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.
Solved! Go to Solution.
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.
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.
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?
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.
Thank you so much.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.