liferay workflow scripted assignment

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

03-tasks.markdown

Latest commit, file metadata and controls, workflow task nodes.

[TOC levels=1-4]

Task nodes are fundamental parts of a workflow definition. When you define your organization's business processes and design corresponding workflows, you likely first envision the tasks. As the name implies, tasks are the part of the workflow where work is done. A user enters the picture and must interact with the submitted asset. Users often take the role of reviewer, deciding if an asset from the workflow is acceptable for publication or needs more work.

Unlike other workflow nodes, task nodes have Assignments, because a user is expected to do something (often approve or reject the submitted asset) when a workflow process enters the task node.

Commonly, task nodes contain task timers, assignments, actions (which can include notifications and scripts), and transitions. Notifications and actions aren't limited to task nodes, but task nodes and their assignments deserve their own article (this one).

Check out the Review task in the Single Approver definition, noting that several <role> tags are excluded from this snippet for brevity:

There are two actions in the review task, both <notification> s. Each notification may contain a name, template, notification-type, execution-type, and recipients. Besides notifications, You can also use the <action> tag. These have a name and a script and are more often used in state nodes than tasks.

Assignments

Workflow tasks are completed by a user. Assignments make sure the right users can access the tasks. You can choose how you want to configure your assignments.

You can choose to add assignments to specific roles, to multiple roles of a role type (organization, site, or regular role types), to the asset creator, to resource actions, or to specific users. Additionally, you can write a script to define the assignment. For an example, see the single-approver-definition-scripted-assignment.xml .

The above assignment specifies that an Organization Administrator must complete the task.

The above assignment specifies that only the user with the user ID of 20156 may complete the task. Alternatively, specify the <screen-name> or <email-address> of the user.

The above assignment assigns the task to the Administrator role, then checks whether the group of the asset is an Organization. If it is, the Organization Content Reviewer role is assigned to it. If it's not, the task is assigned to the Site Content Reviewer role.

Note the roles = new ArrayList<Role>(); line above. In a scripted assignment, the roles variable is where you specify any roles the task is assigned to. For example, when roles.add(adminRole); is called, the Administrator role is added to the assignment.

Assigning tasks to Roles, Organizations, or Asset Creators is a straightforward concept, but what does it mean to assign a workflow task to a Resource Action? Imagine an UPDATE resource action. If your workflow definition specifies the UPDATE action in an assignment, then anyone who has permission to update the type of asset being processed in the workflow is assigned to the task. You can configure multiple assignments for a task.

Resource Action Assignments

Resource actions are operations performed by users on an application or entity. For example, a user might have permission to update Message Boards Messages. This is called an UPDATE resource action, because the user can update the resource. If you're uncertain about what resource actions are, refer to the developer tutorial on the permission system for a more detailed explanation.

To find all the resource actions that have been created, you need access to the Roles Admin application in the Control Panel (in other words, you need permission for the VIEW action on the roles resource).

• Navigate to Control Panel → Users → Roles.
• Add a new Regular Role. See the article on managing roles for more information.
• Once the role is added, navigate to the Define Permissions interface for the role.
• Find the resource whose action should define your workflow assignment.

Here's what the assignment's XML looks like:

Now when the workflow proceeds to the task with the resource action assignment, users with UPDATE permission on the resource (for example, Message Boards Messages) are notified of the task and can assign it to themselves (if the notification is set to Task Assignees). Specifically, users see the tasks in their My Workflow Tasks application under the tab Assigned to My Roles .

Use all upper case letters for resource action names. Here are some common resource actions:

Determine the probable resource action name from the permissions screen for a resource. For example, in Message Boards, one of the permissions displayed on that screen is Add Discussion . Convert that to all uppercase and replace the space with an underscore, and you have the action name.

Task Timers

Task timers trigger an action after a specified time period passes. Timers are useful for ensuring a task does not go unattended for a long time. Available timer actions include sending an additional notification, reassigning the asset, or creating a timer action.

The above task timer creates a notification. Specify a time period in the <delay> tag, and specify what action to take when the time expires in the <timer-actions> block. The <blocking> element specifies whether the timer actions may recur. If blocking is set to false , timer actions may recur. In a recurrence element, specify the recurrence interval using a duration and a scale , as demonstrated above. The above recurrence element specifies that the timer actions run again every ten minutes after the initial occurrence. Setting blocking to true prevents timer actions from recurring.

The above snippet demonstrates how to set up a reassignment action.

Like <action> elements, <timer-action> elements can contain scripts.

The above example isn't functional but it demonstrates setting up a <script> in your task timer. Read the Scripting in Workflow article for more information.

| Note: A timer-action can contain all the same tags as an action , with |one exception: execution-type . Timer actions are always triggered once the |time is up, so specifying and execution type of onEntry , for example, isn't |meaningful inside a timer.

