nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

choice_filter affecting choice list order

EricaCirigliano

Hello, team S123,

I'm using S123 Connect 3.12.232

I have a select_one list of three choices that I want to appear in the order they are listed in the XLS form.

I have inserted a choice_filter called choicelimit, which contains integers. Here's a screenshot:

In the above configuration, the options show in the survey as (1) survey (2) chgbearing (3) end (using name column values for brevity).

To confirm that the choicelimit column was affecting display order in the survey, I changed the choicelimit value for chgbearing to 19. In that case, the choices in the survey displayed as (1) chgbearing (2) survey (3) end.

This list appears in a repeat. Once the repeat has been collected 20 times, I want the first and third option not to display any longer. There is a counter in the survey that keeps track of the repeats. If there is a better way to execute this, I'm fine with not using choice_filter. If there isn't a better way to do this, how can I better control display order?

Thanks,

Erica

Find more posts tagged with

Accepted answers

ZacharySutherby

@EricaCirigliano @DougBrowning,

Thank you for passing this information along! We have an issue logged internally for this behavior. Please go ahead and reach out to Esri Technical Support to log an official BUG for the issue.

Thank you,

Zach

All comments

SMH-Rio

Any chance this issue returned with version 3.18.124? I had never seen this before and now the same problem described in the post is happening (the list is being sorted in alphabetical order by choice_filter)

ZacharySutherby

Hello @EricaCirigliano,

Adding @IsmaelChivite for visibility.

In looking at Supports database it looks like the previous defect you may be referring to is BUG-000120594, which was implemented in Survey123's 3.10 release and nested repeats can be submitted in the web form using the current 3.12 release.

Please feel free to message me directly at ZSutherby@esri.com and we can set up a call to discuss issues encountered and the defect logging process.

Thank you,

Zach

EricaCirigliano

@ZacharySutherby

For the record, I'm a big fan of the dev teams behind S123 and QuickCapture. You all are responsive to requests and it's been gratifying to watch both applications mature in real time.

This is the second time I've been asked to submit a bug report to help the S123 dev team. Unfortunately, the customer side of this is confusing to the point of being frustrating. The previous bug report appears, based on what our interface says, to be closed, but I know for a fact that the bug still exists.

After spending 30 minutes trying to figure out how the process works, my supervisor and I gave up. If you, or anyone else in the land formerly known as Geonet, have pointers on how to get through this process from the customer side, we're all ears. Help us help you.

Erica

EricaCirigliano

@ZacharySutherby

Thanks for logging this as an issue. I'm not an administrator of our AGOL system, and I know internally we've been somewhat confused by the need to log a bug ourselves when it has been logged also by an Esri dev team and how to match those bugs up as being the same thing, but I will enlist the help of my supervisor and we'll take a crack at it.

Erica

ZacharySutherby

@EricaCirigliano @DougBrowning,

Thank you for passing this information along! We have an issue logged internally for this behavior. Please go ahead and reach out to Esri Technical Support to log an official BUG for the issue.

Thank you,

Zach

EricaCirigliano

Hi @ZacharySutherby ,

Thanks for posting that. I was able to replicate the issue by changing the comparison operator from != to > in the choice_filter for the "action" select _one.

Thanks,

Erica

dougbrowning

I sent this to James before and he saw it. I will forward to you as well. thanks

ZacharySutherby

Hello @EricaCirigliano @DougBrowning,

I'm not seeing the behavior on my end, would I be able to obtain a copy of an XLSform that's reproducing the behavior?

Typically choices will be ordered the same way they are in the choices worksheet. Here is a sample XLSForm that I was testing with where I'm not seeing the behavior.

Thank you,

Zach

choice_order.xlsx

dougbrowning

I am not sure if this is the same issue we are seeing. It started with the new way lists are stored now. It is sorting by the filter instead of the order of the list now.

Does this sound the same? We have not found a way around it yet.

So we ran into an issue with Survy123 3.12.277. When filtering an external_choices list we are getting the results back in alphabetical order based on the filter. And further, capitalization counts – so NonWoody is not the same as Nonwoody. This is not the case for Survey123 Connect or we think older versions of Survey123.

Type (line 96):

select_one_external PlantsList

Choice_filter (line 96):

Type=${herb} or Type=${none} or Type =${unknown}

We set (lines 52…)

${woody} to “Woody”

${herb} to “NonWoody”

${none} to “None”

${unknown} to “Unknown”

It does not matter what order the items are in the choice_filter, we get the results back in alphabetical order by filter.

NonWoody

None

Unknown

Woody

What we want is for None to be first, since it is most often picked. Is there a way we can accomplish that? If we change “NonWoody” to “Nonwoody” then it would work. But that messes up all our workflows downstream. Plus, we don’t want to name filters just based on making sure they alphabetize correctly.

thanks

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.