We are renaming our users and have the administrative server set on the ACL to update Names fields. When the AdminP ran to udpate the Name, it updated the names on the documents but did not update the Names field on the profile document. Is it suppose to update the profile documents as well?
Sidenote: To get to the profile document you must push a button that is only visible to a specific role. Do I need to make sure the server is included in this role to update the fields on the profile doc? I would think that if the server has Manager access it could update any document. And if this is the case, is it just a good rule to make sure the server is included in every role?
Thanks!
Subject: Is the Profile Document read restricted?
You said “you must push a button that is only visible to a specific role” . . . Does the Form used for your Profile Document have a READERS field on it that is restricting read access to a certain ACL Role? If so, then your server will need this Role to be able to see the Profile Documents, to then allow AdminP to update them.
Subject: Should servers be included in all roles?
I do not have a Reader field on the profile document. But the only way you can get to the profile document is by pushing this button that is hidden by a role.
So, what if the Names field is in a controlled section that is based on a Role? Would the server have to be a member of that role to update the Names field in that controlled section?
And is it just good practice to have the servers be included in all roles.
Subject: Access controlled Sections & Giving servers all Roles.
“Would the server have to be a member of that role to update the Names field in that controlled section?” . . . Access Controlled Sections are not ‘real’ document security, as they are on a Form and only come into play if you are editing a document in the UI with that particular Form. If you are accessing a back-end document directly in the database e.g. from an Agent, they don’t have any effect; thus when a server is doing AdminP processing, the Section will not be an issue.
You also asked about giving a server all ACL Roles. Hmmm, thats a loaded question 
It really depends on what you want to achieve for a particular application/environment, so I would not say there is one answer to that.
If you want your server to be able to do ‘everything’, then sure, give it Manager in the ACL with all Roles. But remember that in some situations application developers use Roles in a negative way e.g. if you have Role “[Training]” then don’t execute the mailing code; in such a case you might not want your server to have all Roles.
Personally I’d recommend giving your server and all other ACL entries (Groups etc.) just enough access to perform their duties (can reduce the damage if something goes wring). So in fact Editor may be enough access for many, without things such as Create shared folders, Agents etc. An even better approach is to not give users higher than Author ACL access, then user AUTHORS fields on documents to enable them to edit the documents they need to, when they need to (change the AUTHORS field contents based on stage in a workflow etc.), but now I’m gettng off-topic!
Hth.
Subject: Assigning roles to servers
That’s a good point James. If I have a role that limits access I would be doing more harm. Thanks!!