Document copy permission to authors?

[andre]

It seems that only user groups with the Editor role has permission to make a copy of a document:

Groups with the Author role does not have the option:

Is there a way to enable this for authors? While only copy is a current requirement for our authors, how would I enable move and rename of an unpublished document, if the need arises?

Other permissions around publish requests should remain.

EDIT: Currently using 12.3.0

[andre]

Our CMS users say that it is quite a common use case to be able to make a copy of an existing document to use as a starting point for a new one. I see their point.

Has no one else has to deal with this?

[jasper.floor]

I think most customers just have people with editor roles do this. At the moment I don’t think you can give this permission to authors without making them editors. The granularity of permissions in the Channel Manager is still quite rough.

[bcanvural]

From the default scxml configuration:

  <!-- the state copyable is only active for users which are editor (granted hippo:editor) -->

you can check this at /hippo:configuration/hippo:modules/scxmlregistry/hippo:moduleconfig/hipposcxml:definitions/documentworkflow

[jasper.floor]

Ah, sorry, for some reason I was thinking of copy page in the channel manager. It should be possible to grant copy permission on document level as @bcanvural says.

[bcanvural]

Quickly trying out granting hippo:editor to authors I found out that authors basically get editor privileges with this. This would be a difficult thing to achieve imo with just security domains configuraiton (also note that v14 is coming up, and the security domains will have to be migrated).
Perhaps a custom workflow action ? https://documentation.bloomreach.com/library/concepts/workflow/custom-workflow.html
Also see what the actual copy action does here:
/hippo:configuration/hippo:modules/scxmlregistry/hippo:moduleconfig/hipposcxml:definitions/documentworkflow/copyDocument

[ate.douma]

In the upcoming brXM v14 this will become supported out-of-the-box!
We’ve changed the set of permissions (and implementation) for content authors to also allow copy/rename/move/delete for unpublished documents. Only editors retain the permission for (de)publish.

[andre]

@bcanvural

From the default scxml configuration:

  <!-- the state copyable is only active for users which are editor (granted hippo:editor) -->

you can check this at /hippo:configuration/hippo:modules/scxmlregistry/hippo:moduleconfig/hipposcxml:definitions/documentworkflow

@jasper.floor

Ah, sorry, for some reason I was thinking of copy page in the channel manager. It should be possible to grant copy permission on document level as @bcanvural says.

@bcanvural

Quickly trying out granting hippo:editor to authors I found out that authors basically get editor privileges with this. This would be a difficult thing to achieve imo with just security domains configuraiton (also note that v14 is coming up, and the security domains will have to be migrated).
Perhaps a custom workflow action ? How to implement a custom workflow? - Bloomreach Experience Manager (PaaS/Self-Hosted) - The Fast and Flexible Headless CMS
Also see what the actual copy action does here:
/hippo:configuration/hippo:modules/scxmlregistry/hippo:moduleconfig/hipposcxml:definitions/documentworkflow/copyDocument

Thank you to you both. I will look into a custom workflow action.

@jasper.floor

I think most customers just have people with editor roles do this. At the moment I don’t think you can give this permission to authors without making them editors. The granularity of permissions in the Channel Manager is still quite rough.

I will however certainly try to convince our users to adopt a workflow where the editors copy the documents in the interim, while we wait for the release of 14.

@ate.douma

In the upcoming brXM v14 this will become supported out-of-the-box!
We’ve changed the set of permissions (and implementation) for content authors to also allow copy/rename/move/delete for unpublished documents. Only editors retain the permission for (de)publish.

Thanks for the tip, this is great news, looking forward to this.