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.
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 ‘Member.party’ to be unique - except if member has resigned.
Of course, a Party can be a member of an Association only once at a time.
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
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)
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.
Thanks.
@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.
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).
Anyway:
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
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
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
So if you have other question, you can post here, and I’ll try to respond in a timelly manner.
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.
@wifasoi Since codereview is going to be shut down, can you please ensure your gitlab contains all relevant changes from https://codereview.tryton.org/277491002/ ? I can take care of converting this into into a part of the new mono repository, if you like, I’d be eager to get this module completed.
yep… on my todo list.
Sorry if I was absent, but paraphrasing Britney Spears: “My lower back is trying to kill me” (I cannot stay long in front of a PC for personal health issue).
Anyway,
Me and my my partner in crime updated the module to 6.4, and implemented all the outstanding issue raised in the bug tracker (here the branch), but did not push to the bug tracker for the reason above.
Now need to check against 6.6 if still works, and then I can push a new PR to heptapod.
But as I’ll have surgery soon , I cannot promise any timeline to when it will be done.
Maybe you could upload the current state of the development as a draft (drafts are not mergeable).
That way it won’t be lost and other can also help on your topic.
Are people interested in rising up this topic during Tryton unconference of Berlin in may ?
Do you think we might be able to setup a first version of an association vertical during this event ?
, I cannot promise any timeline to when it will be done.