Content
View differences
Updated by Niels Lindenthal about 2 years ago
**As** an OpenProject admin admin
**I want to** set up automated workflows
**so that** project members are relieved of tedious work and work packages status and values are more conform.
**Acceptance criteria**
* All changes caused by automations are performed by a new system user that gets introduced to OP.
* The new system user's action are limited to the given permissions.
* When certain actions can not be performed, due to lack of permissions, admins need to be notified about it.
* All changes to WPs need to create a new journal entry. The the new system user is shown in the journal entry as performing user of this changes.
**Why?**
_"Automate the routine and unlock potential"_
Automated workflows streamline operations and improve overall productivity by
* Relieving team members of tedious administrative tasks and allowing them to focus on more valuable work.
* Reducing the likelihood of human error.
* Allowing for controlled changes in project areas for which team members would otherwise not have permissions for.
The team ends up with increased efficiency, productivity and consistency.
## Customer use cases
* Close Milestones automatically through a work package relation (e.g. includes/part of or precedes/follows) when predecessor has been closed
* If all the Tasks have been set to "Closed" -> Then the overlying Parent (for example, a Project under which all those tasks are arranged) is automatically set to "Closed" as well.
* Someone creates a task; status is new -> Someone different from the author adds a comment -> Status should now automatically change from new to "in progress"
* If a work package is between start and finish date AND there are preceding or blocking WPs that are not closed yet, set status to "blocked"
* If status change is to "closed" and there is a following WP, email or notify assignee of following work package
* I would say that the status would only toggle automatically when the Assignee does something (comment \*\*or\*\* enters "spent time").
* 'solved' status, then the assignee was automatically removed, as the CCB needed to assign a different user.
* For changing user defined values like a checkbox in the task overview by changing the task status.
* Would be helpful to set the progress to 100% once a WP is moved to "Closed"
* Enter project progress in % --> automatic status change to "in progress"
## Customer cases (unified and grouped)
### Triggered by user changes in WP
#### Status changed -> change field to value
* Status set to solved -> assignee gets removed
* Status is changed -> custom field checkbox gets changed
* Status is closed -> progress gets changed to 100%
#### Field is changed -> change status
* Spent time is added -> status gets changed to in progress
* When progress is changed to > 0% -> status gets changed to "in progress"
#### Others
* Comment is added -> status gets changed
### Triggered by user changes in relational WP
#### Status is changed -> trigger from relational -> change status if all/some/one relational has status
* Status is changed to close -> relational milestone status gets changed to close
* Status is changed -> parent status gets changed
#### Status is changed -> trigger from relational -> action
* Status is closed -> users of following WP get notified
* Status is open -> preceding gets blocked (out of scope)UI
###
## Additional functionality needed to move from "Custom actions" to **Automation**
### Triggers (sorted by priority)
* Button \[label\] (exist but needs a label input)
* Other automation
* Status transition to \[status\]
Out of scope:
* Field(s) updated \[field\] \[change\] (user needs to specify field and what changes happened e.g. all, specific value, deleted etc)
* Created
* Deleted
* Comment \[added/edited/deleted\]
* Assigned
* Linked
### Condition
* Status of all \[relation\] is \[status\]
### Action
* Trigger \[automation\] for \[relation\]
## Use cases example implementation FACHKONZEPT
###
### AUFTRAG is closed
```text
Trigger: Status transition to "closed"
Condition
- Type: "AUFTRAG"
Action
- Trigger automation: "Close KONZEPT when done" for "including" work packages
```
### Close KONZEPT when done
```text
Trigger: Other automation
Conditions
- Type: "FACHKONZEPT" or "DV-KONZEPT"
- Status of all relations: "including" is "closed"
Action
- "Close"
```
## Wireframes
### New UI options needed
<img class="op-uc-image op-uc-image_inline" style="width:594px;" src="/api/v3/attachments/92765/content">
###
### Automation: AUFTRAG is closed
<img class="op-uc-image op-uc-image_inline" style="width:660px;" src="/api/v3/attachments/92764/content">
### Automation: Close KONZEPT when done
<img class="op-uc-image op-uc-image_inline" style="width:753px;" src="/api/v3/attachments/92763/content">
###
**I want to** set up automated workflows
**so that** project members are relieved of tedious work and work packages status and values are more conform.
**Acceptance criteria**
* All changes caused by automations are performed by a new system user that gets introduced to OP.
* The new system user's action are limited to the given permissions.
* When certain actions can not be performed, due to lack of permissions, admins need to be notified about it.
* All changes to WPs need to create a new journal entry. The the new system user is shown in the journal entry as performing user of this changes.
**Why?**
_"Automate the routine and unlock potential"_
Automated workflows streamline operations and improve overall productivity by
* Relieving team members of tedious administrative tasks and allowing them to focus on more valuable work.
* Reducing the likelihood of human error.
* Allowing for controlled changes in project areas for which team members would otherwise not have permissions for.
The team ends up with increased efficiency, productivity and consistency.
## Customer use cases
* Close Milestones automatically through a work package relation (e.g. includes/part of or precedes/follows) when predecessor has been closed
* If all the Tasks have been set to "Closed" -> Then the overlying Parent (for example, a Project under which all those tasks are arranged) is automatically set to "Closed" as well.
* Someone creates a task; status is new -> Someone different from the author adds a comment -> Status should now automatically change from new to "in progress"
* If a work package is between start and finish date AND there are preceding or blocking WPs that are not closed yet, set status to "blocked"
* If status change is to "closed" and there is a following WP, email or notify assignee of following work package
* I would say that the status would only toggle automatically when the Assignee does something (comment \*\*or\*\* enters "spent time").
* 'solved' status, then the assignee was automatically removed, as the CCB needed to assign a different user.
* For changing user defined values like a checkbox in the task overview by changing the task status.
* Would be helpful to set the progress to 100% once a WP is moved to "Closed"
* Enter project progress in % --> automatic status change to "in progress"
## Customer cases (unified and grouped)
### Triggered by user changes in WP
#### Status changed -> change field to value
* Status set to solved -> assignee gets removed
* Status is changed -> custom field checkbox gets changed
* Status is closed -> progress gets changed to 100%
#### Field is changed -> change status
* Spent time is added -> status gets changed to in progress
* When progress is changed to > 0% -> status gets changed to "in progress"
#### Others
* Comment is added -> status gets changed
### Triggered by user changes in relational WP
#### Status is changed -> trigger from relational -> change status if all/some/one relational has status
* Status is changed to close -> relational milestone status gets changed to close
* Status is changed -> parent status gets changed
#### Status is changed -> trigger from relational -> action
* Status is closed -> users of following WP get notified
* Status is open -> preceding gets blocked (out of scope)UI
###
## Additional functionality needed to move from "Custom actions" to **Automation**
### Triggers (sorted by priority)
* Button \[label\] (exist but needs a label input)
* Other automation
* Status transition to \[status\]
Out of scope:
* Field(s) updated \[field\] \[change\] (user needs to specify field and what changes happened e.g. all, specific value, deleted etc)
* Created
* Deleted
* Comment \[added/edited/deleted\]
* Assigned
* Linked
### Condition
* Status of all \[relation\] is \[status\]
### Action
* Trigger \[automation\] for \[relation\]
## Use cases example implementation FACHKONZEPT
###
### AUFTRAG is closed
```text
Trigger: Status transition to "closed"
Condition
- Type: "AUFTRAG"
Action
- Trigger automation: "Close KONZEPT when done" for "including" work packages
```
### Close KONZEPT when done
```text
Trigger: Other automation
Conditions
- Type: "FACHKONZEPT" or "DV-KONZEPT"
- Status of all relations: "including" is "closed"
Action
- "Close"
```
## Wireframes
### New UI options needed
<img class="op-uc-image op-uc-image_inline" style="width:594px;" src="/api/v3/attachments/92765/content">
###
### Automation: AUFTRAG is closed
<img class="op-uc-image op-uc-image_inline" style="width:660px;" src="/api/v3/attachments/92764/content">
### Automation: Close KONZEPT when done
<img class="op-uc-image op-uc-image_inline" style="width:753px;" src="/api/v3/attachments/92763/content">
###