How to do this in Notes

Posted on 2010-11-10
Medium Priority
Last Modified: 2013-12-18
I am trying to create what SEEMS like it should be a simple application in Notes.  The basic database is a one that holds documents related to safety metrics.  Each document has a category and a subcategory.  A simple Notes view can show the documents grouped by category and subcategory.

Where the design gets a bit difficult (for me anyway) is the security/access.  The user has requsted that the application be designed so that documents of each subcategory be visible to some users but not others and that they can modify that access on their own (without using the ACL). (Note that each category can have completely different subcategories.)

I have no idea how to design this.  I would use groups and roles in a relational database - enabling or disabling subcategories depending upon the user's membership in specific roles.  However, within Notes, I don't have access to functions like @UserNamesList and @DbColumns from within views to allow me to filter what documents are selected, so I'm at a bit of a loss.

I admit, I'm a little out of my element here.  Notes development is not my forte.  I've tried a number of approaches that just don't work.  My gut feeling is that I'm just not thinking about this problem from a Lotus Notes perspective.  

Does anyone have any suggestions how you might go about this or can you point me to some resource (book or website) that might explain how to do this in Notes?

Question by:jmgroft
  • 4
  • 2
  • 2
  • +4
LVL 22

Assisted Solution

Bill-Hanson earned 500 total points
ID: 34106661
For security, READERS fields are the only true answer.  Take a look in the documentation under the heading "Using a Readers field to restrict access to specific documents".

Basically, you'll just create a Computed READERS field that evaluates to a group name or role, etc...

Making it so the users can define their own access?  You're going to have to design a small mini-app just to handle that part.  Can't say what it would look like without knowing the details.

Expert Comment

ID: 34106800
Hi, I suggets you to create a configuration docs with users and roles so they can modify the access from this document and not from the Access Control List.

Then, create a script like this example i've found, but adapted to your problem, selecting only the subcategories as per notes user and then performing the appropiate selection formula. give me more details i'll give you som further help:

Sub Click(Source As Button)
Dim uiw As New NotesUIWorkspace

Dim uiview As NotesUIView
Dim uidoc As NotesUIDocument

Dim view As NotesView
Dim one As String
Dim two As String
Dim doc As NotesDocument
Dim formula As String
doc.Form = "Finance"

one=uiw.Prompt(Prompt_OKCANCELEDIT,"Geef de start datum in","Start Datum (DD/MM/YYYY) ","")
two=uiw.Prompt(Prompt_OKCANCELEDIT,"Geef de eind datum in","Eind Datum (DD/MM/YYYY) ","")

formula = | SELECT datum > [| & one & |] & datum < [| & two &|] & doc.Form = Form |

Set uiview =uiw.CurrentView
Set view =uiview.View
view.SelectionFormula = formula

Call uiw.ViewRebuild

End Sub
LVL 22

Expert Comment

ID: 34106854
Although that technically works, it violates just about every best practice concerning document security and view design.  It's a good example of what can be done, but not good in an enterprise environment.
What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

LVL 10

Accepted Solution

doninja earned 500 total points
ID: 34110537
If user access can be simplified to being that a user has access to documents in a whole catagory or not and there is no reason to have exceptions to this then you could use Directory groups to hold lists of users that have access to a specific catagory and allow certain people edit rights to these groups to manage the access.
This would be better than having to edit every document in a catagory etc.

Then use the Readers field solution from Bill and just have the filed Computed with a value of "SomePrefix-Catagory"

You can add ganularity if needed by including the sub catagory in the name or adding extra groups that might be an admin group etc.
readerfield:="SomePrefix-" & Catagory:"SomePrefix-" & Catagory & "-" & SubCatagory:[AdminRole]:"Local-Administartors-Group"

Expert Comment

