Following up the discussion about the association blueprint and the merge-request for the assiciation module, I’d like to bring up the topic “workflow states” to a broader audience. At the Unconference I had some person-to-person discussions (esp. thanks to @timitos and @dave) but there was no workshop on this topic.
These are the proposed workflow states and some reasoning — based on recent discussions:
- Draft — same as anywhere in Tryton
- Rejected: not accepted as a member, end-state of the workflow
Accepted (by the board/whoever-is-in-charge): the party is allowed to become a member, but some other (technical, administrative) preconditions might be required to become “Active”
I added this to the proposal for several reasons:
- allowing separation of duties between the board and the operative personal
- allowing for checking preconditions (e.g. paying entrence-fees, which a future member will only pay if accepted)
- we have fine-grained workflow-steps on other modules, too
- it’s much easier to customize skipping a workflow-state than adding one
- Running (is member) → rename to „Member“
- Ended: some kind of „normal” termination which allows the party to become a member again (forgot to renew membership / cancelled membership / died / defaulted on their payment)
- Expelled: association has decided to terminate the membership and is unlikely to want the party to be a member again
Please comment, so we can finish the implementation.