It seems like the Table->Determination policies don’t do anything (at least in a practical way) is that correct?
For example, simply allowing create/update on the determination table does not allow one to add determinations to a collection object. You also have to allow updates to the collection object table. But allowing updates to the collection object table enables all permissions related to the determination, even ones you may not want, like deleting determinations.
The use case here is that we want a ‘determiner’ role where someone can add their own determinations to a record and even set it as preferred, but not change the other collection object data or delete other determinations for that object.
The policies above do not allow the user to create determinations on a collection object unless you check “update” for Collection Objects. But doing so seems like an all-or-nothing permission for the determination table. Please let me know if there’s something I’m not doing properly, thanks!
To be clear, I’m not requesting any additional features if my assessment is correct - we can work around this- but if there is something I’m missing here i’d like to know about it.
Hi, you are correct.
I believe we can change this behavior and make Table -> Determination -> Delete forbid removing Determinations from Collection Objects. Similarly for all other dependent relationships (you can see whether the relationship is dependent using the Database Schema viewer in the user tools menu)
Long explanation behind the current behavior:
The issue is that the determination record can not exist separately from the Collection Object.
The Table -> Determination -> Delete permission is responsible for ability to delete determination records. You can see it’s effect only when you open the Determination record directly, not as a subform on the Collection Object form.
Of course, a more useful behavior would be for that permission to forbid removing determinations from a Collection Object. But, this action is editing the Collection Object record, not determination, which is why it is currently under Table -> Collection Object -> Update
Thank you, that explanation makes sense and was my suspicion as well. Just as a test I went to see if I could work around this by making a determination query on a given catalog number, opening the determination record directly and then choosing ‘add another’ but it threw an error. Not surprisingly - that is a probably entirely unexpected way to interact with determinations.
I’ve noticed that the GEOLocate plugin circumvents some of this behavior. For example, if Collecting Information is read-only (if I don’t want someone editing the verbatim locality field) but the Locality table is updateable (because I want to create a ‘georeferencer’ role) then none of the locality fields can be edited directly as a subform, but one can still update and save parts of the locality table subform (lat/long, uncertainty estimate, etc.) using the GEOlocate plugin. The other fields (locality name, etc) still can only be edited by opening the locality form directly, but this hides the other relevant collecting information.
Anyway, this gives me hope that at some point the functionality of editing and saving changes to a pop-out form from a read-only form could be possible. This would be useful for the georeferencer role where I might want them to easily see (but not edit) verbatim locality while editing the locality.
I think in the mean-time (for anyone still reading 
the solution is just to just have two tabs open with different tables displayed.