Association module: workflow states

Feature Ideas
1

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.

2

Sorry if I could not attend the conference (I was on sick leave).

But my 2 cents (I hope it can help):

  • The ended and expelled seams a bit redundant, at least for the base module (doesn’t mean it could be have more sense later). For the base module seams a bit to limitative to limit the rejoin if you’re in the expelled state. And you permitt to rejoin the expelled people, there is not distinction between the two states (IMHO).

So, I propose:

  • Draft
  • Pending - the approving workflow has started (vote, waiting payment, ecc…)
  • Active - the member is part of the association
  • Expelled - the member is no longer part of the association (or never was)

If you want register that a member was not accepted by the association, You can expell it (if tlyou want to keep record of it). Otherwise you can push to draft, or delete the record (this I think depends on the association/club management).

3

I will prefer to keep it simpe for the base module. So I agree with:

The limitation can be always added by customization code if really needed.

4

I’ve just had a look at the current merge request, and I can see that there is a join_date and leave_date, so I’m not so sure that (my previous suggestion) of Active for one of the states is correct. In fact, with those dates, you may only need:

  • Draft
  • Approved

The dates indicate whether the membership is Active or not (and could work with an active field in a similar way to, for example, the party relationships).

As a suggestion, you could then have a

  • Rejected

state, to mirror the Approved state and which could also be used, along with the join_date / leave_date, to indicate that the member was expelled (for example, if there is no join_date then the membership was rejected, but with a join_date the membership was terminated early because the member was expelled)?