1 person found this helpful
You can give component level permission via going to "users" section afte login into CQ console. please refer http://dev.day.com/docs/en/cq/current/administering/security.html for more information. It has detailed out everything related to permission. Please let me know if face any issue.
1 person found this helpful
On a JCR level this is easily possible, as you can set ACL on every node you want. And your component is also "only" a node. CQ5 itself is not designed to support component level security ootb, the smallest entity you can set ACLs on are pages. The useradmin does not support a granularity of components.
So, as a recommendation: Do not try to implement component-based security. Because you will run into problems you need to handle:
* Maintaining ACLs on components (no UI available for this ootb)
* The editmode is not built to handle write-protected components.
I do not say it's impossible, but to really make it work, you need to spend time and experience to tune the UI for this usecase.
I think it is viable to set ACL at component level as far as authoring is concern, of course you can not do it at component instance level because CQ suppport page centric framework and everything you have to dealt with is page only.
As Jorg stated, Group ACL settings are meant to control access at a page
level. As he also stated is possible to control access even further, but
with additional effort and difficulty. But, nearly every client wants this
done down to the component level and on a group by group basis. So, what
I've found, over the years that works is the following:
- Configure the available components per template type per parsys
- Further configure the available components at the group level
For the custom built components, you can remove them at the group level by
un-checking the 'read' ACL on the dialogs for the given component. You
don't want to un-check read for the whole component because then the users
of that group experience random 'holes' in the content. But, if you
un-check 'read' for the dialogs, then the component will not display in
Side-kick (at least on 5.4 and prior this is the case).
The only caveat to this is the OOB components. That is where you will run
into a lot more difficulty. Those should mostly be enabled/disabled at the
design level for the entire page/parsys.
Hope this helps.
When you remove read then it does not display in sidekick (CQ5.5 ) as well. Thanks for information
I haven't had this requirement that often :-) Nevertheless, if the customer is interested in "Adobe best practices", component based security is not part of it.
I just see, that I was referring to a different usecase: applying ACLs to a component within a page, not limiting the usage of a component to certain groups. But both cases are not really in line with the product philosophy.
I agree 100% with you regarding standards and best practices... But, this
is commonly requested from clients as early as the pre-sales cycle. Thus,
it permeates all the way through to the delivery/go-live phase and has
touch points with everything from template and component development to
users, groups, and system administration.
As you said, "I do not say it's impossible, but to really make it work, you
need to spend time and experience to tune the UI for this usecase."