Tasks are at the core of the workflow definition. Once you understand how to create tasks and the other workflow nodes and add transitions between the nodes, you're on the cusp of workflow wizard-hood.

• HIRING! CHECK OUR JOB POSTINGS

Assigning User Registration Workflow to an Organization Role in Liferay

by Ashok Neupane | Apr 3, 2018 | Blog , Digital Experience , Liferay , Liferay DXP , Portals | 0 comments

This article is intended to give you an overview of how can you assign a workflow task to organization role if the definition is applied to other than the organization site. You will need to know the basic concepts of Kaleo workflow in order to understand the concepts described here.

Before we get into the specific Liferay workflow scenario this blog is meant to address, let’s talk a little about Liferay workflow in general. Workflow in Liferay is most commonly used for blog posts, comments, wiki pages, message board messages, and user registration. In regards to Liferay content, workflow helps us to filter and monitor content before it goes live by assigning the task to a user or a role for the approval. The “out of the box” single approver workflow is most commonly used in Liferay. If the approver finds the content appropriate, they can accept the task, approve it, and the content is live. If the content is not appropriate, the approver can reject it. At that time, the workflow can do many things such as getting assigned back to the creator of the content. This helps maintain the integrity of the content within the site. Here are a few workflow scenarios.

Workflow assigned to a Regular Role

In a normal scenario, the approval of a workflow task is assigned to a regular role. This means every user in Liferay with that regular role has rights to accept the workflow task. This works well for organizations that have dedicated content editors & authors that work on many sites concurrently or if you only have one Liferay site. This is the most basic use case for managing content with Liferay workflow.

Workflow assigned to an Site Role

In another scenario, the content posted in a site is assigned to a site role. In this scenario, the workflow task can be approved/denied only by users who are the member of the same site where the content resides and have that site role. If other users have the same site role but are not the member of that Liferay site where the content exists, they will not be assigned to the workflow approval task. This was done intentionally to ensure only members of the site with the necessary role are assigned that workflow task. This works well if your content editors & authors have dedicated Liferay sites that they are responsible for maintaining.

Workflow assigned to an Organizational Role

The same principle applies to the organization roles as site roles. If the workflow assignment is set to an organization role, the workflow task will only get assigned to users with the specific organization role rights to accept the task and only if the workflow definition is applied to an application in an organization site. This is the less common scenario, I’d like to discuss further.

In this particular scenario, we would like to assign user registration workflow to be approved by the appropriate users within the organization the newly registered user is associated with. Therefore we need to assign the workflow task to an organization role even when the workflow definition is not in the organization site. The registration form will need to include some custom fields used to lookup the appropriate organization where they new user should reside. Then we need to assign the workflow task to the “Organization Administrator” role associated with that organization. There is no direct way to do this, but there is a workaround for achieving this goal.

First, you have to get the organization where the user should reside and where you want to assign the workflow task. We looked up the organization using custom fields on the registration form. For example, you can use a company name field & email address domain to lookup the correct organization in Liferay. Next, you need to add the user to the organization:

• The organizationPk is the primary key of the organization. This is the organization we will assign the user and it will be used for workflow assignment.
• The classPK is primary key of the context entry, which in this case will be the user’s primary key (aka userId).

Now to assign the task to an organization role, you need to get that role. But first, you have to set the group id of the workflowInstanceLink, workflowContext and serviceContext same as the organization’s groupId so that the organization role will get permission to view and approve the task:

The “rolesAssignment” attribute contains the role that should be assigned to the workflow task. We can now add the following in the scripted assignment of the task to assign it to the organization role even if the workflow definition is not in the organization site:

Liferay workflow is an efficient way to implement the approval based task to filter out the inappropriate content or users from your site. This blog post was written to show how can you assign the organization roles for approval of the workflow task even if the definition of the workflow is applied outside of an organization site.

If you have questions or need help, please engage with us via comments on this blog post, or reach out to us at https://www.xtivia.com/contact/ or [email protected] .

Additional Reading

You can continue to explore Liferay DXP by checking out Publishing Typed Content With Liferay DXP’s Asset Publisher for utilizing the Asset Publisher to publish typed content, or Introducing Speedray Architecture Pattern for Liferay DXP to learn about the Speedray Architecture Pattern, or The Top 10 New Features in Liferay DXP 7 from a functional perspective, or Top 5 New Features in Liferay DXP UI Development and Creating JAX-RS REST Services in Liferay DXP from a development perspective, or Top 5 DevOps Features in Liferay DXP from a devops perspective.

Submit a Comment Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Need more information? Let’s Talk Today!

Hear from our customers, learn more about.

Success Stories

• API Management
• Applications
• Business Intelligence
• Customer Relationship Management
• Cyber Security
• Data Management
• Data Science & AI
• Data Warehousing
• Digital Experience
• Dynamics 365
• Enterprise Information Management
• Headless CMS
• Liferay DXP
• Master Data Management
• Perspectives
• Software Licensing

