HCL Domino Ideas Portal
Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
Ah, now I see. So the user to be denied already have access because they belong to a group listed in the reader, right ? IMHO I still think that your example is somewhat misleading but I now understand what you mean.
Yes, in that case a deny list would be the answer. Assuming of course that deny take priority over allow, which I think is the "expected behaviour".
Tinus Riyanto - Prisma Global Solusi
Yes those techniques are part of our current solutions, but adding formulas to views, QueryOpen, and other routines we have had to implement is a lot of motion and overhead to the application and system ... which is completely unnecessary to add a single acl related field type.
To move forward into a better more productive future... I have proposed the new field type
You have missed the point. The individual is part of a team of workers that normally would have access to this given types of documents / information.
There needs to be an easy preemptive way to designate exceptions to the group list that have no access. When readers has a list of specific named individuals there is a maintenance problem for new members of the team being able to have automatic access based on normal rights.
Our current implementation does exactly that in breaking/expanding the group into named individuals on the readers field, So we end up with a large number of authorized people listed to remove 1 individual. Then when the group changes, the individual documents with these exceptions must be updated with new/removed members in bulk. Instead of simple change to the group list.
You can hide the databse design so the properties box is not displayed. Also, if you store the barred names in a names field on the document, you can manipulate the view so that the name reads <Name Witheld> if the person viewing is in the barred list.
That is something that can be achieved with readers. Basically the above means that only people on that list is allowed.
I think what your idea would probably something like a blacklist for a place / event. Everyone that can go there can enter, except for the following people of the list.
Tinus Riyanto - Prisma Global Solusi
QueryOpen does not prevent document being displayed in views or person being able to use properties box to view document data. Dealing with Protected Health information. There can't be any disclosure of any kind in this situation. A "barred" person merely knowing there is information in the system for the other party can also be viewed as a breach/unauthorized disclosure. Lets say you are a government official or celebrity ... would be very interested in limiting the number of people that know you are receiving certain types of treatment. etc.
Could you not use the QueryOpen event to check the current user against a barred list?