Usability - Productivity - Business - The web - Singapore & Twins

NoReader and NoAuthor Fields

Access control in Lotus Notes and Domino is build around the concept of positive identification, meaning you specify who can read or edit by naming them explicitly or implicitely as members of a role or group. What you can't do is to say: Everybody except these people (or all members of group A but not when they are members of group B). We don't have PreventReader or PreventAuthor fields (which would come in handy from time to time). The only construct is the the -No Access- setting in the ACL which has the highest priority.
For web applications there is actually a way how you can implement a PreventReader form (must be web only). You have to be clear that is is NOT a watertight method and can be compromised given enough effort. However it is good enough for most requirements (It doesn't work in Notes clients). These are the steps:
  1. Create a Names field that will hold the entries that can't read an entry (call it PreventReader)
  2. Design all your views to only contain hidden columns
  3. Create $$ViewTemplates for [ViewNames] form with no embedded view, no $$ViewBody fields, but a Body RichText field and a SaveOptions field, Computed, Formula "0"
  4. Create a webqueryopen agent (with a little creativity you can get away with one agent and one form) that prints the columns you want to display into the BODY field. The logic that prints the lines needs to be extended to skip printing when the @UsersNamesList contains a value from the PreventReader field. Since the view columns are otherwise hidden even ?ReadViewEntries wouldn't reveal a thing.
However a user could open a direct link to the document. So there are a few additional steps required:
  1. Create one subform per form. Call them sf[OriginalFormName]. Cut & Paste the whole content short of the PreventReader field into the subform.
  2. Create one subform sfUnauthorizedAccessAttempt that has a nice message or throws the user back to the start-page and/or logs the attempt
  3. In the now almost empty main forms add a computed subform with the formula @if(@isNotMember(ReventReader;@UserNamesList;"sf"+form;"sfUnauthorizedAccessAttempt")
Now if a user gets a direct link (e.g. forwarded by an authorized user), the subform "sfUnauthorizedAccessAttempt" will load instead of the subform with the real data, so our excluded user has nothing to see.
As usual: YMMV.

Posted by on 15 April 2009 | Comments (4) | categories: Show-N-Tell Thursday


  1. posted by Elijah Lapson on Thursday 16 April 2009 AD:
    Wow very slickery. :)

  2. posted by Jan Schulz on Thursday 16 April 2009 AD:
    I had a similar requirement in Notes (allow author access or a group, but not for one person in that group: four eyes principle) and I used something similar: using @UserNamesList and setting continue to false in edit event...

    Also not watertight, but someone who is able to work around it might be "intelligent" enought to know why there is such a rule Emoticon smile.gif
  3. posted by Tim Rattray on Friday 17 April 2009 AD:
    You say "What you can't do is to say: Everybody except these people". What about having -=Default=-: Author, Group X: No Access. Or Joe Bloggs: No Access? When your name is explicitly mentioned, you get that level of access, no matter what your other group memberships...

  4. posted by Stephan H. Wissel on Saturday 18 April 2009 AD:
    @Tim: That works for the ACL for all document. What I meant was "except these people" on a document by document basis.