[IMP] cooperator[_website]: Improve form

[carmenbianca]

Internal task: https://gestion.coopiteasy.be/web#id=11130&action=479&model=project.task&view_type=form&menu_id=536

[victor-champonnois]

Functional review

Great, the interface is much better !

Some issues:

• french translations should be updated, but I think we can fix this afterwards in weblate. We just need to remember it.
• to me it's weird that the field "existing contact" stays visible even when the type of subscription is "new cooperator". The fact that it's among the first field makes this even more weird. Is there a reason to keep it visible ? This means that the field should be set to null when the type of subscription is set to new cooperator (after having previously selected an "existing contact").

I think, we can also improve significantly the "Subscription Information" section, at low cost. I am writing a commit to do that.

[victor-champonnois]

I think, we can also improve significantly the "Subscription Information" section, at low cost. I am writing a commit to do that.

done

to me it's weird that the field "existing contact" stays visible even when the type of subscription is "new cooperator". The fact that it's among the first field makes this even more weird. Is there a reason to keep it visible ? This means that the field should be set to null when the type of subscription is set to new cooperator (after having previously selected an "existing contact").

I think this should be considered, I am not sure how the case "existing contact is set" and type of subscription is "new cooperator" is handled, and whether we should prevent it directly from the interface. @huguesdk what do you think ?

[victor-champonnois]

I think this should be considered, I am not sure how the case "existing contact is set" and type of subscription is "new cooperator" is handled, and whether we should prevent it directly from the interface. @huguesdk what do you think ?

nevermind I see it's handled here. It could be nice if it was handled directly in the form, but to me it's OK like this

[victor-champonnois]

cooperative/cooperator/models/subscription_request.py

Lines 750 to 756 in 7ce1aea

	if self.already_cooperator:
	raise UserError(
	_(
	"The checkbox already cooperator is"
	" checked please select a cooperator."
	)
	)

Shouldn't this code be removed or altered now that there is no checkbox ?

[huguesdk]

@victor-champonnois about the “new cooperator” type for an existing contact: it is counter-intuitive, but it is valid and important: this is to allow to create a subscription (to become a cooperator) for a contact (res.partner) that already exists in the database but is not yet a cooperator.

what should be prevented, though, are these combinations:

• type is increase, existing contact is none (existing contact must become required in case of increase) or existing contact is not already a cooperator
• type is new cooperator, existing contact is set to a contact that is already a cooperator

moreover, when an existing contact is selected, all the fields corresponding to the contact properties and not related to the subscription request itself should become read-only, because the contact details will not be updated from the subscription request.

[huguesdk]

@victor-champonnois @carmenbianca i realize that the subscription type should not be editable: it should be read-only and computed from the existing contact field:

• if it is set and the contact is already member: increase
• otherwise: new

it should just be there for information, and i think that a more logical place would be after the existing contact field. what do you think?

[victor-champonnois]

Yes it sounds like a good idea !

[victor-champonnois]

@huguesdk I've implemented your idea. (cf last commit). @carmenbianca

[victor-champonnois]

... and fixed the tests (including some other test errors). Strange, this behavior was in contradiction with one of the test (a sub request for an existing partner that is not yet member was expected to be of type "increase").

[carmenbianca]

Rebased this on top of 6eef0d9 because otherwise there would be merge conflicts and the tests wouldn't run.

[carmenbianca]

Made some small fixes on top of @victor-champonnois 's work. Ready for review+merge I think

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.