Recent Posts

• MS Dynamics Implementation: A Guide to Avoiding Common Mistakes
• Salesforce Implementation: A Guide to Avoiding Common Mistakes
• Workato vs. MuleSoft: Which Integration Platform is Best for Your Enterprise?
• XTIVIA’s Picks: The Top 3 Features in Dynamics 365 Business Central

XTIVIA uses cookies to personalize content and ads. Privacy Policy

• Workflow Designer Overview

Creating Workflow Tasks

• Configuring Workflow Actions and Notifications
• Workflow Nodes
• Using Forks and Joins
• Using Condition Nodes
• Assigning Task Nodes
• Workflow Transitions
• Process Automation
• Designing and Managing Workflows
• Workflow Designer

Subscription

The default Single Approver Definition offers a simple introduction to workflow tasks. It has only two task nodes: Review and Update. The workflow enters the Review node when a content creator submits an asset for review. In review, the asset can be accepted or rejected. If it’s rejected, the process moves to the Update task. The submitter can then modify the asset and resubmit it for review.

Task nodes are often the most complex parts of a workflow definition. They can have Assignments which can assign the task to users or a Resource Action (see Assigning Task Nodes ).

Task nodes also contain Notifications and Actions–both of which support workflow scripts . See Configuring Workflow Actions and Notifications .

When the review is finished and the approved transition is triggered, the workflow advances to the next node. In the Single Approver process, it moves to the Approved nd node.

Creating the Single Approver Workflow

You’ll create the workflow in 4 steps:

• Create the workflow and give it a name
• Create the Review node
• Create the Update node
• Configure the End node

Creating the Workflow

• Go to the Global Menu → Applications → Process Builder.
• Click the Workflows tab.

• Give your workflow a descriptive name, like My Single Approver.

Creating the Review Node

In the workflow designer Canvas, if there’s a transition connecting the Start node and End node, delete it: select it with your mouse and hit the Delete key on your keyboard.

Drag and drop a Task node onto the canvas.

Connect the Start node to the Task node by making sure no nodes are selected and then moving your pointer to the edge of the start node. When the cursor changes shape, you can click and drag a transition from the Start node to the Task node.

Select the transition and rename it Review .

Click the Task node to begin updating its properties.

Give the node a name: Review .

Add a Notification:

• Name : Review Notification
• Template Language : Freemarker
• Template : Enter this Freemarker notification: ${userName} sent you a ${entryType} for review in the workflow.
• Notification Type : Select Email and User Notification in the multiple select field.
• Execution Type : On Assignment
• Recipient Type : Task Assignees

Add another notification:

• Name: Review Completion Notification
• Template Language: Freemarker
• Template: Enter this Freemarker notification: Your submission was reviewed<#if taskComments?has_content> and the reviewer applied the following ${taskComments}</#if>.
• Notification Type: Email
• Execution Type: On Exit
• Recipient Type: Asset Creator

Add the Assignments . You can assign the review task to a Role, Role Type, a specific User, or a Resource Action. In this example, assign the review Task to a Role Type. Select these Roles, clicking New Section each time you must add a new Role:

• Asset Library Administrator
• Asset Library Content Reviewer
• Asset Library Owner
• Organization Administrator
• Organization Content Reviewer
• Organization Owner
• Administrator
• Portal Content Reviewer
• Site Administrator
• Site Content Reviewer

If you select Auto Create, a Role that doesn’t currently exist will be auto-created when the workflow is saved. For more information about Roles and Permissions, see Understanding Roles and Permissions and Assigning Users to Roles .

Click the End node and rename it to Approved .

Connect the Review node to the Approved End node. Name the connector approve .

This Task node is now configured; it sends a notification that a submission is ready for review to those Users assigned to a specific Role.

You can also assign the Task node to a Resource Action instead of another user or a Role Type. To learn more see Assigning Task Nodes .

Create the Update Node

Drag and drop another Task node onto the canvas.

Connect the review node to the new Task node by making sure no nodes are selected and then moving your pointer to the edge of the start node. When the cursor changes shape, you can click and drag a connector from the review node to the new Task node.

Select the connector and rename it reject .

Give the node a name: Update .

Now add a Notification .

• Name: Creator Modification Notification
• Template: Enter this Freemarker notification: Your submission was rejected by ${userName}; please modify and resubmit.
• Notification Type: Select Email and User Notification in the multiple select field.
• Execution Type: On Assignment
• Recipient Type: Task Assignees

Click on Assignments . Select Asset Creator .

Now add Actions :

