[16.0][IMP] membership_delegated_partner: allow multiple delegated members per invoice

[flaenen]

It is now possible to define a delegate member per invoice line (in addition to the one defined on the invoice). A customer can therefore be invoiced for the memberships of several partners.

A delegated member defined on an invoice line has priority over the delegated member defined globally on the invoice.

[chienandalu]

Did you see #151 ? There were some issues spotted there with this approach. (fyi @gdgellatly )

In any case, I'm missing test coverage here

[flaenen]

Did you see #151 ? There were some issues spotted there with this approach. (fyi @gdgellatly )

In any case, I'm missing test coverage here

I'll take a look at this PR, thank you.

[gdgellatly]

So in #151 I have passed the torch on that and I have not been involved in a long time, can't quite remember who to, but they are doing the work. 151 has actually been in production for years now for the OCA and IMO should eventually supersede membership_delegated_partner as the preferred module.

The reason for a separate module was technical at the time, something to do with computed fields in the upstream module, I don't really remember. That issue may no longer exist in newer versions.

Given the OCA's reliance on the feature, I imagine this is something that the relevant working group will want to be involved in.

[huguesdk]

i think this approach is much simpler than #151 which introduces a separate and incompatible module.

lgtm.

[gdgellatly]

i think this approach is much simpler than #151 which introduces a separate and incompatible module.

lgtm.

Sure, recent tendencies for people to just do what they want and not worry about anyone who depends on the existing behaviour, but at the time you would never dream of disrupting an existing module and its existing dependencies. That is why it was seperate after discussion with maintainer

[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.

[chienandalu]

Reviewing you approach I agree with @gdgellatly that it would be compatible with both use cases. And this would not introduce incompatibility with the existing base, I think.

In any case, the extra test cases for membership from lines are very much needed, IMO. Maybe you could borrow them from #151