Entities Integrity URL #1348
Merged
Entities Integrity URL #1348
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
a1f8727 to
b066ea7
Compare
b066ea7 to
ee4b6f2
Compare
ktuite
approved these changes
Feb 12, 2025
docs/api.yaml
Outdated
|
|
||
| [Offline Entities support](https://forum.getodk.org/t/openrosa-spec-proposal-support-offline-entities/48052): | ||
|
|
||
| * If an attachemnt is linked to a Dataset, then `type="entityList"` attribute is added to the `mediaFile` element. |
There was a problem hiding this comment.
Suggested change
| * If an attachemnt is linked to a Dataset, then `type="entityList"` attribute is added to the `mediaFile` element. | |
| * If an attachment is linked to a Dataset, then `type="entityList"` attribute is added to the `mediaFile` element. |
lib/formats/openrosa.js
Outdated
| isDataset: attachment.datasetId != null | ||
| isDataset: attachment.datasetId != null, | ||
| integrityUrl: attachment.datasetId ? | ||
| `${data.domain}${data.projectPath}/datasets/${encodeURIComponent(attachment.name.replace(/\.[^/.]+$/, ''))}/integrity` |
There was a problem hiding this comment.
This building of the dataset name from the attachment name makes me nervous. What if there's a weird name that we matched successfully elsewhere but this doesn't work? How does this work in the case where the dataset is manually linked to the attachment? Can we get the name from the database OR can we have a utility that transforms attachment names to dataset names in a reliable way?
It should be the exact same mechanism in the PATCH attachment resource where an attachment name (with .csv or .CSV) is transformed into a dataset name that is then matched in the database.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #668
Dependent on #1349
What has been done to verify that this works as intended?
Written tests. I have deployed this to dev environment for Collect team to start using this endpoint.
Why is this the best possible solution? Were any other approaches considered?
Used the existing pattern.
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?
Since Form manifest is changed, it should work with older Collect clients.
Does this change require updates to the API documentation? If so, please update docs/api.yaml as part of this PR.
yes
Before submitting this PR, please make sure you have:
make testand confirmed all checks still pass OR confirm CircleCI build passes