• Name: reject
• Template (Groovy): import com.liferay.portal.kernel.workflow.WorkflowStatusManagerUtil; import com.liferay.portal.kernel.workflow.WorkflowConstants; WorkflowStatusManagerUtil.updateStatus(WorkflowConstants.getLabelStatus("denied"), workflowContext); WorkflowStatusManagerUtil.updateStatus(WorkflowConstants.getLabelStatus("pending"), workflowContext);
• Leave the rest of the defaults (e.g., Execution type On Entry ).

Make sure nothing is selected on the palette; move your mouse pointer to the edge of the update node. Drag a connector from the update node back to the review node.

Name the new connector resubmit .

Save the workflow definition.

• Click the Publish button to publish the workflow.

Now that you’ve walked through a workflow creation and learned how to use the workflow designer, look into adding node types that can take your workflow processes to the next level; such as Forks and Joins or Conditions .

Related Topics

• Activating Workflow
• Using Task Nodes

• Implementing Workflow
• Implementing a Custom SLA Calendar
• Crafting XML Workflow Definitions
• Using the Script Engine in Workflow
• Workflow Definition Node Reference
• Workflow Task Node Reference
• Workflow Notification Template Variables
• Creating a Condition Evaluator
• Creating an Action Executor

Working with Workflow Context

• Process Automation
• Developer Guide

Workflows in Liferay are used as approval processes. At each step of the process, the workflow has certain data that’s available in a Map<String, Serializable> object referred to in your scripts and custom code as workflowContext . The workflow context information is important to the proper functionality of Liferay’s workflow engine. Understanding it can help you determine how best to use it in your custom code and workflow scripts.

For example, with workflow context you can

• Access any of the existing attributes for use in workflow scripts, custom code, or FreeMarker templates.
• Set new attributes at one step of a workflow process for access in workflow scripts, custom code, or FreeMarker templates.
• Set ServiceContext attributes, access them in workflow scripts and notification templates.

Use ServiceContext to set attributes in contexts where a workflowContext is not available. For example, if your custom code calls BlogsEntryLocalService#addEntry , you must provide a ServiceContext object to it. You can use ServiceContext#setAttribute to pass in data that you want to access in the workflow.

There are some important things to be aware of when working with workflowContext :

It must be modifiable, therefore it isn’t thread safe. Caution is advised in parallel execution contexts.

For example, in a workflow with a fork node, updating the workflowContext in both forks of the workflow is not recommended.

Its first type parameter (the key for the attribute) is a String. This is used to look up the value stored in the second attribute.

Its second type parameter (the value for each attribute) is a Serializable because it’s stored in the database. This ensures that it’s accessible at every step of the workflow.

To print the workflow context keys and values in any workflow node, you can add a script action like this one:

When the node is entered, output is printed to the log:

Accessing Workflow Context Attributes in Workflow Definitions

To access workflowContext attributes form a <script> , retrieve them with the Map#get method:

The above example retrieves a String , but some of the workflowContext attributes must be used as long s (for example, when passed as method parameters). The GetterUtil utility class helps with this:

Using the WorkflowConstants object fields helps avoid error-prone String literals. The workflowContext fields are all prefixed with CONTEXT (e.g., CONTEXT_COMPANY_ID ).

Setting Workflow Context Attributes in Workflow Definitions

To set attributes into the workflowContext , use the Map#put method. This example sets the assetTitle :

The above code works only if the asset has a getTitle method (for example, JournalArticle ).

Setting Service Context Attributes for Access in Workflow Definitions

Sometimes in your custom Java code, you must pass information to the workflow definition but there’s no workflowContext to pass through. For example, if you’re writing code that adds Blogs Entries, you can call one of the BlogsEntryLocalService#addEntry methods. Even though workflowContext isn’t a parameter in these methods, ServiceContext is. Add a new attribute to the service context:

To get the attribute in the workflow definition, retrieve the ServiceContext from the workflowContext , the get the attribute using its key:

Related Information

Message Boards

• Development

How to assign Kaleo Workflow to User instead of Roles

• RSS (Opens New Window) (Opens New Window)

RE: How to assign Kaleo Workflow to User instead of Roles

Hi guys, This post helped me a lot. Now i would like to know how we can assign workflow to a user group? Thanks in advance

Initialise the property 'roles'.It should work. Add this to the groovy script roles = new ArrayList<Role>();

rino alias: Hi guys, This post helped me a lot. Now i would like to know how we can assign workflow to a user group? Thanks in advance

Hi Hitoshi , Can we assign Kaleo Workflow to User as well as group ??? 1 I am currently working on workflow task ,which I configure with Document and media portlet, My requirement is ,If User A Upload the document It should go to the User B. Which I assigned in definition file <user> <screen-name>User B</screen-name> </user> 2 User B will get notification and User B can able to assign this task to User C Which is belonging to the same group Then User C will get notification but User C not be able to assign to next person who is belonging to the same group. Please Help Me, Thank You In Advance. Pallavi