Association blueprint

A post was split to a new topic: How to support “multi-company” in new module

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.

Indeed it is large. I’ll check it out.

https://codereview.tryton.org/277491002/

1 Like

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

Anything I can help to push this forward?

1 Like

In the top message you can find a code review and an implementation of the blueprint. It is for Tryton version 5.4, but maintained out of the Tryton project. But with a little luck, it will work on 5.8, too, when changing the version in tryton.cfg. When you do a migration, I am sure, @wifasoi is happy to include your patch.

I need to update the patch for the new version of tryton. (It’s on hold because I’m a bit busy with contractor work… and my normal one).

The todo list now is:

  • BUG: I cannot save a draft membership after updating tryton
  • Check for spurious indexes
  • Write better documentation

You can help by codereview my patchset: https://codereview.tryton.org/277491002/

If you want contribute by code, you can fork my project(it’s git not mercurial), and I can merge your branch after my (and my peers at the hackerspace) review. Another way is to forward your patches in the format digestible by “git am”

Another way is nagging me about finishing my projects :smiley: (Usually it works, sometimes extra nagging it’s required)

Another reason why I didn’t update: I lost the base commit hash for the the base commit (needed for uploading the patches in codereview)… no biggie but an hassle.

Indeed you can add a collaborator to the codereview, so they can update the patch directly.

Do not understand, but the patch should be updated to apply on latest trunk of the tryton repository.

It’s not a real issue, just never tried with rietveld (so I’m bit afraid to do it, but nothing that “raw, unadulterated brute force” can’t fix :D). I’ll ask help on the IRC channel when I’ll need to do that (so be ready :P)