[DAM] How to allow Asset properties edition based on user roles?

[Julio_Baixauli]

Hi!

That's it. I would like to allow Asset properties edition based on user roles

For example, I would like to allow all image properties edition to 'authors_groupA' users group, but deny 'Description' changes (allow the others) for 'authors_groupB' users group.

I would like to do this in both classic UI and Coral UI, in the standard DAM interface (no custom WCM pages).

Thank you very much! Any help will be appreciated!

[smacdonald2008]

For this use case -- it sounds like you will have to use sling's Access Control Management. Here is a good piece of content to get you started:

Access Control Management @ http://www.day.com/specs/jcr/2.0/16_Access_Control_Management.html

[Julio_Baixauli]

smacdonald2008 wrote...

For this use case -- it sounds like you will have to use sling's Access Control Management. Here is a good piece of content to get you started:

Access Control Management @ http://www.day.com/specs/jcr/2.0/16_Access_Control_Management.html

Thank you for your comment smacdonald2008. I know about JRC permission management, and how CQ (and DAM) uses it (/useradmin). I can restrict access to a DAM folder based on user roles, but this use case is a bit more complex, because I would like to restrict access to a metadata of many assets in DAM (a properties of many nodes in the JCR). I think the solution will be at higher level than the JCR level (DAM application level).

Also, I know how to hide a metadata in the asset editor [1], but not how to allow only read access.

I was thinking in a solution related with standard DAM configuration, maybe modifying some metadata nodes in JCR, extending DAM components (asset editor) in /apps, or so... But I've no concrete idea.

I would like to use the standard DAM with a custom configuration related to user roles, as my customer only has a DAM license (no WCM license).

[1] http://stackoverflow.com/questions/8165800/cq5-hiding-a-tab-within-a-component-dialog-depending-on-u...

[Julio_Baixauli]

Up!

[Ove_Lindström]

Julio Baixauli wrote...

Up!

Don't do that... it's rude and generally won't help your case.

But to answer your question: No, there is no easy way to use the ACL to restrict subsets of the properties, since they are not nodes. However, you can create your own properties editor that checks the different roles and toggles the edition based on that. To do that, use the ordinary properties editor from the DAM and add your ACL-based code.

[Julio_Baixauli]

Thank you Ove. I'm sorry. Is there any way to be more polite and let know to the forum that I'm still interested in a question previously posted?

Thank you for your response to the question. I'm still investigating.

Best regards,

[Julio_Baixauli]

I've found a possible solution. It's partially based on [1].

The solution is:

• add a custom property (like 'allowedRoles' or something else) in metadata nodes to distinguish different behavior (for example, to nodes under /apps/dam/content/asseteditors/image/jpeg)
• add code in /apps/dam/widgets/source/widgets/AssetEditor.js to apply readOnly, based on previous point and on user roles. Here, the key point is the 'config.formItems' input parameter, that includes the form fields and the properties of metadata nodes (so, the custom property added in the first point). You can apply formItem.readOnly to true based on your requirements.

This allow you to parameterize the solution (in custom properties), so no code modification is needed if you need to change the roles that can edit a metadata.

Hope this helps.

[1] http://stackoverflow.com/questions/8165800/cq5-hiding-a-tab-within-a-component-dialog-depending-on-u...

[Ove_Lindström · Accepted solution]

Yes, sorting properties into different tabs and hiding them for some users might work, but the users could still be able to alter them in other ways. But users with that sort of knowledge would most likely have sufficient rights anyway. Right?

However, it might become harder for the authors to use the system if you use to many tabs. We have actually used this technique in dialogues where we have hidden things like advanced properties, tracking tabs and other stuff the normal author should not alter.