Association blueprint

Ahaa sorry, I meant something like: you dind’t pay for x month, so now we send you a letter (after the board say to proceed with the expulsion procedure). This stage will make so the expulsion letter can be sent (and the date of the notice can be recorded). After that you can go to to “running” (if the members pays the due fees) or “stopped” (if the member doesn’t respond, or doesn’t pay the fee in time).[the fees are just an example… this is meath as a manual step]

Tell me if something like this is should be in the standard module.

Yes, maybe i should fix it :smiley:. At-lest have the option to use a different sequence should be an option.

Yes, the simple way (right now) is to set the fee at 0. Like i suggested we can make the account not required if all periods have a fee set to 0.

Otherwise, in more technical terms, can you describe how you wold implement your idea?

Fair enough :smiley:

I blame the babel tower for this misunderstanding :smiley:
Bur anyway… this is more geared at “clubs”… for the renaming part… I have no strong feelings about it.

This is the way is implemented sale_subscription. I don’t have strong opinion on this either but it’s consistent on how other tryton module work.

I don’t have strong felling about this either.
“Book of…” I think should have a button, because (like other module) it’s an official report like the “general journal”.

This is a missconfiguration. The module allows to define diferent sequences for each company but only comes with a single sequence configured by default. So if you do not configure a diferent sequence for each company the sequence is shared between all companies in the system.

Then you should set zero as fee for the period and it should work.
Latter if you want’ to have fees for the memebers you just update the fee for the next period.

After I’ve lot my carefully quoted darft, I’m going to answer with bullet-points only :wink:


  • Module name “association” is fine for me. Just let’s keep the broader definition in mind when designing this.
  • “Probation” → What is a good term then? “Dissuation”? “(Written) warning”? “Call to order”? “final written warning”? (jura) “threat of dismissal”? “warning of dismissal”?
  • Still not sure what “mmebership type” is for you - see below.

Design proposals

  • Member-ship ID sequence should by per Company/Association
  • Fees should be split from member (optional module)
  • Having a “Books of members” as a menu entry would be okay for me.

Workflow and membership type

The membership-workflow depends a lot on what teh mental model or “membership type” is. I still do not get what a “membership type” is from your point of view:

  • Different fees (e.g. kids pay less, honours pay nothing)?
  • Sub-memberships (e.g special interest groups with/without additional fees)?
  • Different extend (personal, family)?

Even if other Tryton modules behave like this: To add a “membership-type”, the “membership” itself should not the set to “draft” - as this would imply the board has to re-agree on the membership itself. This might be required (depending on the statutes) when changing from personal to family membership. Anyhow it should not be required when joining a special interest group.

Same for the membership id: depending on the statutes it may nor may not change when changing from personal to family membership.

This can be archived by creating another sequence for each company. So this is more a “fix by documenting it” issue :smiley:
This is similar to the party module.
(“hidden feature”[is documented], if you not define a sequence, the id can be added by the user manually, like the party module)

This was the first question I asked in the module proposal (if I remember it was decided to keep it in the main module). Anyway (if i remember correctly) a member doesn’t need to have a membership defined. So if you don’t need it you can safely ignore the fee handling of the module.

The association.membership.type defines the fee for the given periods. I drew a quick and dirty diagram (simplified… membership periods don’t need to be contiguous or starting with the same date). I hope it helps:

some considerations:

  • membership types have periods (the boxes with a name and fees)
  • individual memberships can have a starting and ending date.

With this model you can model different type of behavior, like different fees, sub-memberships and so on.
for “Different extend (personal, family)” can be modeled by creating a (e.g.) “family member” membership type with a reduced fee (or set to 0). This if you want to be register in the members book, otherwise you don’t need to keep track of it (I think).

Progressive fee structure can be modeled by creating types for each milestone (like, for 10 years you pay in full, and afterward you don’t pay anything). The when you add membership to a member you set the start and end date to define your fee structure for each membership type (right now manually, maybe we can add a wizard to calculate the dates for the user).

well, it’s just transitory. There will be no record of this.

This is easily achievable by adding a transaction from “stopped” to “draft” and clearing the starting and ending date.
I can add such feature become it give the option to the user to do so. Anyone opposed to this?

Sorry for not coming back to this earlier.

This meets my POV.

Rethinking this, I’d say a “stopped” membership can not be revived, so not transition from stopped->draft.
Specific needs for “Family membership” can easily be customized based on the current implementation.