ID: 34110866
fredniels answer is as Bill-Hanson stated definetely the wrong way...
it would actually require users to have designer rights (so they could modify the selection formulas on views, unless it's private views), so very bad

then it would mean that the seletion formula would change for every user which would mean each user changing it would change it for the other connected users to.

but to enhance Bill-Hansons proposal:
you could indeed, there I agree with fredniel, create configuration documents to setup a kind of "default" access, authors and readers, for the category/subcategory combinations.

ie. in the config doc you would have fields:
category/subcategory (or multiple values if required) and defaultReaders/defaultAuthors (but those fields would simply be "names" fields not real readers/authors fields

in your main documents you would then have 3 fields, actually 6, 3 per readers and 3 per authors (here only the readers are listed, apply the same scheme for authors):
defaultReaders: computed names field with values from config doc
additionalReaders: editable names field
docReaders (the way I usually name real readers fields): computed reader field: @trim (   @unique( defaultReaders : additionalReaders ) )

same for authors...

that way you give a "default" setup but you allow authors to give other users read or author access

you could even setup roles in the ACL and add those roles to certain config docs so you could easily use ACL grous assigned to those roles to modify basic access:
ie: [marketing], [engineering],[administration]  to give those roles read and/or author access to the relevant categories

author fields DO act as reader fields to! so if a user is in an author field but NOT in a reader field he anyway will see the document and be able to edit,
the general db access would then be: authors for everyone (in order that they can at least create documents)

if the whole thing is JUST about readers forget the part about the authors and simply apply it for readers but be aware of the fact that you should add a default as well (usually [Designer] : [Servers] and/or [Admin]) otherwise it can occur that no-one can see documents anymore under certain circumstances!
LVL 11

Expert Comment

ID: 34110921
need more info:
>  The user has requsted that the application be designed so that documents of each subcategory be visible to some users but not others and that they can modify that access on their own (without using the ACL). (Note that each category can have completely different subcategories.)

By visible do you mean not accessible at all just not seen in the view? What kind of access do additional users get?
(For a feel of the magnitude:  How many users?  How many roles?)

I think you need to look in the Designer help, especially the topic 'Application Design'.  Review the subtopic 'Creating a workflow application' also in Topic 'Application Management', review subtopic 'Application design element security', articles about readers and authorts fields.
Remember that to enforce access, normal users should have Author acces to the database.

Very handy references:
Lotus Notes client help, Domino Designer Help and Administration Help. You should peruse these, to get a feel where to look for stuff.
Lotus Domino Release 5.0: A Developer's Handbook: http://publib-b.boulder.ibm.com/abstracts/sg245331.html?Open
Domino Designer 6: A Developer's Handbook: http://publib-b.boulder.ibm.com/abstracts/sg246854.html?Open
Lotus Security Handbook: http://publib-b.boulder.ibm.com/abstracts/sg247017.html?Open
Lotus Notes and Domino Application Development wiki: http://www-10.lotus.com/ldd/ddwiki.nsf

Author Comment

ID: 34112082
Thank you so much guys.  This gives me a number of great ideas.  I'm going to look further into the reader/author fields.  I'm not familiar with those, but it just sort of 'feels' like the right approach from what I'm gleaning from your comments.  As soon as I know for sure, I'll flag a solution.

To answer the question about scope, there would be approximately 15 different roles and about 30 - 50 users.  The reason for the various roles is that there are about 14 different facilities that will be submitting information and an overall coordinator.  Users from the various facilities should be able to see each others documents, but only be able to update the documents for their own facility.  There are some additional documents (in a separate category) that should only be visible to the coordinator and the members of the facility that added them.

Author Comment

ID: 34112121
Oh and to answer the question about visibility - my thought was that they just wouldn't show up in the view for any user that doesn't have access.   I'm not sure its necessary to go to any extraordinary lengths to prevent a doc from being accessible.  I don't believe the info is quite THAT sensitive.  But I'm not averse to a simple solution that does both.
LVL 11

Expert Comment

ID: 34112621
I mentioned it because reader fields can have performance drawbacks (server needs to compute visibility) in large databases where only a small portion of the documents are visible to a user.

From your extra info, I would only put reader fields on the separate category.

I think you will be best served with assigning Author access for most users, and assigning roles to groups. When a user has a role which is in an Author field in a document, he can edit the document.  If not, he can only read the document.

Author Comment

ID: 34114088
That's actually the approach I'm taking now.  So far, it looks to be exactly what I needed.  I had actually already decided on the roles and groups, but implementing it was a challenge before I understood what reader/author fields were.  I'm coming from a relational & .NET background and many of the concepts don't translate well to Notes.

Thanks again.  I'll let you know how I make out.
LVL 31

Expert Comment

ID: 34146428
Bear in mind that Notes is NOT relational, so you may run into problems if the list of users in a particular set ever changes. To alleviate this, have a Group document created in the Domino Directory for each unique access combination (site, plus one for the central admin). Place the group name in the readers and authors fields. You shoudl come up with a naming convention, something like:


Author Closing Comment

ID: 35777803
It wasn't the solution that I was expecting, but I was brining a non-Notes mindset to a Notes problem.

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

How to install Selenium IDE and loops for quick automated testing. Get Selenium IDE from http://seleniumhq.org Go to that link and select download selenium in the right hand column That will then direct you to their download page. From that p…
IBM Notes offer Encryption feature using which the user can secure its NSF emails or entire database easily. In this section we will discuss about the process to Encrypt Incoming and Outgoing Mails in depth.
THe viewer will learn how to use NetBeans IDE 8.0 for Windows to perform CRUD operations on a MySql database.
The viewer will learn how to synchronize PHP projects with a remote server in NetBeans IDE 8.0 for Windows.
Suggested Courses
Course of the Month16 days, 17 hours left to enroll

864 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question