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

Annotations: Take content identifier into account #687

Open
stefandesu opened this issue May 10, 2022 · 1 comment
Open

Annotations: Take content identifier into account #687

stefandesu opened this issue May 10, 2022 · 1 comment
Labels
question Further discussion needed

Comments

@stefandesu
Copy link
Member

stefandesu commented May 10, 2022

jskos-server now automatically adds a mapping's content identifier to an annotation if possible: gbv/jskos-server#173

This means we can now compare this identifier (annotation.target.state.id) to the mapping's current content identifier to see if the mapping has changed, and if it did, these annotations should not be taken into account. (They can still be shown as "invalid" with a hint that the mapping has changed in the meantime.)

If possible, the creator of such an annotation should be able to update that annotation. This should perform a PATCH request that updates the identifier in target.state.id. We need to figure out a good UI to do this.

Should be taken into consideration for #682.

Related to #667.

@stefandesu
Copy link
Member Author

these annotations should not be taken into account

Update: This is probably too complicated. An easier solution would be to allow a mapping creator to delete these invalid annotations after they updated the mappings. This needs to be implemented in jskos-server. (Issue TBD.)

@nichtich nichtich removed this from the 1.10.0 milestone Jun 9, 2023
@nichtich nichtich added the question Further discussion needed label Jun 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further discussion needed
Projects
None yet
Development

No branches or pull requests

2 participants