Image may be NSFW.
Clik here to view.
Recently we were asked a question about workflows: “Can a user start a workflow on Assets/Pages on which he has only read permission? Could you please help as in how can we restrict user from invoking workflow for which they have only read permission?”
Obviously, the answer to the first question is yes. If they have read permissions to a page, they can put that page into a workflow. Any user who has read permissions to a page or asset who also has permissions to use workflows can put that item into any workflow. The second question gets a bit more complicated.
To give users who only have read access to content the capability to user AEM workflows you simply need to place that user into the following OOB(out of the box) group: workflow-users. If an AEM user is not in this group, they will not be able to start any workflows.
If you want to restrict which users can use specific workflows, then that problem requires additional groups to be introduced and configured. First, start by creating a group that other groups would belong to. In this example I will call this group aemproject. This group would deny access to all workflow models that you desire to restrict from all users on the platform. These permissions can be found at: /etc/workflow/models.
Image may be NSFW.
Clik here to view.
The key to making this all work is to have every group inherit from this parent group.The foundation for this solution is to utilize the hierarchy capability of permissions. We would introduce a group called aemproject. It would have high-level read access to the models so that a user can access the workflow models. You can almost imagine this group acting like a gatekeeper.
You should then create the aforementioned other groups. For this example, I am calling this group activateusers. The activateusers Author will automatically be blocked from starting any other workflow models because it inherits the denied read access from the aemproject group. Next, we need to edit this groups read permissions under /etc/workflow/models to allow them to use the desired workflow model. In this example we are giving the author read access to the request for activation workflow.
Image may be NSFW.
Clik here to view.
If any of this sounds familiar, then you probably read our article already about setting permissions here. In that article, I describe this solution with greater detail how to restrict read access to specific places in the JCR. This strategy outlined in this article is literally the same approach you would take to restrict content for different authors using the same AEM platform.
