Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
devel:documentation:workflows:dev:workflow [2021/05/24 11:38]
husniko [Dynamic detail of task] 		devel:documentation:workflows:dev:workflow [2021/06/21 12:47] (current)
husniko
Line 15: Line 15:
  
 =====Design of process===== =====Design of process=====
-Design of workflow process is realized with XML in format BPM 2.0. It is very helpful to use Activiti Designer. It is [[http://docs.alfresco.com/5.2/tasks/wf-install-activiti-designer.html|plugin in IDE Eclipse]]. Activiti Designer is user-friendly and allows creating a process without user intervention into XML code.+Design of workflow process is realized with XML in format BPM 2.0. It is very helpful to use Activiti Designer. It is [[http://docs.alfresco.com/5.2/tasks/wf-install-activiti-designer.html|plugin in IDE Eclipse]]. Activiti Designer is user-friendly and allows creating a process without user intervention into XML code. In order to be possible to install the Activiti Designer into Eclipse, add its repository address ''https://www.activiti.org/designer/update/'' in the Eclipse Install New Software section. 
 +A manual could be found [[https://www.websparrow.org/misc/how-to-install-activiti-designer-plugin-in-eclipse-sts|here]].
  
 **Sample of Activiti process in IDE Eclipse plugin:** **Sample of Activiti process in IDE Eclipse plugin:**
Line 236: Line 237:
   * **permissions** - Defines required permissions, which user has to have to be able make decision.   * **permissions** - Defines required permissions, which user has to have to be able make decision.
   * **skipValidation** - If you not used this attribute the behavioral will same as if you set it to false. When you set it to true then the validation of form(userTask) will be ignored.    * **skipValidation** - If you not used this attribute the behavioral will same as if you set it to false. When you set it to true then the validation of form(userTask) will be ignored. 
 +  * **reasonRequired ** - This property set to true enforces decision reason to be provided.
  
 ===From properties=== ===From properties===
Line 418: Line 420:
 </dataObject> </dataObject>
 </code> </code>
 +
 +<note tip>
 +To avoid the need of workflow modification and an easy configuration of the most common decisions i.e. ''approve'' and ''disapprove'' there are shortcuts in IdM properties. Both accepts **true** or **false** values.  
 +
 +''idm.sec.core.wf.approval.reason.required'' - sets decision reason required for APPROVAL decision  
 +''idm.sec.core.wf.disapproval.reason.required'' - sets decision reason required for DISAPPROVAL decision  
 +</note>
  
 If decision button ''apporve'' is set like shown above, ''showWarning'' attribute ensures displaying of the modal window, where a solver note can be inserted. The second parameter ''reasonRequired'' specifies that the solver note is mandatory and the action cannot be finished without it. If only ''showWarning'' is set the note can be set but its filling is not required. It's important to note that when our workflow calls other sub-workflows it is important and also sufficient to change this setting in the parent workflow only. The setting is propagate from the parent WF to sub-WF and will override the setting of the sub-WF. If decision button ''apporve'' is set like shown above, ''showWarning'' attribute ensures displaying of the modal window, where a solver note can be inserted. The second parameter ''reasonRequired'' specifies that the solver note is mandatory and the action cannot be finished without it. If only ''showWarning'' is set the note can be set but its filling is not required. It's important to note that when our workflow calls other sub-workflows it is important and also sufficient to change this setting in the parent workflow only. The setting is propagate from the parent WF to sub-WF and will override the setting of the sub-WF.
-In most cases the userTask uses two decision types: ''id=approve'' and ''id=disapporve''. One can avoid the need of workflow changing for those two buttons thanks to the IdM properties ''idm.sec.core.wf.sapproval.reason.required'' and ''idm.sec.core.wf.disapproval.reason.required''. If they are set to true solver note/reason is required for the corresponding type of decision button choice. The setting works globally for all workflows in the IdM. If those IdM properties are set and there is also set ''reasonRequired'' parameter in a workflow, the setting from the workflow is preferred over that IdM properties for userTasks from that workflow.+In most cases the userTask uses two decision types: ''id=approve'' and ''id=disapporve''. One can avoid the need of workflow changing for those two buttons thanks to the IdM properties ''idm.sec.core.wf.approval.reason.required'' and ''idm.sec.core.wf.disapproval.reason.required''. If they are set to true solver note/reason is required for the corresponding type of decision button choice. The setting works globally for all workflows in the IdM. If those IdM properties are set and there is also set ''reasonRequired'' parameter in a workflow, the setting from the workflow is preferred over that IdM properties for userTasks from that workflow.
  
  
  • by husniko