Closed gdgellatly closed 2 years ago
@gdgellatly I don't even remember why we needed this :sweat_smile: Anyway, sounds like a lot of intricated code to maintain... Let's talk about this :)
If I can help 😄 , I don't get the need. Standard make the same in https://www.aeodoo.org/members . Isn't it?
Hi @rafaelbn,
The issue is that within OCA we bill a company say 500 euro and then apply this membership to them and make their contacts associate members. The existing controller operates on membership lines, of which associate members do not have, so do not display.
The current controller then uses all kinds of domains over membership lines linking the partner records in domain filters. However when I investigated, all of the required fields bar one were on the partner. So I added that to partners and copy/pasted/converted to use partners instead of membership lines.
This is how I solve the problem with existing data, but maybe for future there is a way of explicitly identifying members on the invoice line(s) such that it creates its own member line.
The current controller then uses all kinds of domains over membership lines linking the partner records in domain filters...
Maybe the aproach we used in website_event_filter_city
this module gives you some inspiration:
First we inject a context key in the controller:
That we catch in the model search
and read_group
methods to tweak the domain:
@chienandalu My personal feeling is this won't work. The issue is the controller works on membership lines for countries, partners, pagination etc and we need to change everything to return results that don't exist in member lines.
@chienandalu My personal feeling is this won't work. The issue is the controller works on membership lines for countries, partners, pagination etc and we need to change everything to return results that don't exist in member lines.
I wonder if it would be possible to make those lines as virtual records on the fly that we could use in the moment of the search.
@gdgellatly just a felling 😄 with my best intention. My proposal would be, OK! one invoice per employee but the invoice if for the company and the delegate member is the employee.
https://github.com/OCA/vertical-association/tree/14.0/membership_delegated_partner (Take a look to the readme)
The membership line will go to the delegated partner.
So all the employees are members but al the invoices go to the company (parent).
By the way I would take also this option for administration purposes if I would have to administrate OCA.
With ❤️
Don't forget to automate with contract the renewals!
https://github.com/OCA/vertical-association/tree/14.0/contract_membership_delegated_partner
I can help you if you want.
@rafaelbn we did try that, over 70 percent of our membership is these types of invoices, and these partners don't want 10-50 invoices. It is the process we have.We tried delegated partner and it was no good for this. I might move this to oca-custom, it is a short term fix. Ultimately we want to specify the member on the invoice line.
Perfect @gdgellatly ! Yes, "Ultimately we want to specify the member on the invoice line.", then we should move the "Delegated Partner" to each line. Thank you! ❤️
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.
@simahawk proved a ton more difficult than expected. rough first go at it. no tests yet.