Determiner role in Security/Accounts

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.

image

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.