Open carmenbianca opened 9 months ago
@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:
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.
@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:
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?
Yes it sounds like a good idea !
@huguesdk I've implemented your idea. (cf last commit). @carmenbianca
... 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").
Rebased this on top of 6eef0d9 because otherwise there would be merge conflicts and the tests wouldn't run.
Made some small fixes on top of @victor-champonnois 's work. Ready for review+merge I think
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.
Internal task: https://gestion.coopiteasy.be/web#id=11130&action=479&model=project.task&view_type=form&menu_id=536