#dominoforever | Product 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

Add a "No-Access" Field type to complement Readers/Authors field types at the document level

Document access rights are generally given on a group list or role basis. However we have frequent situations where a member of a group must be excluded (as an exception) to an individual document.  The current design being assume no access unless listed, creates a real headache when you generally want to grant access but have exceptions.  Breaking the group list down to individual members creates an extreme maintenance burden and loss of the dynamic membership provisions afforded by group lists.

There have been comments suggesting use of view formulas with an exceptions list to restrict access. It is worth mentioning that if a person generally has author or higher ACL in a database and is listed in the Readers field as a member of a listed group...there is little problem using backdoor processes to gain access.  Such as private views, ODBC/Notes SQL, private actions/agents.

The requested feature is both to ease development efforts as well as effectively tighten security of sensitive information without significant impact on the design of Domino

The ACL model at the database level is great for general access rights. However the model breaks down on the individual document level, when there needs to be exceptions to the general rules. 

  • Guest
  • Feb 13 2019
  • Under Consideration
  • Attach files
  • Guest commented
    15 Feb, 2019 04:57am
    "That is something that can be achieved with readers. Basically the above means that only people on that list is allowed."
    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.

    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

  • Guest commented
    14 Feb, 2019 05:14pm
    You can hide the database 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.

    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

  • Guest commented
    14 Feb, 2019 05:08pm
    "That is something that can be achieved with readers. Basically the above means that only people on that list is allowed."

    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.

  • Guest commented
    14 Feb, 2019 11:32am

    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.

  • Guest commented
    14 Feb, 2019 04:37am
    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.

    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

  • Guest commented
    14 Feb, 2019 01:51am

    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.

  • Guest commented
    13 Feb, 2019 03:45pm

    Could you not use the QueryOpen event to check the current user against a barred list?