Got a couple of users who arent able to edit groups that they are ‘owners’ of.
They are also in the application owners group so that they are allowed to edit groups (im not sure if this is a standard notes group or just our building that has this!).
Any ideas?
Subject: RE: Unable to edit groups…
Check whether they have Author access to the directory – if they just have Reader access they cannot edit anything, no matter where their name appears.
I don’t know of any standard Application Owners group. That must be something local to your site.
Make sure their name appears correctly in the group document, in full canonical form. Make sure it’s really an Authors field and not just a text field (these things can happen if the group document is created or edited by an agent and the agent author isn’t careful to set the right field flags, etc).
Subject: RE: Unable to edit groups…
Thanks for that.
The application owners group is just a group that we can add people to to let themedit groups. It does have edit access (the role is set as groupmodifier as well).
Ive checked and double checked their name is correct, with the domain extension on the end as well.
Any other suggestions?
Subject: RE: Unable to edit groups…
You say the Application Owners group name appears in the ACL of the names.nsf with Editor access and membership in the groupmodifier role as well.
I want to make sure you realize that this will give them access to edit any group, not just the ones that list them as owner. This is a serious security issue, since they can make themselves server administrators and give themselves access to other people’s databases that contain confidential information. Author access and no roles should be sufficient to modify their own groups.
When someone is unable to edit a document, there are by and large three possible reasons for that:
They don’t have at least Author access to the database.
They have Author access to the database and are not listed as an Author of the document.
There’s something else going on, e.g. event code in form Queryopen that’s setting Continue=False for some reason.
Assuming you’re using the original names.nsf design, it’s not [3]. To narrow the problem down to [1] or [2], I suggested that you “check whether they have Author access to the directory.” I don’t mean that you should look at the ACL of the database to see whether it looks to you like they should have Author access. I meant that you should check what their actual access is. Have them open the database, stand behind them and look over their shoulder. The security icon that appears in their status bar, shows what access the server thinks they have. The server’s opinion is what counts – not yours or mine. Click this icon and you will see details, including which ACL entries the server thinks apply to this user and whether it considers them a member of the Application Owners group.
If they do have Author access to the database (or higher) then the problem lies elsewhere than in the database ACL. In my previous posting I discussed making sure their name is correct in the group document (by which I meant, in the group document that they are supposed to be able to edit) and that the field in question really is an Authors field. Apparently you didn’t “get” that, as you don’t address it in your response. Refer to the Compleat Reader and Author Field Troubleshooting document, which is in the FAQ, for step by step directions.
Subject: RE: Unable to edit groups…
I have recently experienced a problem where the person could edit the group but the members field was not saved afer editing. It turned out that the docs in question were created by an agent that set the Field Flag “IsProtected” to True. This is not default behaviour in the Domino Directory.