cancel
Showing results for 
Search instead for 
Did you mean: 

Workflow based on content type or property value

katarinahallber
Champ in-the-making
Champ in-the-making
Hi, I am investigating a way to implement a requirement where different workflows should be available based on document content type or property in document. Hope someone can help me with the best way to solve this.

<!–break–>

More detailed description of the current situation and the additional requirement is following here. I am relatively new to Alfresco development, so I might not use the correct terminology but I hope you understand what I mean.

Today we have a custom content type and two different "review and publish workflows", one with a one step approval process, and one with a two step approval process. Those two workflows are displayed in the menu at the Workflow page after user has invoked the "Start workflow" action. So the user starting the workflow is the one choosing which workflow to start.

The requirement is that it should not be up to the user starting the workflow to select which workflow to start, it should rather be decided by the document that is being "put through" the workflow. The document should by default belong to the "two-step-process", but some users (probably based on which group they belong to) should be able to "mark" the document to belong to the "one-step-process" instead. Based on this only the appropriate "review and publish workflow" should be available when starting a workflow.


My current plan is to:
<ol>
<li> Add an UI-action that is available for some users (probably based on which group they belong to) that can override the default "setting" of document belonging to the "two-step-process". Not sure if I should use different content types, an aspect or a value of an "invisible" property to mark the documents "process-belonging". Any suggestion on this is welcomed.</li>

<li>Replace the two existing "review and publish workflows" with one workflow that takes different "roads" (one-step- or two-step-process) based on document content type, aspect or value of a property (see above).</li>
</ol>

Questions:

<ol>
<li>Is this a correct/good way of solving it?</li>

<li>What is the best way of "marking" which process a document belongs to? Content type, aspect, property value? It needs to be done in a way that I can "read" in the workflow when selecting which "road" to follow.</li>

<li>Is it an alternative solution to make changes in the js that finds workflows to list, so only appropriate workflow is shown, based on content type, aspect or property value of document. Is this even doable?</li>
</ol>

I use Alfresco 4.0.e, Share.

Please let me know if there is any other information needed to be able to understand the situation or requirement.

2 REPLIES 2

pjaromin
Champ on-the-rise
Champ on-the-rise
I've done exactly what you're proposing and it's worked brilliantly for us.

In my case I created an "approvable" aspect as below:


<aspect name="myr:approvable">
   <properties>
      <property name="myr:workflowName">
         <title>Approval Workflow Name</title>
         <type>d:text</type>
         <default>activiti$myPieceApproval</default>
      </property>
      <property name="myr:approverAuthority">
         <title>Approver Authority</title>
         <type>d:text</type>
         <default>GROUP_APPROVERS</default>
      </property>
   </properties>
</aspect>


Then an an admin is able to assign/override the default approval workflow and authority if desired.

I then created a custom "SubmitForApprovalAction"


   protected void executeImpl(Action action, NodeRef nodeRef) {

      NodeService nodeService = serviceRegistry.getNodeService();
      if (nodeService.hasAspect(nodeRef, MyriadModel.ASPECT_APPROVABLE)) {
         String workflowName = (String)nodeService.getProperty(nodeRef, MyriadModel.PROP_WORKFLOW_NAME);

         // TODO check if group or individual
         String groupName = (String)nodeService.getProperty(nodeRef, MyriadModel.PROP_APPROVER_AUTHORITY);
         NodeRef approverAuthority = serviceRegistry.getAuthorityService().getAuthorityNodeRef(groupName);

         WorkflowService workflowService = serviceRegistry.getWorkflowService();
         NodeRef workflowPackage = workflowService.createPackage(null);
         QName qname = QName.createQName(NamespaceService.CONTENT_MODEL_1_0_URI,
               QName.createValidLocalName((String)nodeService.getProperty(nodeRef, ContentModel.PROP_NAME)));
         nodeService.addChild(workflowPackage, nodeRef, ContentModel.ASSOC_CONTAINS, qname);

         Map<QName,Serializable> params = new HashMap<QName,Serializable>();
         params.put(WorkflowModel.ASSOC_PACKAGE, workflowPackage);
         params.put(WorkflowModel.ASSOC_GROUP_ASSIGNEE, approverAuthority);
         params.put(WorkflowModel.PROP_SEND_EMAIL_NOTIFICATIONS, Boolean.TRUE);
         params.put(WorkflowModel.PROP_WORKFLOW_DESCRIPTION, "Approval Request: '" + nodeService.getProperty(nodeRef, ContentModel.PROP_NAME) + "'");
         params.put(MyriadModel.PROP_SUBMITTER_COMMENTS, action.getParameterValue(PARAM_COMMENTS));
         if (action.getParameterValue(PARAM_DUEDATE) != null) {
            params.put(WorkflowModel.PROP_WORKFLOW_DUE_DATE, action.getParameterValue(PARAM_DUEDATE));
         }

         WorkflowDefinition workflowDef = workflowService.getDefinitionByName(workflowName);
         workflowService.startWorkflow(workflowDef.getId(), params);
         
         // Now we need to disable the edit and move actions.
         // TODO: externalize this to allow for per-client customization of this behavior.
         if (nodeService.hasAspect(nodeRef, MyriadModel.ASPECT_DOCUMENT_ACTIONS)) {
            nodeService.setProperty(nodeRef, MyriadModel.PROP_HASACTION_EDITCUSTOMIZABLE, Boolean.FALSE);
            nodeService.setProperty(nodeRef, MyriadModel.PROP_HASACTION_EDITCUSTOMIZABLE, Boolean.FALSE);
         }
      }

   }


And hooked it up on Share via a DocumentAction in the share-config-custom.xml along with a custom form.

After the user selects "Submit for Approval" on the document and completes the form, the workflow runs through the standard Share workflow task forms.

Hope this helps.

-Patrick

It seems that you are doing nearly exactly what I want to achieve 🙂

I have some questions on details of your solution:

<ul>
<li>How does admin override the default values of the aspect? With a Document Action only available for admin? In the "regular edit form"? Some other way?</li>
<li>Is the "Submit for approval" Document Action only available in the UI if the aspect is present? Don't know if this is even possible?</li>
<li>In your solution you have an Action as a starting point, starting the correct workflow based on values in the aspect. In my suggested solution I thought of having one workflow with conditional logic to decide which way the workflow should take. Do you see any advantages/disadvantages with one way or the other, or is it only two ways of solving it? Or maybe my solution is not even possible?</li>
</ul>

Thanks again!

Katarina