I've been a Notes developer for years but never used an Access Control Section on a Form.
I want to give (web) users (with the right [role]) access to edit only one field on a document. I'm assuming an Access Control Sections is the way to go.
A couple of things aren't obvious:
As well as adding the [role] name to the Access section's formula does it also have to exist in an Authors field on the document?
If #1 is true, then do all other fields have to also be in an Access Control Section where that role can not edit them?
Jake
The access control section controls access to what ever is in the section. It does not need an authors field.. Only the content or fields that you want to control access to are included. Authors fields define who can edit a document. Regardless of what level of access a user has, if there is an authors field and the role is not listed, that user will not be able to edit the document.
You can use an authors field to limit the editors to certain documents, from there you can further restrict access to fields to edit by sections. If you do have an authors field in conjunction with a section, the role needs to be in the authors field as well as the section access formula in order to be able to edit
In Lotus Notes Access is ALWAYS calculated top -> down.
If you don't have Author- Access to the document itself (defined by an Author- field or because you are Editor or higher) then a Section- Author- Role will not help you.
The answer is: Yes, you need an editor- field containing the role.
In consequence the answer to your second question is also: YES, you need to protect the other fields with a section (without the role) as well, if you really want to restrict access to that single section.
Related
Let's say I have a data template that has 3 field sections: Basic Info, Navigation Info and Content Info. I would like to restrict Field Write access to the fields in these sections by role. I know that it is fairly simple to create a role for each of these and deny Field Write for the other sections. For example, I could create a role called Basic Info Editor Role and deny Field Write for all of the fields in the Navigation Info and Content Info sections. However I need to have the ability for a given user to be a member of more than one role sometimes. So I may have a user called jSmith that is a member of both the Basic Info Editor Role and also the Navigation Info Editor Role. I want jSmith to be able to edit both of those sections of content.
I can't figure out how to do this. It seems that by default all users have Field Write access to all templates. I think somehow I need to remove inheritance so that they don't all have the Field Write granted or something. Any ideas?
From what I remember you cannot assign Field Read and Field Write access rights on the section level - you can only do this on the field items directly.
Anyway, I think your approach is correct:
select chosen field which should be restricted
break the inheritance of this field for your base role (e.g. Standard Editor)
and then create Basic Info Editor Role which will be a member of the Standard Editor role
add Field Write option for the selected field for Basic Info Editor Role role.
All other Standard Editors won't be able to change this field, only Basic Info Editors will be allowed to change it.
A user is not able to edit a form. The user had editor access and i've tried to replicate the issue using a test user and providing the same access as the user, but to no avail. I came across a link which told me that there is something called as additional ACL control in Lotus Administrator. I'm not sure if this actually can influence the editing privileges. I don't think that could be the problem. Anyway, please let me know if you can figure out the problem.
Additional info:
The user is a part of a distribution list(multipurpose group) and the group has editor access.
The default access to the form is Author, with a authors field in the form.
The user has 2 names mentioned in the names.nsf person document. An old name and a new name.
The required user roles are assigned to the group.
Let me know if you need additional info.
With Editor rights she should be able to edit. Please check her rights by placing a Computed Text with #UserAccess on the form.
Or if she is using a Notes client she can simply click the "Security" icon in the bottom toolbar of the Notes, near the right corner. It will open a dialog box telling what is her access level to the database.
A few things to check:
is the user listed explicitly in the ACL? If so, those rights will take precedence over any groups she's in.
check the authors field carefully. Best option is to look at the properties of the doc she's editing via the Notes client and examine the authors field in the dialog. That will let you see if any code altered the list of allowed authors. If she's an editor this shouldn't matter but based on the behavior you are seeing it sounds like she's acting as an author.
Make sure that the names in the authors fields are being stored in the canonical format and are not abbreviated or in common name. EG: using Herny Newberry/MyOrg does not work while using CN=Henry Newberry/O=MyOrg does.
The issue is solved. There was some problem with the user configuration. Thats the reason she was getting author access even though she was an editor. After reconfiguration of her Notes client, she'd able to edit the form now. Thanks to all of you for your help.
Although already answered and a solution found, it should be noted that user-names listed in the 'fullname' field of the NAB person record should list the current or 'newname' first as other names may not be recognized.
Is it possible to validate the Xpage's ACL depending on the Source document's field value.
We need to make the Authors & Readers ability at XPage level (as per requirement I am not supposed to use the ROLES, since, it is dependent on each individual Authors which is stored in backend document FIELD).
Kindly suggest the approach, as I am not even looking HideWhen for the Buttons(edit,save etc)
Example code in the ACLEntry[0] in Xpage:
if getComponent("inputText1").getValue() == sessionScope.user {
session.getEffectiveUserName();
} else {
return false;
}
Thanks.
I do not quite understand your code on that property...
To query the readers/authors level at XPage level I suggest to use the database.queryAccess method (http://www-10.lotus.com/ldd/ddwiki.nsf/dx/NotesDatabase_sample_JavaScript_code_for_XPages?opendocument&comments#queryAccess)
You try to compare the username only. This may fail if your access level is computed by a membership in a group where your username is not relevant.
XPages' ACL depends on the database ACL, so you have to setup the levels there - the XPages' ACL is in addition to the "real" ACL as far as I experienced.
I also experienced that readers fields affect the ability to use an XPage to open a document by default.
I hope my answer is not too confusing ;-)
I think the question is valid (to my current knowledge):
If I want to design a workflow application but the current approver should not edit the full document I want to give him only access to parts (ie. a comment field and the approval button).
The question above relateds somehow to access controlled sections in old LN development. I so far also didn't find a good solution
What you describe is a very common workflow scenario. There are several ways how you can implement that efficiently. Here is what I would do:
Have one (or more) custom controls that render the "payload" (the fields the requester fills in)
assemble them into one bigger control that is used to render the form
compute the mode to read/edit depending on who is opening the form and the mode (new, pending approval, approved, rejected etc.)
Optional: when submitted remove submitter from the author field
Have one "Approval Control" that show only when the current user is the (current) approver and status is "pending approval" That control has fields that are NOT bound to the document, but a scope variable
The approval button triggers SSJS that takes the scope variable values and updates the document (and triggers notifications, access change etc)
The approval component can be used for any approval form. You then can contemplate not to give the approver write access since you could handle that in code.
What I need
I have a custom Entity with that with multiple fields. Admin Role has "god" access. All other roles except for one have read only. The one non admin role with update access, should only be able to update a single field.
What I believe to be true
I believe I have three main options to implement this requirement:
Enable Update Access to the role for that entity then write Javascript to disable all fields on the form for that role, except for the one that I want that role to be able to edit
Enable Update Access to the role for that entity then create a new form that disables all fields on the form for that role, except for the one that I want that role to be able to edit.
Enable Update Access to the role for that entity then turn on field security for each field, disabling access using the field security, for each field except for the one I want them to edit.
What's the Best Practice?
What options should I choose?
If I go with options 1 or 2, will the user be able to edit the field on the bulk edit form?
From a user perspective, I think it's confusing when a form opens up with things enabled, then they get locked down. Plus someone could possibly get data in there before the fields get locked. I'd say you'd have to combine this with a plugin to prevent changing fields you don't want changed.
I like this option better, although again, the field can be unlocked if someone knows what they're doing, so a plugin to double check would be nice.
This would avoid having to double check in a plugin, but you also have to rely on the admin correctly setting up security for new fields going forward. If that's not a concern, this might be best.
Bulk edit is a global privilege, so they'd have bulk edit for all entities. Also, the bulk edit form does not load scripts, so that knocks out option 1. I'd say if it's just this one field, I might leave the privilege locked down and provide my own Bulk edit button on the grid that would show a custom page that just has that one field on it, then handle the updates though script.
2 is most likely best, or as an alternative put the fields in the header or footer rather than as read-only fields on the form.
This also means the fields won't be available to bulk edit, but other methods such as data import or workflows would let users get round this if they know how and have rights to do such things.
3 Field Security is the most robust and works for all scenarios
Possible option 4: create another entity to contain those fields and apply different security to that entity. If created as a child, show the record in a grid on the form with the values included in the view. If it is a parent then you could use methods such as showing the values via an HTML webresource page included on the form.
I am setting up an Inquiry list. There will be two groups of users: Requestors and Administrators. The Requestors will fill in a form with basic information and their question. The Administrators will respond to the inquiry and have additional status fields to fill in; these fields should not be visible to Requestors (essentially, two different forms). What do I need to do to allow the Requestor to see one form, while the Administrators see a different form (containing all of the fields from the Requestor form as well as Administrator-only fields) when they edit the request? I'd like to do this without having both forms show up on the "New" button.
Also note that I am prohibited from using anything other than Sharepoint's "out-of-the-box" functionality.
Thanks!
Ralph
Try Forms Designer tool. It allows to personalize forms based on the current user membership, permissions and field values.
I would keep the same form myself, but get the Administrators fields to not display.
Boost Solutions may be what you are after.