Assign multiple state machine workflows rules to a project
Hi,
I've several projects that share the same workflows.
Among them, there is one called "Dev lifecycle" that has a state machine rule.
There are other project with similar workflows, however, the "Lifecycle" rule is slightly different.
Both rules share many transitions, so when I update one, I often need to update the other.
I was wondering if I could create a third workflow, with just a state machine rule that has all the shared transitions.
What blocks me however is the "initial state", as this is supposed the first state when submitting the ticket.
Instead, in my case, it should be considered the initial state from where all the transitions should follow.
Meaning that the ticket might be submitted with a different state, but the rule must start working only when ticket reach the initial state.
So, to make it cleared and using a realistic example, we have two life cycles:
The both have the same lifecycle:
(*) Development need to also go through these states after it change to "In progress" (that's just a shor version):
I've several projects that share the same workflows.
Among them, there is one called "Dev lifecycle" that has a state machine rule.
There are other project with similar workflows, however, the "Lifecycle" rule is slightly different.
Both rules share many transitions, so when I update one, I often need to update the other.
I was wondering if I could create a third workflow, with just a state machine rule that has all the shared transitions.
What blocks me however is the "initial state", as this is supposed the first state when submitting the ticket.
Instead, in my case, it should be considered the initial state from where all the transitions should follow.
Meaning that the ticket might be submitted with a different state, but the rule must start working only when ticket reach the initial state.
So, to make it cleared and using a realistic example, we have two life cycles:
- Support
- Development
The both have the same lifecycle:
- Open
- In progress (*)
- Fixed
- Won't fix
- Fixed
- Won't fix
- Duplicated
- Obsolete
(*) Development need to also go through these states after it change to "In progress" (that's just a shor version):
- Fix proposed
- Fix approved
- Tests needed
- Tests passed
- Test failed
- Test needs improvement
- Fixed
- Reopened
- Fixed
- Tests passed
- Fixed
- Tests needed
- Fix declined
- Fix approved
Please sign in to leave a comment.
I think you can see the point of my request: many projects may share several workflows and among them, state machine workflows needs to be repeated over and over even if they only have small difference.
Call me stupid, but I like DRY methodology and this is way far from it.