Welcome to the #dominoforever Product Ideas Lab! 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 jointly by the IBM & 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.


Hide fields in properties box

By using hide options on a form, you can hide sensitive info for specific users. But this is of no use if that user can read field data using the properties box.
Have an ACL option to determine who can see field data in the properties box.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jul 18 2018
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    18 Jul 09:03

    Using simple hide options on a form is not a security feature. If you want to prevent users from getting access to specific data in document, you can do that by using encrypted fields.

    See https://www.ibm.com/support/knowledgecenter/de/search/encrypting%20documents%20and%20fields?scope=SSVRGU_9.0.1

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    23 Jul 07:14

     

    Encryption has its limitations:

    - mixed environments: encryption is not fully supported in browsers

    - you cannot use multiple encryption keys on one document (e.g. encrypt section depending on user role)

    - it can get tricky if data must be available depending on the data on the document

     

    This request is not primarily intended for high security applications. Avoiding that people have direct access to data in 'hidden' fields just helps to not confuse/mislead users.

    Therefor I do not agree that this feature 'already exist'. Thomas, can you please remove that tag?

     

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    02 Aug 12:38

    At is simplest, an additional checkbox on the field properties (advanced tab) "Box Properties only viewable by Manager access"

     

    Encryption keys - not only the limitations already given but having to managing them!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    02 Aug 19:32

    If the user can open and edit the document, the user would be able to decrypt those fields as well, and thus they would show in the propertybox. Encryption does not help here.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    13 Aug 07:10

    WRONG TAG! THIS FEATURE DOES NOT EXIST!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    22 Aug 14:56

    I guess if you want to hide stuff in this manner without the limitations of using encryptions keys, you could build a more complex system that saves off the field data you want to hide to another form or a profile document and then remove the fields from the saved document.  When the document is opened for viewing or editing again retrieve the field content from the secondary source(s) and repeat the exercise when the document is saved again..

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    29 Aug 16:54

    This feature does NOT exist. The majority of the apps I develop are web-based apps. We don't use encrypted fields, because most of those clients do not want to deal with maintaining private keys and Notes IDs when Notes clients don't exist. However, I can see this desired when you have a mixed use environment. If I want to hide data, I have to make sure I structure the design of the app so that "private" data are in embedded views in "child" docs. That way I can use Readers and Authors field. However, clients don't always want that structure/model of child documents and they don't understand when you say, that's they way it is unless you want keys. They all want their cake-and-eat-it-too. I don't "need" this feature, but the feature would be useful to me, and it's disingenuous to say that it "already exists".

  • Admin
    Thomas Hampel commented
    27 Oct 12:20

    Ok, based on your feedback changing the status of this idea from "already exists" back to "Needs review"