You are viewing limited content. For full access, please sign in.

Question

Question

Template Security - Field Setting Shared between Templates

asked on July 22, 2022

I noticed something that I was not expecting when setting security in a new template. I have fields FirstName and LastName being used between two templates.

In the first templates I go through add the corresponding groups and give them their read and writes to the two fields, I then remove the groups from this template that do no need access. 

I got a call and it turns out when i removed those groups from the first template, it removed their access to the share fields. I re-add the read and write access in the second template and when i go back to the first template these groups are automatically added back in with the same access to these shared fields. 

I was looking into just creating new first and last name fields but they will have to be named differently and requires configuration changes within workflow and the import xmls and looking at future state we will be using first and last names fields in more templates.

Please note all of these settings are being attempted via Web management for the repository.

Is there a way to set field security by template? or is this acting as designed?

0 0

Answer

SELECTED ANSWER
replied on July 22, 2022

It's acting as designed. The security is on the field, regardless of why it is assigned to the entry - either as an "independent" field, or as a part of any of the templates it belongs to. The UI is admittedly a little confusing, but the key thing to understand is that the list of users is everyone who has been assigned rights to any of the fields in the template. There's no difference between assigning (or removing) a field right in the dialog for Template A vs Template B.

0 0
replied on July 25, 2022

I think if this presents a challenge for you - that you want users to have different access to the FirstName field based on whether it is part of Template A or Template B - it is an indication that you really have 2 different fields here. For instance, Customer First Name and Patient First Name. The activity most impacted by creating additional fields is searching, so that's a good lens through which to consider the question. In my example, there probably isn't a scenario where a user would have a name to search for but they want to search across both customers and patients. So in that case, it's ok to split them.

Also keep in mind that field rights are secondary to entry rights. So if a user lacks read or write rights to an entry, that applies to the fields as well. So maybe you have a single "Social Security Number" field (rather than splitting it into multiple distinct fields), but your security needs are satisfied because HR doesn't have access to patient records, and the medical staff doesn't have access to HR documents.

0 0

Replies

You are not allowed to reply in this post.
You are not allowed to follow up in this post.

Sign in to reply to this post.