ACLs on custom table - need any user to be able to add comments

Brian Workman · ‎08-01-2018

I have a custom table, we'll call it table that includes many fields types, including a journal input called comments and another called internal_comments.

We have a requirement to lock this down tight, but, via the portal, we want people to see their own records.

I have a role for the table u_table_users that has full access to the table except for delete, which is set to admin role.

I managed to get the custom page/widget on the portal to show the details of the record, however, I need for the comments field to be writable for the user. I found that i can achieve this by the table:read and table:write ACL to condition Opened By is (dynamic) me. But, if they have platform access, they can find the record and update it there and I don't want this because they can change other values in the fields. Users do NOT see internal_comments, which I managed.

So, what I'm looking for is this:

On the Portal

Any user be able to read/write to comments and read every other field except internal_comments.

On the Platform

Any user can read all fields except internal_comments and be able to write to comments field only.

scott barnard1 · ‎08-02-2018

Just looks like you need a read ACL for all fields with no role. That way anyone can see everything.

A write ACL for the table role to all fields. This gives roled user access to write to the fields and also bars users without the role writing to fields.

A write ACL for the comments field that is opened by dynamic is me. This deploys after the roled acl prohibition as it is more specific.

Note that read is not enough for the comments field as it's a journal record input field. Without write access they just will not see the box.

They will see the activity stream if you have one etc.

View solution in original post

Mark Stanger · ‎08-01-2018

If things really need to be locked down, then you'll want to use ACLs. Every other form of security simply masks the input (which can be bypassed). ACLs don't care about how the record is being viewed, however. It will be consistent (as it should be if it's really secure) regardless of how the record is accessed. It sounds like you need to define more precisely which users can update 'internal_comments' and which users can update 'comments' regardless of the view. Once you do that, you can add the appropriate ACLs to secure the fields.

Once the ACLs are in place, the only other thing to do would be to customize a view or set up a UI policy to hide those readonly fields that shouldn't be visible in either place.

Brian Workman · ‎08-01-2018

You know, I didn't think about creating a view for non u_table_users role.

scott barnard1 · ‎08-01-2018

Is the table extended from another?

If it is you will need table specific acls to override the parent

Also restrict what the author can change, it should not be the whole record. They are the creator but they don't have to have full control etc

Brian Workman · ‎08-01-2018

This is a custom table that does not extend any other table. And what you are describing is what I'm trying to achieve.