...
Requested Node | Current Status | Action | Taken By | New Status |
|---|---|---|---|---|
Request | INITIATED | Fill out form, set URGENT to NO, click route | requester1 | ENROUTE |
ReviewCurrentConfiguration | ENROUTE | Click approve | DES1 | ENROUTE |
InitialApproval | ENROUTE | Click disapprove | FPG1 | DISAPPROVED |
AcknowledgeConfiguration | DISAPPROVED | Click acknowledge | requester1 | DISAPPROVED |
Procure Roles
After going through the easy and expedient process of requesting work groups, the Kuali Rice administrator has notified us that the following groups are available for use in our workflow:
Responsible Party | Work Group |
|---|---|
Requester | Initiator.Role.RuleAttribute |
Desktop Services | edu.ucdavis.iet.des.DevelopmentSupport |
Firewall Policy Group | edu.ucdavis.iet.adda.FirewallPolicyGroup |
Firewall Gatekeeper | edu.ucdavis.iet.dccs.FirewallSysAdmin |
Super User Workgroup | edu.ucdavis.iet.adda.KualiRiceSysAdmin |
Default Exception Workgroup | edu.ucdavis.iet.KualiRiceSysAdmin |
| Info |
|---|
Notice that the Kuali Rice Administrator identified ucd.IET.AppDev.KualiRice.SysAdmin.Workgroup even though that group is not involved in our business process. We'll need to identify a Super User Workgroup and Default Exception Workgroup when we create Document Types. In production, these work groups could potentially be the process owners, or department system administrators, rather than IET system administrators. |
Looking at our workflow diagram, we build a responsibility matrix documenting who should act on which node and what action we're requesting of them. We'll use this later when we build our set of rules.
Node | Responsible Party | Responsibility Condition(s) | Action Requested |
|---|---|---|---|
Request | Initiator.Role.RuleAttribute (whoever creates the document) | none | SUBMIT |
Review Current Configuration | ucd.IET.DES.DevelopmentSupport.WorkGroup | none | APPROVE |
Initial Approval | ucd.IET.AppDev.FirewallPolicyGroup.Workgroup | non-urgent request | APPROVE |
Initial Approval | ucd.IET.DCCS.FirewallSysAdmin.Workgroup | urgent request | APPROVE |
Final Approval | ucd.IET.AppDev.FirewallPolicyGroup.Workgroup | non-urgent request | APPROVE |
Final Approval | ucd.IET.DCCS.FirewallSysAdmin.Workgroup | urgent request | APPROVE |
Acknowledge Configuration | Initiator.Role.RuleAttribute | none | ACKNOWLEDGE |
Looking at our workflow diagram, we build a responsibility matrix documenting who should act on which node and what action we're requesting of them. We'll use this later when we build our set of rules.
Node | Responsible Party | Responsibility Condition(s) | Action Requested |
|---|---|---|---|
Request | Initiator (whoever creates the document) | none | SUBMIT |
Review Current Configuration | IET DES Development Support | anyone, any request | APPROVE |
Initial Approval | IET PSL Firewall Policy Group | everyone, non-urgent request | APPROVE |
Initial Approval | IET DCCS Firewall System Administrator | first one, urgent request | APPROVE |
Final Approval | IET PSL Firewall Policy Group | everyone, non-urgent request | APPROVE |
Final Approval | IET DCCS Firewall System Administrator | first one, urgent request | APPROVE |
Acknowledge Configuration | Initiator | none | ACKNOWLEDGE |
After going through the easy and expedient process of requesting work groups, the Kuali Rice administrator has notified us that the following roles are available for use in our workflow:
Responsible Party | Work Group |
|---|---|
Requester | Initiator.Role.RuleAttribute |
Desktop Services | edu.ucdavis.iet.des.DevelopmentSupport |
Firewall Policy Group | edu.ucdavis.iet.adda.FirewallPolicyGroup |
Firewall Gatekeeper | edu.ucdavis.iet.dccs.FirewallSysAdmin |
Super User Workgroup | edu.ucdavis.iet.adda.KualiRiceSysAdmin |
Default Exception Workgroup | edu.ucdavis.iet.KualiRiceSysAdmin |
| Info |
|---|
Notice that the Kuali Rice Administrator identified edu.ucdavis.iet.KualiRiceSysAdmin even though that role is not involved in our business process. We'll need to identify a Super User Role and Default Exception Role when we create Document Types. In production, these work groups could potentially be the process owners, or department system administrators, rather than IET system administrators. |
Create the Parent Document Type
...
| Code Block | ||
|---|---|---|
| ||
<?xml version="1.0" encoding="UTF-8"?>
<data xmlns="ns:workflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="ns:workflow resource:WorkflowData">
<documentTypes xmlns="ns:workflow/DocumentType" xsi:schemaLocation="ns:workflow/DocumentType resource:DocumentType">
<documentType>
<name>RequestFirewallChange.eDoc.ChildDocType</name>
<parent>RequestFirewallChange.eDoc.ParentDocType</parent>
<description>Request Firewall Change eDocLite Child Document Type</description>
<label>Request Firewall Change eDocLite Child Document Type</label>
<postProcessorName>edu.iu.uis.eden.edl.EDocLitePostProcessor</postProcessorName>
<superUserWorkgroupName>ucd.IET.AppDev.KualiRice.SysAdmin.Workgroup</superUserWorkgroupName>
<defaultExceptionWorkgroupName>ucd.IET.AppDev.KualiRice.SysAdmin.Workgroup</defaultExceptionWorkgroupName>
<docHandler>${workflow.url}/EDocLite</docHandler>
<active>true</active>
<routingVersion>2</routingVersion>
<routePaths>
<routePath>
<start name="Request" nextNode="ReviewCurrentConfiguration" />
<requests name="ReviewCurrentConfiguration" nextNode="InitialApproval" />
<requests name="InitialApproval" nextNode="FinalApproval" />
<requests name="FinalApproval" nextNode="AcknowledgeConfiguration" />
<requests name="AcknowledgeConfiguration" />
</routePath>
</routePaths>
<routeNodes>
<start name="Request">
<activationType>P</activationType>
</start>
<requests name="ReviewCurrentConfiguration">
<activationType>P</activationType>
<ruleTemplate>RequestFirewallChange.eDoc.ReviewCurrentConfiguration.RuleTemplate</ruleTemplate>
</requests>
<requests name="InitialApproval">
<activationType>P</activationType>
<ruleTemplate>RequestFirewallChange.eDoc.InitialApproval.RuleTemplate</ruleTemplate>
</requests>
<requests name="FinalApproval">
<activationType>P</activationType>
<ruleTemplate>RequestFirewallChange.eDoc.FinalApproval.RuleTemplate</ruleTemplate>
</requests>
<requests name="AcknowledgeConfiguration">
<activationType>S</activationType>
<ruleTemplate>RequestFirewallChange.eDoc.AcknowledgeConfiguration.RuleTemplate</ruleTemplate>
<mandatoryRoute>false</mandatoryRoute>
<finalApproval>false</finalApproval>
</requests>
</routeNodes>
</documentType>
</documentTypes>
</data>
|
...