Having some questions, I’m going to contact you off-forum.
I’m not going to use codereview.tryton.org since it is a Google service and also requires a Google account.
1 Like
I just sent some patches to @wifasoi.
Here are my comments (having in mind quite a variety of “associations”, from clubs to cooperations)
Dates
- a date of notice of termination is missing - if there is a time for giving notice, it must be documented that the notice arrived in time - depending on the type of assosiaction this might even be a legal requirement.
- If the “leave date” is in the future, a member must not be “stopped” - as this would leave immediately - contrary to the leave date.
- Since stopping a membership can not be reverted, I suggest asking “are you sure?”.
Member
- while a member can be defined for any of the companies, there is a single “Member sequence”. This has at least two issues - when managing several association in one database:
- one can not import an existing member list if Ids overlap
- member Ids of each association will have gaps - which might be an issue depending on type of association and legal requirements
Fees et al:
The mental model behind this design seems to assume there is some fee to be paid per period. (The fee might be zero in case, but basically there is some fee). This can be exemplified be the fact that for defining a Membership Type a revenue account is required. Anyhow:
- Membership might not depend on any money at all
- Example: I’m aware of a club where you are a member by just participating in common activities and being officially accepted as a member. They do not ask fees at all.
- For this case it is “only” confusion if defining a revenue account is required.
- Membership might require to give some capital contribution - which is not a revenue but equity
- Example: Germany Cooperations
- For this case, having accounting defined might be good. Anyhow the restriction on revenue is wrong.
Memberships
-
For adding a new Membership, the member needs to be set to “draft” - even if it already is a member and will continue to be a member. IMHO this works more like a subscription line in sale_subscription: member-typed can be added or ended at will - as long as there is at least one active.
- Example: Academic association: You are a member of the association and in special interest groups
- Example: Switching from personal membership to familiy membership.
Rethinking this, there seem to be quite some similarities with subscriptions
Menu
Since an Association in Tryton is a Company, I suggest these change to the menu structure
- Association » Config →→ Company » Config » Association (like under accounting)
- Association →→ Company » Association
- Members →→ Parties » Members - FMPOV Members are just parties with special attributes.
- Print Member Book IMHO should be removed from the menu, as it is just a report of “Members”
2 Likes
Sorry, I will not use a google service and I will create a Google Account.
Google is a offence to privacy, and I’m not going to use it.
1 Like
If you want but then do not pollute thread with reviews on the wrong place.
Than I can not contribute
It is your choice.
We stop here because it is off-topic.
Well, that’s what I call a heartily welcome to the community.
Merge requests · Infrastruttura / Tryton / mittelab_association · GitLab seems to accept Merge Requests. Perhaps this is a way not to lose your valuable input. Best to check with @wifasoi .
1 Like
I think the post above was in topic, because it’s a design question/opinion, and not a code one.
Anyway:
This was not in scope of my initial proposal, because the radiation/ending process is not automatic by it’s nature (an association is a democratic body, so the radiation process need to be started by the board).
I’m not opposed to add this feature in the scope of this module, because it can be useful.
We can think as a “probation” stage in the main workflow (before stopped). For now it can be a manual process, otherwise a rule engine need to be created (this can be a lot of work to implement).
In the probation stage you’re still a member, but onwill be sent to the member advising
Fair enough. There is no automatic mechanism right now, I just not generate the membership fee. So this need to be implemented (IMHO)
Well, by definition an association has one Book of members (by definition). So I don’t get the the user case. (maybe you can give me an example, if you have one in mind)
Well, a membership fee is required in my country (and set at minimum of 5€)… otherwise an association is just a way to provide services to members without paying the required taxes (many association in my country get this wrong).
Well, if you don’t charge fees, why you need of this module? 
But i think we can accommodate this user case
Well, I can add a required pyson rule like:
- if a line in the membership line > 0 => account required.
Don’t know if it’s feasible (need to try it first).
Then i need to update the query for fee line generation, so i exclude fee with value == 0
well, the you’re not an association… you’re a cooperation by your definition (maybe another module is required for this user case)
usually the member changes ID on re-subscription. You need to keep a record of when the member leave and then when to rejoin… and this is the simplest way (and is the way it’s done when you do it by hand). (remember… ID number are cheap :D)
A member in draft state is not a member, because each member need to be approved by the board (maybe it’s transparent to the member, but this needs to be done in Italy) then it can be added to the book of members.
A membership is personal and not transferable, by definition…
A member is a person, or an entity (another association) that gets one vote.
You’re thinking about fees for gim, soccer practice… they are SERVICES with recurring fee structure. Not membership fees (English here is a bit ambiguous), and so better serviced by the sale_subscription module.
If you do this with an association you need to pay all the past taxed you didn’t pay… because for the state you’re retroactively a company (yes… fun times here)
Well association are not companies. And association can have other thing over the book of members (like a book of volunteers… that can be another module).
So it’s fair to keep it separate from the company.
Party is the model that keeps of the personal info of the member. And the member’s book is were you keep track of witch party is a member (in party you can have a mix of supplier, customer… and sometimes both).
So I’m for keeping the status quo.
1 Like
According to my translator “probation” is at the beginning - prior to be accepted as a full member. We could prepare such a state, but I would not put it into the standard workflow as FMPOV this is rarely used.
Not sure what you mean: Member did not follow its duties, go a warning by the baord and maybe is no longer allowed to participate (in parts or at all)? This could be useful. Again, I would not make it part of the standard workflow.
(We could prepare several workflows plus a config wizard to choose.)
Try this: Have two Companies defined, add a member to each of the Companies/Associations. add another member to the first one. In the Book of Members of the first Company there will be member Ids 1 and 3. Number 2 is missing - as this Id has been given to the member of the other association.
Well, in my country it is not required 
This is way I wrote about “mental model”: Some where above was a discussion about whether one becomes a member after paying the fees (as ced assumed), or one becomes a member (e.g. by being accepted by the board) and paying the fees is an obligation for all members (as you say). I’m adding a third model: one becomes a member (e.g. by being accepted by the board) but there are no fees.
Well, to manage other states of or information about a “member”, like e.g. enter and leave date, birthday. How else do you want to honor “30 years of membership” or send a postcode for the 80th birthday?
The English term “association” is a quite generic term. association - LEO: Übersetzung im Englisch ⇔ Deutsch Wörterbuch lists 21 different meanings: from informal forms over clubs, larger family, working associations and cooperations to generic “organization”.
The Italian term “associazione” seems to be more like a club or society.
If this module is for the later only, it might be worth to consider renaming it to get away from the generic term.
(Sorry, I meant “For adding a now membership type”)
Exactly this is the point!
Imagine a hackspace 
Your a member since long, now you are joining the Python special interest group. FMPOV this would be an additional membership type - which would allow selecting all members of the Python SIG, or see which SIGs a member is participating in.
Anyhow. you are still a member and your basic membership does not need to be approved by the boards (the membership in the SIG might, but this is another topic). As of now one can not add “Python SIGs” to the membership without moving the member to “draft”.
I’m not transferring the membership, but changing the type/fee.
Imagine a sports club: I’m the member since I’m 12 years old. When I marry, I can change my member ship type to “Family”, so my partner (any maybe kids) can also use the club’s facilities. Still I’m the member and I have the vote. the family are only the annexure.
This might be the case in your jurisdiction, but might not be the case in others.
Since within the model each Association is exactly on Company, I don’t see much sense in adding another menu entry. If the mnue item “Company” would be called “Organisation” it would fit perfectly IMHO.
Also all “Books of …” are just reports about parties being a member. (Yes, this way round: you could even be a volunteer without being a member.)
Yes, that sounds right: Probation (workplace) - Wikipedia
Yes, it looks like that would be possible with the design, as noted here:
Yes, you are right, but if this module is used for (or as the base of modules for) various types of association, such as clubs, voluntary associations, and societies, then I think it might be hard to come up with a better name, which is more specific but still covers all the use cases.
Yes, that sounds right, but this is how other referential models in Tryton work (such as party and product).
Perhaps the association.membership model could have a number field that is sequential for each different association (like with sale or purchase), and this number is used in the book of members?
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 . 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
I blame the babel tower for this misunderstanding
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 
General
- 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
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?
1 Like
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 https://gitlab.com/htgoebel/trytond-mittelab_association.
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.
1 Like
First of all, thank you for your work regardless
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 
Don’t worry, it will go in codereview
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.