Skip to content

Conversation

@grzesiek2010
Copy link
Member

@grzesiek2010 grzesiek2010 commented Sep 29, 2025

Closes #6425

Why is this the best possible solution? Were any other approaches considered?

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Do we need any specific form for testing your changes? If so, please attach one.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

Before submitting this PR, please make sure you have:

  • added or modified tests for any new or changed behavior
  • run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
  • added a comment above any new strings describing it for translators
  • added any new strings with date formatting to DateFormatsTest
  • verified that any code or assets from external sources are properly credited in comments and/or in the about file.
  • verified that any new UI elements use theme colors. UI Components Style guidelines

@grzesiek2010
Copy link
Member Author

grzesiek2010 commented Sep 29, 2025

At first, the issue seemed pretty straightforward based on the description, but it turned out to be more complex.

In Javarosa, choices are loaded without any awareness of entities - it treats all choices the same way. I believe that was intentional, and we don’t want to change this by passing the usesEntities parameter into Javarosa.

In Collect, we have LocalEntitiesInstanceProvider, which Javarosa uses to load entities (instead of choices from a static CSV file) when a matching dataset exists (as described in the issue). However, at that point we don’t have any details about the form (whether it uses entities or not) that could help us decide whether LocalEntitiesInstanceProvider#isSupported should return true or false.

Given that, the simplest solution I can think of is to introduce something similar to what we did for enabling/disabling entities in the settings. There, we had a function that determined whether LocalEntitiesInstanceProvider should be added. The difference now would be that instead of checking the settings (like before), the function would check the currently loaded form.

What do you think about this approach @seadowg?

Copy link
Member

@seadowg seadowg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've realized that I don't think this entirely solves the problem sadly: you could still have a form that uses an entity list, but also has a non entity list CSV that clashes with an entity list in the project. That's definitely an edge case, but I think the flow in the issue is as well.

I think to fully solve this we really need to be able to have access to information about the media file we're referencing (through a MediaFileRepository) for example. This is something that we've talked about on and off, but it's always been hard to justify. Maybe we should bite the bullet here? This could be a good issue to drive that out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

When a static CSV with the same name as an Entity List in the project is attached to a form, the Entity List is always used

2 participants