I have a time sheet application where I use Author and Reader fields to keep things restricted. Users use local replicas of the database.
My manager removed a person from our system using AdminP and selected the “remove from author & reader fields” option. This removed the only name in a set of time sheets revealing those time sheets to everyone.
I quickly wrote a script to repopulate them with an updated user.
THE PROBLEM: Many users replicated before I caught this and brought down the set of time sheets to their local replicas. After I updated the documents, the set of documents on the local replicas are not being updated (or removed as I had thought they would be).
Subject: RE: Just an Idea for the future. You should always include an “Admin” role in the ReaderNames field.
Actually, I’d put it in an Authors field, Bill, and keep it there at all times. To make a document all-access, you’d need to clear all Readers fields, including the Admin role. If a user then sets the “Who can read” property through the dialog, Admin loses access. If the value is in an Authors field, it never has to be touched, and only deliberate actions on the user’s part can cause problems.
Subject: yep are calculated author field with a [admin] role you assign to admins and servers is the best way
actually reader fields are internally stored with the ITEM_READERS flag
author fields are internally stored with the ITEM_READWRITERS flag
so a author name always counts for read access but reader fields only count if at least one not empty field is present
Having a admin role computed is an excellent way to go but best practice would also be to have a real author field that contains the “owner” or the document and maybe also additional author fields containing the organizational owners (in this application) of the document.
In a good application standard users have author access only and can only modify their “own” documents. This needs author fields… Power user could be editor of the database and modify all documents.
Take care there is dangerous gap (IMO this is not a bug).
If you are author in a database and can delete documents and you are editor in the database without delete documents you can still delete all documents because the highest access right always counts and the user roles and acl flags like delete are additive!
Subject: RE: yep are calculated author field with a [admin] role you assign to admins and servers is the best way
You wrote: “In a good application standard users have author access only and can only modify their “own” documents.”
That depends entirely upon the application, and the function of a document or set of documents within that application. The point of putting admin readers in an Authors-type field is that access can never accidentally be removed from the admin readers (a problem if the $Readers field gets set by any user). At the same time, putting the admin role in an Authors field cannot remove read access from any other user.
The reason for including admins is not the urgent matter it was before full access administration rights were added to the Notes world, since a full access administrator can view and repair documents that would ordinarily be hidden from him by one or more Readers fields.
Subject: this is still needed even with full access administrator…
What about replication? Reader fields are also used for replication if you have documents where the server has no access they will never replicate. So a Admin/ReadAll role is still needed and using a calculated author field with a role is a nice way to get this working.
For applications you are right. No every application will need this but it is best practice to start with author fields from the very beginning. For Notes applications you never know how big they get once the user started to have crazy ideas. If you do your basic design once and have always a author field from the beginning this can make your life much more easier. And you never have to change or convert existing data. Plus admis always know who owns the documents (since $UpdatedBy can also be limited in the properties and this is an internal field that should not be used for application level tracking – you should have a author field reflecting the owner of a document). I don’t say you have to but it is still good practice IMO.
Subject: RE: yep are calculated author field with a [admin] role you assign to admins and servers is the best way
I have two author fields that were on these documents that had group names in them (one for the admins of the application and the other with LocalDomainServers in it).
Subject: groups are not changed by adminp in the documents only direct entries of names…
the best way to go is to have a role in the application. that makes you completely independent on anything in the directory.
The developer makes sure there is a [Admin] or [ReadAll] role and the admin assigns it to the right group in the productive system. That’s specially important if you do commercial development and have no idea what groups your customers have in their environment and it makes you totally flexible.
I really like the concept of roles in domino. you can also assign author rights to people with certain roles in the database this way.
I wrote a tool to scan and fix certain problems in Notes database this includes problems like the NoName items problem (item without a name that can cause the server to crash in some releases) or the problem where reader and author fields without the summary flag set cause document not to be readable any more in Domino 5.0.10 and higher (security fix see (Technote #1088956, SPR #MGAN5C7SD9)
I am thinking about a tool that checks a whole database for documents with reader fields which have not the right permissions for servers to replicate them.
The logic would be
take the actual server name
check all group and role membership for this server
loop thru all documents and check if the user is listed in the reader fields if a not empty reader field is present
OR open with full permissions first and than use another database handle and check with restricted permissions while looping thru all documents with full local access.
This would produce detailed lists (already ready to go from another tool called nshdst a Daylight Savings fixup servertask). The whole stuff would be an add-on to this existing tool and not really much extra work.
Do you think this reader-names-replication sanity check tool would make sense?
Subject: RE: Just an Idea for the future. You should always include an “Admin” role in the ReaderNames field.
There’s a nice trick to doing that, which relies on the fact that Reader or Author fields concatenate.
If you have more than one Reader or Author field on a form, then they are all treated as one single field by the system. So if you want an Author’s field that is editable by the user, but you want o make sure that you can’t get locked out of that document, the trick is to create two of them.
Make one a standard editable field. Let the user play with that one.
Make the other a hidden, computed field, with a Value formula like:
@If( = “”; “AdminGroup:LocalDomainServers”; “”)
Of course, you can make it so that the field always contains those values, or whatever suits your needs.
(I know I’m teaching you both to suck eggs Bill & Stan, but it’s a good trick for the beginners)
Subject: RE: Just an Idea for the future. You should always include an “Admin” role in the ReaderNames field.
You may be telling me to suck eggs, Stephen, but you’re teaching me nothing. What if the user sets the $Readers field using the security tab of the document properties? That can be done without invoking the form, let alone putting the document into edit mode. An admin value in an Authors field prevents that eventuality – a user would have to “wilfullly and with malice aforethought” alter the value of that Authors field in order to remove “normal” admin access. Once the document had been recovered usng full access admin rights, that user could be disciplined in whatever manner happens to be legal in the jurisdiction.
Subject: RE: Just an Idea for the future. You should always include an “Admin” role in the ReaderNames field.
An admin value in an Authors field prevents that eventuality
Exactly the point I was making Stan - that a hidden, computed Authors field would make it impossible for a user to deliberately make a doocument unavailable.
That’s also what I meant by the ‘teaching you to suck eggs’ comment - I assumed that you knew all this far better than I do, and that I didn’t post it trying to teach you anything. I doubt there’s anything in the Notes field that I’m capable of teaching you
Possibly a difference in idiom - I wasn’t telling you to suck eggs, I was making a reference to ‘teaching your Grandpa to suck eggs’. My bad…
Subject: RE: Just an Idea for the future. You should always include an “Admin” role in the ReaderNames field.
We are, as was once noted, separated by a common language, I’d say. Here in Canada, we have phrases that don’t survive translation from province to province, let alone transcend national boundaries. No offence taken, since I’m absolutely sure there was none intended.
I’ve made a habit, now, of including a non-conditional Authors field with an admin role on everything because of that accursed (pronounced, if you please, with a full syllabic accent on the “ed”) properties dialog. The user who started this was kind enough to include the Notes administrators in a set of documents, but refused access to our servers. You can have no possible idea how much time I (as at the time less than conversant with access control fields) spent trying to track down the seemingly random bugs that it caused.
Subject: RE: Just an Idea for the future. You should always include an “Admin” role in the ReaderNames field.
I have to admit that I had completely overlooked the ability to change things via the Properties box. I’m guessing that it would block out access even if there wasn’t an Authors or Readers field on the document in the first place?
Thanks for that Stan - I’ll add it to my list of gotchas.
