Hi,
I have some buttons on the top of the forms or on the views. how can I hide those buttons from unauthorized personnel?
Thx,
Pam Henry
Subject: How to hide buttons
If you mean Action buttons in the button bar, they each have their own Hide-When properties. If you mean hotspot buttons within the form real estate, their Hide-When state is controlled by the Hide-When proprties of the paragraph they’re in.
As far as the determination of authorized personnel, I would hope you’re using roles for that.
Subject: RE: How to hide buttons
Hello Bruce,Sorry, I was referring to buttons on the menu bar, like the ones on the groups, etc. Some people don’t have permission to modify/add groups, people so I’d like to hide those buttons from them. Also determinination who mofidies/adds groups, then I should have (and use) the hidden fields on the bottom of the forms. What about roles?
Thx for fast reponse.
Pam Henry
Subject: RE: How to hide buttons
If you’re asking “what about roles?” in a general sense, that’s a whole topic we could go into.
However, it looks to me as if you’re asking specifically how to hide the “New Group/Person/etc” actions in the various views of the NAB.
-
Have you assigned/removed the appropriate roles which already exist in the NAB specifically to do exactly this?
-
If you have assigned/removed the pre-existing roles, the result is that when an unauthorized user clicks the button, they get a message that tells them that they’re not authorized. Are you dissatisfied with that behavior, and want the buttons to disappear in addition? Then just add a hide formula to the button based on the appropriate role, using @userroles and @isnotmember.
-
If by “hidden fields on the bottom of the forms” you mean the shared DocumentAccess field, then since it’s a computed field, the only way to mess with it is to rewrite the formula. There is less than no reason to do this; that’s what the Modifier roles are for.
Userroles in the NAB:
Subject: How to hide buttons - Disable “double click”
Bruce,
I am able to hide the buttons successfully. When the use opens the form, the only thing s/he sees is Cancel button. However, another issue came across is, when the (unauthorized person) user double clicks on the form, then the buttons (Save&Close and Cancel) appear (it looks like that the user is authorized person). The user modifies the form, clicks on Save&Close button, a message says that “You’re not authorized…”, that is Ok, then s/he clicks on Cancel button, a message asks user that “Do you want to save changes… Yes, No, Cancel”. If the use choose yes, then data will be saved.
How can I disable the “double click” functionality on the form?
Pam Henry
Subject: RE: How to hide buttons - Disable “double click”
Bruce,
I got it,
I put Continue = false in QueryModeChange event in the form design.
Thx,
Pam
Subject: NO!!
That will prevent anyone from toggling any doc of that type from read mode to edit mode and back again.
Your original question was how to hide action buttons, so that’s the question I answered. However, I now see that your question was really, “How do I control edit access to documents?”, and the answer to that is to use the ACL and Authors fields. Do NOT ever, ever, ever, use hide-when and other logic in place of real security in order to simulate security!
Subject: Can ACL & Author field & hiding button be done at the same time?
Hi Bruce,
It seems like you’re right. I used that logic, and the user wasn’t able to edit the form even though the button appears on the form (since s/he is authorized to see EDIT button and to modify the form). Based on your suggestion is that I should use ACL and Author fiels. I’ve never used Author field before and not sure how to apply that in here. What about hiding the button? How can I handle those two issues at the same time?
Thx,
Pam Henry
Subject: RE: Can ACL & Author field & hiding button be done at the same time?
Yes, you can hide the button in addition to controlling edit access; the two are completely independent issues.
Subject: RE: Can ACL & Author field & hiding button be done at the same time?
You have an authors field on the form (and give all users author access). The authors field contains a user name (fully distinguished) or a role. If the user is not a member of that field, they do not see the buttons. If you add this field after the fact, make sure you refesh all the documents so the field takes hold.
Subject: RE: Can ACL & Author field & hiding button be done at the same time?
FileSave,
For some reasons, this does not work and I don’t know why. Can you give me an example (syntax) for this?
Pam Henry
Subject: RE: Can ACL & Author field & hiding button be done at the same time?
Using Authors fields to control edit access is a fundamental development technique. It’s pretty thoroughly documented; for example:
Subject: RE: Can ACL & Author field & hiding button be done at the same time?
I don’t get this. There are three fields: Field1 (user enters text), Field2 and Field3 (user selects names from PickList (or address book window) window. The form is saved when they click on save button. The users (field 2)will not see Edit button, users from field2 cannot edit the form, but the users from field3 can edit the form which means they can see the edit button on the menu bar.
Can you show me how I can do this?
Pam Henry
Subject: RE: Can ACL & Author field & hiding button be done at the same time?
It’s simple – but not, now that I go back and look, quite as simple as File Save’s initial post may have caused you to believe. You only need to do two things:
-
Use the Authors field to control who can edit.
-
Use the Edit button’s hide-when properties to control who can see it. (This is the part that File Save’s post didn’t explicitly spell out.)
The hide-when formula for the button might get complicated; if hiding based on roles, you’ll need to use a formula like @IsNotMember(“[YourRoleName]”; @UserRoles). If using groups, you can use @IsNotMember(“YourGroupName”; @UserNamesList). If using individual names which show up in the Authors field, you can use @IsNotMember(“CN=Pam Henry/O=OrgName”; AuthorsFieldName). Or you may use a combination of these, combined by the Or operator (“|”).
Regardless of whether the button is hidden, the point of using Authors fields to control edit access is that any non-editor who tries to put the document into edit mode will fail to do so.
Subject: Author field is not working
Hi Bruce,
It seems like the author field is not working or something. I created a seperate blank author field on the bottom of the page with the following description:
Authors (type), editable, allow multiple values. The formula I use for that is @username. Is that how you use it? Is that the right formula? Or am I missing something else How do I integrate this with other fields? The link you gave me is not quite useful for me, it’s too general:
Using Authors fields to control edit access is a fundamental development technique. It’s pretty thoroughly documented; for example:
Pam Henry
Subject: RE: Author field is not working
Pam,
The field as you’ve described it will give document creators edit access to their own documents – as long as nobody changes the field value. (Assumption: When you say “The formula I use,” I assume you mean the Default Value formula.) Unless you want any document editor to be able to change that field, you should change it from Editable to Computed when composed.
Typically, if the goal is to allow the document creator and others with Author-level aCL access to edit, one would create two Authors fields: one visible CWC single-value field with @Username, and another hidden CWC multi-value containing a list of the groups/roles who ahouls also have edit access.
For example:
“EditorsGroup” : “[EditorsRole]”
(The reason for the two fields is that we are usually interested in storing/displaying the doc creator separately from the editors list.)
If you want to further allow users to assign edit access to others, you’d add another, Editable Authors field, multi-values, Use Address dialog for choices.
I’m not sure if I’ve answered your questions?