I think the simplest is to select the first journal with the right type (like in invoice) but allow to customize it by overriding a method on association.membership.
The module is almost ready for review.
I have only one doubt before i summit:
I generate a fee line (association.membership.fee) via a wizard + cronjob.
Should this wizard generate the move line as-well, or should be a manual process?
And if so:
- should the move be posted manually (adding an action/button on the fee line that post the move)
- or should the move be posted automatically by a wizard +cronjob
The first option imply that i create a tree view with a button that call the post action (like move), and will use the today date (or should be the starting date of the period? or should prompt the posting date)
the second imply a new wizard that will ask me the posting date.
I do not think. User will check the fees before posting them.
For me, the creation and the posting can be done at once.
I do not think it is needed. A simple button on the fee is enough.
Dave made some convincing point to change the name of the module
association.membership → association.membership.type
association.membership.line → association.membership
From the codereview
This model seems to represent a type of membership, is that right? If so
perhaps it should be called MembershipType and
association.membership.type?
I am thinking of “membership”, and “membership type” as used in this example:
My friend became a member of a club 5 years ago, his current membership runs
from the start to the end of the year. At the club there are 3 different types
of membership available called standard, honorary, and lifetime. He is an
honorary member, so does not need to pay any fees.
I’m in favor of changing association.membership to association.membership.type, but i want keep the association.membership.line.
What are your opinion in this matter?
ok, another point for discussion.
Should I implement a default date for member join/leave date (like @ced and @pokoli suggested in codereview )
here the discussion:
ced wrote:
wifasoi wrote:
pokoli wrote:
maybe we should add a default value for join date (probably today).this date is important and it can’t be changed afterwards, so having a default
is very dangerous.But normally you encode the date the member joined. So for me, it makes sense to
have a default.
If we decide to have a default, should i permit the user to modify the date in draft?
Now you can only modify the membership line when you go from 'running to ‘draft’, and you cannot go from ‘stopped’ to ‘draft’ (so the leave_date cannot be modified by the user via the gui)
My opinion is to not have a default, so the user will be force to check before committing the membership, and maintain the strict flow. But I’m open for discussion.
P.S:
But normally you encode the date the member joined. […]
What do you mean? You’re referring to the creation date of the record?
For me, yes. The default should not be a constraint.
I think the user should have the right to set the leave_date manually. I guess the button should launch a wizard which ask for a date (default today) and then run the transition for the date (using context).
You are probably right. For the foundation module, I did not set a default start date but I put a pre_validate on the button: tpf/foundation_supporter: eab00d2dc41a foundation.py
Ok, then I’ll add the pre-validation on the button and keep the “strict” flow (user cannot change the date (join/leave) after input, not even in the ‘draft’ state)
No in draft it should be allowed to edit the dates.
It seams there is a bit of ambiquity in this discussion, so sorry for the verbosity of this post.
Right now join_date can be changed in ‘draft’ (so the user can save the record in the draft state, and later modify it before approval), but if the record goes from ‘draft’ to ‘running’, the field will be permanently set to read-only. (I mimic similar behavior like sale_subscription with the start date)
If I understand correctly (and the above is not what you meant) you prefer:
- no default
- add pre-check for empty date field (this will be added regardless)
- permit join_date to be changed in draft (leave date cannot be modified, because you cannot go from ‘stopped’ to ‘draft’ right now)
Please correct me if I’m wrong
For the subscription, the constraint exists because it is required for the computation. For me, such constraint should be added only if the computation can not deal with it.
So it should always be editable in draft except if some other value requires it to not be.
Understood.
There should be any problem, so I’ll relive the constraint.
The generating fee algorithm should be intelligent enough to generate the fees for the new date… but I’ll add a case in the unit test file, just to be sure.
What’s the current situation of this?
The module is under review. But as it is a large module it takes time and effort to review. It is on my TODO list but with a low priority. Others can help reviewing.
I noticed I left out the “maturity date” in the move/fee generation.
Should the “maturity date” be configurable by the end user, or i just set it to the start of the period?
If it need to be a configuration, should be global, for membership type or for period?
The value should be a time-delta from the starting date of the period (IMHO).
It must be set otherwise there will be not dunning.
I think it should be on membership type.
+1
I do not think we need the same complexity as invoice payment term.
Could I help move this forward somehow?
Well, I need to update the code to the new tryton version. Right now i have freelancer work to do, and not much spare time.
But fear not! By the end of the month I’ll surelly update the codebase (I’ll need to update my association tryton instace, so I’m obbligated to do so :P)
1 Like