nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Temporary hide documents

jpfi

Hi folks,
I'd like to achieve the following behaviour:

- Temporary hide documents for all users that only have read-permissions on the documents - user with at least write perms should still be able to access the document.
- The documents should be hidden independent from the way accessing (Share, WebDav, Navigation(DB), Search (Solr))

My ideas/approaches:

A. disable inherit permission if a document is hidden & remove all read-permission entries
Problems: there is no OnPermissionUpdatedBehaviour where i can track permission changes, e.g. if the ACL on the parent folder was modified & the private permissions of a hidden document must be updated also.

B. Use deny-permissions - Just add "read-denied" permissions to temporary hide a document.
Problems: Denied Permissions are not indexed in SOLR - thus I'll have to filter search result sets manually - huge performance impact. Besides Share's permissions dialog/webscript doesn't support denied-permissions & switches all "denied" entries to "allowed" ones when changing the permissions…

C. Use Dynamic Authories to achieve the desired behaviour.
Problem: Also gonna be a huge performance impact.

My question: Did I miss an approach or any useful details?

Cheers, Jan

Find more posts tagged with

Comments

cleseach

Hi Jan,

Not sure it's a possible solution, but there is a "sys:hidden" aspect :

<!– aspect to tag hidden nodes –>
      <aspect name="sys:hidden">
         <title>Hidden</title>
         <!– Explicitly turn off archiving for all nodes with this aspect –>
         <archive>false</archive>
         <properties>
             <!– A bit mask encoding whether clients (such as CIFS, WebDav, Share, …) can see the node –>
            <property name="sys:clientVisibilityMask">
               <type>d:int</type>
               <mandatory>false</mandatory>
               <default>0</default>
            </property>
         </properties>
      </aspect>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Let me know if it fits your needs.

Best regards,
Charles Le Seac'h

jpfi

Hi Charles,
thx for your reply. using such an aspect would do the job if I'd like to hide the document for all users.
I would like to hide the document for all users that normally would have read permissions - all users having at least write permissions should still be able to access the document.
Cheers, Jan

tommorris

Hi Jan,
Sorry - I didn't quite understand your comment:
"e.g. if the ACL on the parent folder was modified & the private permissions of a hidden document must be updated also.".
So what if the ACL changes on the parent folder? You've broken inheritance, so you still keep the document's specific permissions.

jpfi

Hi tom,

let's take the following scenario:

Folder A
|
- Document X

Folder A has a typical Share-Site ACL like & Document X inherits permissions:
Group_SiteABC_SiteConsumer = SiteConsumer ALLOWED
Group_SiteABC_SiteCollaborator = SiteCollaborator ALLOWED
Group_SiteABC_SiteManager = SiteManager ALLOWED
….

Now, i'd like to hide Document X for all Consumers, so I disable the inheritance for document X & document X has the following ACL
(Group_SiteABC_SiteConsumer = NONE)
Group_SiteABC_SiteCollaborator = SiteCollaborator ALLOWED
Group_SiteABC_SiteManager = SiteManager ALLOWED
….

but, if now someone updates the permissions of Folder A - e.g. Group_SiteABC_SiteCollaborator=SiteConsumer ALLOWED, then I've to update the ACL of document X also to (but there is no ~onACLUpdateBehaviour):
(Group_SiteABC_SiteConsumer = NONE)
(Group_SiteABC_SiteCollaborator = NONE)
Group_SiteABC_SiteManager = SiteManager ALLOWED

If I could use denied-permissions then I could still inherit permissions. in our last example document X would have the following ACL:
Group_SiteABC_SiteConsumer = SiteConsumer ALLOWED (inherited)
Group_SiteABC_SiteCollaborator = SiteConsumer ALLOWED (inherited)
Group_SiteABC_SiteManager = SiteManager ALLOWED (inherited)
Group_SiteABC_SiteConsumer = SiteConsumer DENIED
Group_SiteABC_SiteCollaborator = SiteConsumer DENIED

Cheers, jan

tommorris

Oh I see! Yes that is a tricky.

I think what you're saying is:
1) You've denied the consumers-group access on a particular document.
2) Then you subsequently decide that the collaborators-group should also not have access.
3) …but not just denied for that one document, but for all documents in that folder.
4) …however since permission inheritance is broken, that single document still remains visible to the collaborators group.

Yes, we too normally use the very useful, (but not widely known) 'deny-permissions'. But we've yet to do this on a v4/Solr installation, so were not aware that Solr doesn't respect them (thanks for the info).

Does the search result set generate a permissions error when trying to generate the HTML/JSON rendition?

Have you raised a Jira defect for this?