11-16-2017 03:50 PM
Hello.
We have some cases where users would like to be able to add an user as a member of a site, but this user should not be able to see all the documents by default, like the Consumer role.
The idea is to let such user to see only the "published" ones (defined by a property value or an aspect).
So, basically, a special Consumer role.
What I was considering, and this is where I am not sure if it is the best way to achieve it, is to create a new role called PublishedContentConsumer, and the read permission would be granted to the user only if the content has the aspect or the property set to a specific value.
Based on that, I would like to know if a Dynamic Authority would be the right way to implement this, or if I should consider another approach.
Some links I was reading:
Please, let me know what you think.
Any idea is welcome.
11-17-2017 03:32 AM
Why aren't you simply using the regular Consumer permission for that role (they still need to be able to navigate the structure). You can use behaviours that automatically set a Consumer=DENIED permission assignment on content items (documents), and which will react to the property/aspect change to remove the DENIED permission once the document is published.
No need to use a dynamic authority for this. It is important to note that using a dynamic authority for any permission that grants Read permission is potentially a bad for performance. The optimisations for ACL checking via SOLR may be (partially) negated when doing so, and searches become far slower as ACL checks are again performed after retrieving the results from SOLR. For a while now SOLR has also been tracking and using static DENIED permissions to filter results correctly, so there is no such problem when using regular DENIED permission assignments.
11-17-2017 03:32 AM
Why aren't you simply using the regular Consumer permission for that role (they still need to be able to navigate the structure). You can use behaviours that automatically set a Consumer=DENIED permission assignment on content items (documents), and which will react to the property/aspect change to remove the DENIED permission once the document is published.
No need to use a dynamic authority for this. It is important to note that using a dynamic authority for any permission that grants Read permission is potentially a bad for performance. The optimisations for ACL checking via SOLR may be (partially) negated when doing so, and searches become far slower as ACL checks are again performed after retrieving the results from SOLR. For a while now SOLR has also been tracking and using static DENIED permissions to filter results correctly, so there is no such problem when using regular DENIED permission assignments.
11-18-2017 12:17 PM
Yes, that is an idea, but I have a small different scenario here, that I believe I haven't made clear enough.
There are going to be 2 different groups of Consumer users, the first one, the "normal" consumer, that can see every single document inside the site, and the "External" consumers, for who I want to restrict the access until the documents are considered ready.
But now, thinking about your suggestion, I thought about something like:
Site_siteConsumer
UserA
UserB
Group_ExternalConsumer
UserC
UserD
Following your idea, I believe I can set the DENY only on the group ExternalConsumer.
I just have to test to make sure the DENY will win, even if the user being also a "normal" consumer, but I guess what is going to define the behaviour is the security.anyDenyDenies=true config.
Am I right?
11-20-2017 04:10 AM
Technically, this should work even without security.anyDenyDenies - AFAIK the security.anyDenyDenies is mostly relevant if you have a dynamic auhority related to the DENIED permission. ACL checks on the Repository tier definitely will let a DENIED on a specific ACL win over an inherited permission. I am just not 100% sure over SOLR checks - here the security.anyDenyDenies=true will make sure that any search result is post-processed with Repository-tier ACL checking.
11-20-2017 01:49 PM
Thank you so much.
Explore our Alfresco products with the links below. Use labels to filter content by product module.