Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent local entity create/update from older spec version forms #6394

Merged
merged 3 commits into from
Sep 9, 2024

Conversation

seadowg
Copy link
Member

@seadowg seadowg commented Sep 3, 2024

Closes #6384

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

The biggest change ended up being in EntityFormParseProcessor. This now only adds the EntityFormExtra if the entity spec version being used is v2024.1 (or a patch of that). For earlier versions there's actually now nothing we need to do with the entity node (that isn't already handled by JavaRosa), so this made sense as a simple change to disable local entities for earlier spec versions. As a point of interest, we'd only been exposing entities after form finalization in these older versions for debug purposes and to verify the spec made sense - this is us explicitly making v2024.1 the cut-off for local entities.

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?

This should only affect entity forms, but it's worth quickly check form entry for a non-entity form as well. The biggest change will be the intended one that now old entity forms (v2023.1 and older) will no longer create or update entities until a submit/refresh happens.

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

@seadowg seadowg marked this pull request as ready for review September 4, 2024 11:58
@lognaturel lognaturel added the high priority Should be looked at before other PRs/issues label Sep 5, 2024
@@ -54,11 +56,11 @@ public void processBindAttribute(String name, String value, DataBinding binding)

@Override
public void processFormDef(FormDef formDef) throws XFormParser.ParseException {
if (!versionPresent && EntityFormParser.getEntityElement(formDef.getMainInstance()) != null) {
if (version == null && EntityFormParser.getEntityElement(formDef.getMainInstance()) != null) {
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need to check if EntityFormParser.getEntityElement(formDef.getMainInstance()) != null here?
Can't we just throw that exception if version is null?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm good point! Let me play with that.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, because if we do that, we end up exploding when there's no version and no entity element. We only care about validating the version if there's an entity element.

Copy link
Member

Choose a reason for hiding this comment

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

Ok so it determines if a form contains entities or not? If so please create a method with a descriptive name that could be used here instead of that enigmatic
EntityFormParser.getEntityElement(formDef.getMainInstance()) != null

Copy link
Member Author

Choose a reason for hiding this comment

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

Gotha! I can probably wrap the whole method in that check as well to make it clearer.

Copy link
Member

@grzesiek2010 grzesiek2010 left a comment

Choose a reason for hiding this comment

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

Copy link
Member

@grzesiek2010 grzesiek2010 left a comment

Choose a reason for hiding this comment

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

One last thing and we can merge.

@grzesiek2010 grzesiek2010 merged commit 7c8e437 into getodk:master Sep 9, 2024
6 checks passed
@seadowg seadowg deleted the entity-spec-version branch September 9, 2024 09:25
@WKobus
Copy link

WKobus commented Sep 11, 2024

Tested with success!

Verified on device with Android 14

Verified cases:

  • Entity forms with old and new spec
  • Mixing old spec forms with new spec forms
  • Offline entities
  • Quick regression check on non-entity forms

@dbemke
Copy link

dbemke commented Sep 11, 2024

Tested with success!

Verified on device with Android 10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
behavior verified high priority Should be looked at before other PRs/issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Only create/update local entities for forms using entity spec v2024.1
5 participants