@wifasol: Please find my updated version at
I updated the documentation to (hopefully) meet the results of our discussion. Thus the most interesting part of this change are the Introduction and Concepts sections in the documentation. I did not yet implement this,since I fist would like to agree on the concepts.

Please let my know what you think.

It will be great if you can join efforts to include the changes on the odifical review server so they can be included to tryton.

The documentation should follow our documeantion guideliness.

First of all, thank you for your work regardless :smiley:

Will check if it follows the guidelines, for the content I think we should slim down with the specific examples.
For design (including a new state for handling expulsion, I think… I just scanned the document really fast) I’ll compile yout proposal here, when I have a sliver of time :smile:

Don’t worry, it will go in codereview :smiley:
But first I need to apply the changes you asked in #105 (when I have some time this month).
In that regard I’m studyng how the payed state is handled in the invoice module (you linked as an exaple), and then I can answer your remarks.

@wifasoi I updated my code (which is now at htgoebel/trytond-association: Fork and extension of of - trytond-association - Relevant changes are:

  • Change Member workflow to be linear: Once a member, never go back to “draft”,
    since if one is a member, it will stay a member until resigning.
  • Add state ‘admitted’
    This module splits approval into two steps: admission and activating as a member.
    This is done to cover cases where the member-to-be, after being admitted to become a member, has to provide something to actually become a member (e.g. pay some entry fee, pay cooperative shares).
  • Add support for observing termination notice period
  • Add field ‘Member.termination_notice_date’
  • Add field ‘Member.memberships_names’
  • Require ‘’ to be unique - except if member has resigned.
    Of course, a Party can be a member of an Association only once at a time.

Other changes:

  • Make Membership editable in all Member states
  • Fix sql-constraints for ‘Member.code’
  • Add German translation
  • Update form view for membership-type
  • Activate missing form view for membership-type

Thank you for lending me an hand in this. I’ll check the code this weekend, and push it to code review.
Anyway, I had a quick peek:

I’m fine with this.

I’m fine with this. Initially i was thinking to use the dunning module to keep track of the notices. But termination by not paying fees is not the only way to be radiated by the association (e.g. breaking the rules, and the board want to expell you).

side note: maybe a future module/version can add a way to add comunication channels (like the dunning one), for sending notice via sms or/and email.

maybe a better name for the filed is “active memberships”,
Anyway, I find this featuure can be handy… but I think the best way is to make possible (if it’s not already possible) to filter the “active membership” by name. Then the user can open the form view to see all the memberships.
Maybe we can be creative and use some conditional formatting to color the line of the one2Many memberships to indicate wich one is still active/ended.

This is a feature I want :smiley:

Maybe I’ll strip out this form the code review, and the later import to weblate when the module will be merged in to trunk.
I don’t know if it’s ok to leave it, and weblate will pick it up automatically (if so, I’ll add an italian translation too).

Anyway, thanks for your contribution (and lending me an hand) :smiley:

Yeah, this is a better name.


Sound good. Anyhow, I’d prefer to get the package accepted as official first. We can always refine it later.

Ok, tox fails if i try your branch with tryton 6.1.0 (aka dev).
So, I wasn’t able to push to codereview. I’m now try to find out why.

2 posts were merged into an existing topic: Problem inizializing sqlite db with tryton 6.1.0

This topic has become a holdall topic which derived from the discussion of the design of the proposed module.
Please open appropriate new specific topics and avoid development chat here.

@wifasoi I just discovered a issue in the implementation for the module’s configuration: termination_notice_period must be specific to the association/company. Currently it is not.

Ahaa I see,
yes it should be another class that extends ValueMixin (like here)

I can implement it this weekend (if you dont want do it first).
Anyway I’ll work on the 6.0.0 migration in the meantime.

I’d be happy if you could finish this module - I’m still Tryton newbie and this kind of fine-tuning take a loooot of time for me.

Hey, I would like to get this ready soon as well. Hopefully the others at “my” association will be as excited as I am ^^.

Indeed, this thread is way too long, and the thread’s context is outdated! Even though I am late for the discussion, I would still like to make a few considerations about the design / state of the module (I got the code from Infrastruttura / Tryton / mittelab_association · GitLab).

  • As commented somewhere earlier in the thread, a member is conceptually a party with certain added attributes (fields). Why is it better to create a new model for a Member, instead of adding it to the party? (I would expect that a Party has memberships)

  • Why aren’t the fee lines created automatically when a membership is admitted or running?

  • Why do we need both admitted and running states? Is some feature missing? They sound redundant to me.

  • As a user of the system, I would like to find information about a party’s membership from the party list. It would even be nice to show who has an active membership in party’s list.

  • Docs say

    Join Date: The date when the member joins the association.

    Is join date the date when someone requests (applies) to become a member? Or is it the date when that person becomes a member? Or is it the date when a Tryton user creates that member record?
    I’m confused with this field. I would expect it to be calculated as the earliest start date of the Members’ memberships, or as a default value for the time when the record is created.

  • The workflow to me sounds more like the workflow of each membership, and not of the member itself. Especially considering that the same (person) Member can have more than one active memberships, there would be no way of stopping one membership, while the other continues. On the same line of thought, Notice termination date and leave date would be related to the membership, and not to the member.

  • Associations I’m a member of will keep invoicing me yearly for the membership fee, and this is a process I’d like to automate with Tryton, automatically sending a membership invoice with instructions for payment to each active member. Is this something to be done through the association module, or with other customization (a trigger)?

  • I like how you made it easy to mark that the fee was paid, among other conveniences.

I guess it’s not so good that there are difference sources available. Makes it difficult to comment directly on the code review platform, as it may be outdated. Anyway, I left a comment in rietveld.

I’m willing to contribute with code. Let me know if you’d like any.
Let me know if the comments are too out of place here or if it makes any sense to you.

Hi, thanks for the interest (and sorry if the development has slowed down).

Yes, you could that… but it’s not best practice to merge two “concept” in the same DB table.
Reletional databases are called this way for a reason… they’re good at relate things :smiley:

I emulated the pattern of other module to have manually cerate the fee from a certain date with a wizard. Then this wizard can be called from a automatic job on a timer if the user want to automate it. (maybe I’m wrong to think this is a desired pattern)

That was something @htgoebel wanted, and I merged in my branch to test it. After testing it, I too saw it as redundant, at least for my user case, but before a factoring out I wanted some feedback from @htgoebel (and ask here if it was ok to keep it). This is why I didn’t push the new commit to codereview (not the only reason… the main one that I’m a bit busy now)

Yes, This is a feature htgoebel contribuited, but i think the implementation dosn’t fit well (with a function field with a list of active memberships), but this from the membership view in the GUI. I wanted to implement a search fuction, and color the active membership type line in varius colors.
What you want can, maybe, can be accomplished with a relate action.

You join the memebrship when the board, or delegated organ, vote for your inclusion. So this date register this event (and the memebr can be in running state).

You’re a member, or you’re not; there are no in-between. But a membercan have one, or more kind of membership. A member can have a list of membership type and in this list you will define a start_date and end_date for each membership type line, if not specified it will use the join_date and leave_date of the member.

They relate to: when the member joined the association, when the noticed was given (and check it before kick out someone [thanks @htgoebel for this feature]) and when they are kicked out (by the board, or similar organ).

This will not generate invoices, but just recevable lines. Memberships are not service rendered, so they are not invoiceable. Gym memberships =/= Association memberships (one is a “service rendered”, and taxed… the latter is tax exempt).
If you need invoice I think your user case is best modelled by the sale_subscription module (you can still use the module without generate fee line… if you need to have a “book of memebers)”

I’ll read it… thanks for your review (and sorry for the multiple sourced of thruth caused by my lazyness/busyness)

Yes, the more the merrier :smiley:
I can give you permission to push to rietveld… or you can slide me git patches by mail (or if you host somewhere the git repo, I can pull form your fork).

Anyway, as you saw… I like to discuss :smiley:
So if you have other question, you can post here, and I’ll try to respond in a timelly manner.

1 Like

Thanks for the comprehensive answer ^^.

So the Join date should be the same as the start date of the first membership, no? (a calculated field). Isn’t what you explained also what admitted means?

Exactly. My point was that being a member or not would also be a calculation. If there is any running memberships, the party is a member.
The implicitness of the start/end dates feels somewhat shady, adding extra complexity. I don’t see why we need manual fields for join date, and leave date. Those are the dates of membership start and membership end. But enough with this. I also get the point of the current design, and it’s ok how it is

This is not clear from the tooltip and docs. The explanations indicate that the termination date is given by the member. Or is it the idea that the field works both for when the association wants to kick a member out, and for when the member wants to quit their membership?

I am aware of the differences. Associations in Finland do send invoices to charge for the membership fees. Both hobby associations, and labour union associations do it. We don’t need to report a “book of members” in Finland, so being able to see a list of members is enough.

Let me know if you have a todo list for the module.