-
Notifications
You must be signed in to change notification settings - Fork 6
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
create presave validation hook for field_member_of and field_access_terms #108
Comments
It is unclear if this is a prerequisite for #114 or not. |
So proof of concepted this quickly to do what was discussed as a MVP. Ran it past @bseeger and it seems to meet the intent of what's being intended for the time being. To distill it out down leveraging the In the below scenario two collections are made: "Collection A" and "Collection B". The "test" user is given access to ingest into "Collection B" only. When attempting to ingest into "Collection A": Ingest into "Collection B" yields a new object. Currently this code lives in the In regards to other work that distills out from this:
|
As discussed on the iDC developer call I will go ahead and create a new module that will begin to contain more general hooks that aren't UI related. |
Fixed in jhu-idc/idc_defaults#1. |
As discussed in Slack tests are required for the above so this issue isn't ready for review yet. |
|
All related PRs are merged, so this is done |
We should create a pre-save validation hook (maybe in islandora defaults) to prevent a user from putting values they don't have access to in those particular fields.
This would prevent a user from putting an object in a collection they don't have edit access to. This could help solve part of the problem outlined in #107. If we had a presave hook, it wouldn't matter so much what showed up in the UI, as this hook would catch any invalid values for that user.
This is also key to helping prevent the migration ingest from putting items in collections it shouldn't.
To be clear, if we have time to do one thing, this has a higher benefit then #107 as it will provide validation before saving the node. It will cover both the UI workflow and Ingest workflow paths.
The text was updated successfully, but these errors were encountered: