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

Question

Question

field Create and/or Edit rights without Read rights

asked on June 11, 2014 Show version history

In LF 8, we had fields with security set so that only certain users could view and edit them.  They (the field(s))were part of a template, and that template could be applied by anyone with rights to apply the template even though they had no rights to 1 or more fields on the template.  After they upgraded from LF8 to LF 9.1.1.486, without changing any security, suddenly the users that have no rights to the secure fields can not change template assignment on entries that have templates with secured fields.

 

I contacted LF Tech support about the issue and they told me it was acting as designed and if I needed help with configuration, then I need to go to Answers.  They also sent me to the help file Field Security.

 

In the Help file it states:

You also need the Edit right on all fields in the current template to apply a new template to the document.

 

 Here is the problem,  to apply the Edit Allow right, it is now also forcing the Read Allow right.  If they have the Read Allow right, then the field is no longer secure.  So then, I tried to add the Edit Allow to a group and then do a Read Deny on the individual user, but the Read Deny is also forced an Edit Deny.

 

How are we supposed to secure our fields yet still allow users without the field security to modify the template assignment?  This definitely seems to a big problem!

0 0

Answer

APPROVED ANSWER
replied on June 11, 2014 Show version history

Hey Bert,

 

I wanted to step in to confirm what Alex and Aaron have been saying. The behavior for what has been described here has been the same behavior since at least version 7.2 in both the desktop Client and Web Access. I checked documentation for our prior versions and it lists it there as well - it's somewhat hidden in the descriptions, but that at least indicates that the behaviors were the same. The earliest online docs is for 8.3, and the relevant page can be found at: http://www.laserfiche.com/support/webhelp/laserfiche/8.3/en-US/adminguide/lfadmin8_CSH.htm#Security_Fields.htm. I also checked a copy of the 8.0.1 admin chm file and the same line ("You also need the Edit right on all fields in the current template to apply a new template to the document.") was present there as well. This is definitely not new behavior in 9.0.

 

That said, I wonder if perhaps we are talking past each other and what you are describing isn't necessarily the whole scenario. For example, do you know what application this was done through or perhaps an integration? The desktop Client and Web Access have restricted this for a while, but some other applications appear to have not done so until more recently - perhaps you happen to be hitting that? Alternatively, if a user had certain privileges or rights not directly related to this specific setting (such as the 'Manage Templates and Fields' right), they would automatically get an implied read access right on all fields, avoiding this issue. Are you certain you are comparing the exact same user with the exact same security setup?

 

Unfortunately, this was definitely existing behavior in the base case. It very well might be that the exact scenario that was being used in this situation avoided or bypassed this in some way which changed, perhaps unrelated to this and this is just a side-effect, but unless you have the exact scenario it's not really possible to say.

 

Added: I also doublechecked that the 8.0.1 admin documentation states that the Edit Field Access Right implicitly assigned Create and Read, so it's not a change there either.

2 0

Replies

replied on June 11, 2014

Can you clarify what the customer is trying to do exactly? In your example, some users do not have read/edit rights to some fields in a template. However, these same users are to be able to change the template assigned to documents? That means they would be able to effectively delete those field values if they change to a new template that doesn't have those same fields.

0 0
replied on June 11, 2014

Fields are no longer bound to the templates!  Therefore, template reassignment does not edit the field or its data.  The user should have the option to reassign the template regardless of the field security.  If a field is on a template but has no data, then I can see how it is argued that they are removing the field, but the truth is with an empty field, they are not removing anything.  If the secure field does have data, then that field with its data should remain as an independent field if it is not part of the new template assignment.

 

How can Laserfiche conclude that every user with permission to assign a template should have read rights to every field not only that template but on any other template that may potentially be previously assigned?  That just is not how the real world that I live in works.

0 0
replied on June 11, 2014

So basically you're wanting all fields that have data to be automatically converted to independent fields when a user changes the template to one which those fields aren't part of?

0 0
replied on June 11, 2014

The default behavior for fields that the users have full rights to is already to keep the data as an independent field.  Why should the behavior be different when they do not have rights to the fields?

 

We do not want them to change the field or its data, only weather it is in a template collection assigned to the entry or an independent.  This is how it was functioning for the users in LF 8, so I am unsure why this is not an understood issue or what the confusion is.

0 0
replied on June 11, 2014 Show version history

It doesn't appear that this behavior changed from version 8. I just tested on a 8.0.2 installation and a user cannot change a template if they are denied edit rights on at least one field in that template:

 

0 0
replied on June 11, 2014 Show version history

In Laserfiche 8 and 9, the Client and Web Access will not allow users to change the template of an entry from one to another if the user doesn't have edit rights to all fields in the source template. Note that this is different from applying a template to an entry that doesn't currently have one.

 

Now, regarding the scenario where the user does have edit rights to all fields in a template, we never had the ability to automatically save the fields that had data as independent fields when the template was changed to a new one that doesn't have those shared fields.

 

However, we do understand the request that it'd be nice to be able to retain the fields with data as independent fields when the template is changed, regardless of what rights the user has on those fields. I will speak with development about this and file an enhancement request.

0 0
replied on June 11, 2014

Well, we can not go back, but I can tell you the the user could not see certain administrative fields, but they could change the template from the template with secure fields to any other template they had rights to.  After the upgrade, they can not.  So weather it was intended or not, my customer had this functionality in their LF 8.x system.

 

What it boils down to is that if a secured field is applied to a template, then it dramatically limits the ability to change the applied templates if needed.  My customer is using the fields for administrative purposes, and it is a big hassle for their high value people to spend a lot of time adding independent fields to documents and as LF9 is currently, this is the workaround for secure fields.  In this (my) customers view, this is a big step backwards for them and they are disappointed in the move to LF9.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.