Permissions bug or question!

I have a table called ‘onc_np’ which has data that I don’t want the users to be able to alter in any way. So I created a related table called ‘onc_np_extension’ which I automatically populate with a related record when a new record comes into onc_np. I DO want my users to be able to update onc_np_extension. So I set the table security for onc_np to be explicit as Read only and I set the table security for onc_np_extension to be explicit as for ‘Read’ and ‘Update’. I have a relation from onc_np_to_onc_np_extension (based on a medical record number). I have a form based on onc_np with two fields from onc_np_extension as onc_np_to_onc_np_extension.fields. Those fields though can’t be updated.

Why doesn’t that set up allow my users to update those fields from onc_np_extension? Instead I have to give ‘UPDATE’ permission to them on ‘onc_np’ as well as ‘onc_np_extension’. That doesn’t make any sense to me. Why should the ‘child’ table have to have the permissions granted to the parent table in order to do those actions on the child table? Instead I have to label every field showing from onc_np with ‘editable’ unchecked to achieve more or less the same thing. That makes for more work and it’s less logical and safe. (Because now I have to remember that onc_np - which I don’t want in any circumstance to allow updates from users - allows updates. If I use that table/fields, I have to remember to mark every field again as not editable.)

This is in 5.2 but I believe it is the same situation in 6

If instead of adding the fields that should be editable directly to that form (via relation), you add them via a portal or a “HIDE” tab-panel & form with empty borders then it does work as expected. I tend to agree with you that those fields should not be blocked either, although the form is based on a write-restricted table. Please file a case for this.

Thanks Andrei. I filed a case for this: Jira