Archives
Contributors
-
Activate runboat in donation's repo
Dear Contributors,
As runboat it quite new, could I ask how to activate it in a repo that still have runbot?
In this case:
https://github.com/OCA/donation/tree/14.0/donation
Thank you
Regards,
Rafael
by Rafael Blasco (Moduon) - 05:00 - 16 Feb 2022 -
PSC in project & service
Dear Contributors,
Jairo sent an email yesterday, but it looks like the OCA Odoo didn’t send it.
:+1 for me
Thank you!
Rafael
PSC in project & service
by "Jairo Llopis" jairo@moduon.team - 14/02/2022 08:30:33
Hi dear community.
I would like to ask permissions to be PSC in the project & service group.
https://odoo-community.org/psc-teams/project-service-28
My profile: https://github.com/Yajo
Thanks!
by Rafael Blasco (Moduon) - 01:06 - 15 Feb 2022 -
Re: New repositories : cooperative and participative supermarket
I would be glad to join.I agree with Robin. Not sure that the PSC association is suitable as from what I see it covers mainly the membership aspect. While a cooperative verticalization will mainly cover the specifics for a commercial cooperative company as the share management for example.Anyway there is also a membership aspect for cooperative but it is far different from the way it is conceived for association.Le jeu. 10 févr. 2022 à 10:46, Enrico Stano <enrico.stano@coopdevs.org> a écrit :+1 on Rémy and/or Houssine of course.
If needed, from Coopdevs we would be glad to participate (Daniel Palomar or myself). Thanks.
Not sure about the "Association" PSC, it also seems unrelated IMHO. But maybe PSC members from "Association" have a different opinion. Could we ask?
Bye,
Enrico
coopdevs.org
On 2/9/22 19:17, robin@coopiteasy.be wrote:
Rémy Taymans (remy@coopiteasy.be) should be in the PSC as well. Is there candidates at Coopdevs ? If Houssine Bakkali is still around and interested, he would be a good candidate as well.
Expanding “Association” could work if we need to have people outside of Coop IT Easy in the PSC. Otherwise, it seems unrelated.
All the best,
On 9 Feb 2022, 18:42 +0100, Daniel Reis <dreis@opensourceintegrators.com>, wrote:
Would it be simpler to reuse/expand scope of the existing "Association" PSC?
https://odoo-community.org/psc-teams/association-91
/Daniel
On 09/02/22 17:32, Stéphane Bidoul wrote:
Ok, so what do we do in terms of PSC, PSC Representative, and PSC Members ?
I don't immediately see an existing PSC to cover this scope.So shall we create one new PSC (named Ccooperative?) for the 3 repos ?Who would be the PSC representative (Robin?). Who would be the first members ?-sbi
On Wed, Feb 9, 2022 at 10:47 AM Valentin Vinagre Urteaga <valentin.vinagre@sygel.es> wrote:
+1 :D
El mié, 9 feb 2022 a las 10:02, Enrico Stano (<enrico.stano@coopdevs.org>) escribió:
Hi,
+1 and a big thank you!
Bye,
Enrico Stano
On 1/27/22 18:57, Roussel, Denis wrote:
Hi Robin,
+1 for the three repos.
On Thu, Jan 27, 2022 at 6:22 PM <robin@coopiteasy.be> wrote:
Hi Denis,
Thank you for your answer, it looks like my last email did not go through. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.
As for refining the topics, I can try to rephrase :-)
- oca/cooperative would hold the modules allowing to
- Subscribe to a share, transfer a share or sell a share from the cooperative,
- Share subscription can be done online,
- Manage the cooperator registry of a cooperative,
- Generate legal reports for company and cooperators.
- oca/shift-planning would hold the modules allowing to
- Create a planning template of work shifts of the company
- Generate the shifts based on these templates,
- Allow partners to subscribe to regular tasks,
- Allow partners to subscribe to any task with available spot,
- Track the attendance to the shifts.
- oca/vertical-cooperative-supermarket* glues all these together to
- Track who can work in the cooperative
- Track who can shop in the cooperative
- welcome screens and member cards
* once cleaned up from all sale, purchase, pos, ... customisations.
I hope it’s clearer that way,
On 17 Jan 2022, 18:25 +0100, robin@coopiteasy.be, wrote:Hi Denis,
Thank you for your answer. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.
Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
As for refining the topics, I can try to rephrase :-)
• oca/cooperative would hold the modules allowing to
• Subscribe to a share, transfer a share or sell a share from the cooperative,
• Share subscription can be done online,
• Manage the cooperator registry of a cooperative,
• Generate legal reports for company and cooperators.
• oca/shift-planning would hold the modules allowing to
• Create a planning template of work shifts of the company
• Generate the shifts based on these templates,
• Allow partners to subscribe to regular tasks,
• Allow partners to subscribe to any task with available spot,
• Track the attendance to the shifts.
• oca/vertical-cooperative-supermarket* glues all these together to
• Track who can work in the cooperative
• Track who can shop in the cooperative
* once cleaned up from all sale, purchase, pos, ... customisations.
I hope it’s clearer that way,
Robin Keunen
Coop IT Easy
robin@coopiteasy.be
+32 488 86 57 40
On 14 Jan 2022, 18:32 +0100, Roussel, Denis <denis.roussel@acsone.eu>, wrote:
Hi Robin,
That's great to hear this!
My two cents on this. Maybe you should refine the topics the repositories you want to create will cover (it does not help saying they are in beta). Especially for the first one.
For the third, we usually don't create 'temporary' repositories. I suggest you to create issues/PR's directly on OCA specific repos for modules you want to move. It will be more efficient and avoiding creation of one that will be deleted actually.
Don't hesitate if you have more technical questions, but for sure you have a good OCA contact person near you !
On Fri, Jan 14, 2022 at 11:27 AM <robin@coopiteasy.be> wrote:
Hi all,
At Coop IT Easy, we’ve been working for 5 years with cooperative and participatory supermarkets (aka Food Coop, ex: BEES coop). We would like to bring most of that code under the OCA umbrella. The code is now divided into two repositories :
cooperative/vertical-cooperative modules deal with share subscriptions, cooperator registry, online registrations, etc. equivalent to oca/vertical-association ;
beescoop/obeesdoo contains modules to manage the work of the members (planning their shifts) and many customisations to sales, purchase, stock and point of sales.
We will need to
remove all references to Obeesdoo and Easy My Coop (debranding) ;
split modules by features ;
cover more code with unit tests.
These solutions have been used in production for several years now and is now used by 11 supermarkets and 25+ cooperatives (plus a few others by other integrators). Everything is in version 12 and we will soon migrate cooperative modules to version 14.
Based on the OCA repository policy, we would like to propose to create these 3 new repositories :
cooperative with all modules in beta-stage while we debrand them.
shift-planning (or shift-management ?) with all modules dealing with shifts in beta stage as well.
vertical-cooperative-supermarket as an incubation repository while we move all the features to oca/purchase-workflow, oca/pos, …
What do you think ? Is there room for these projects at the OCA ?
You can find more information on these Github Issues RFC Moving Obeesdoo to OCA #247 and RFC Moving Easy My Coop to OCA.
All inputs welcome,
Robin Keunen
Robin Keunen
Coop IT Easy
robin@coopiteasy.be
+32 488 86 57 40
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe
--
Denis RousselSoftware EngineerT : +32 2 888 31 49M : +32 472 22 00 57
Val Benoit, Quai Banning 6 | B-4000 Liège | BelgiumAtrium Building, Drève Richelle 167 | B-1410 Waterloo | BelgiumZone industrielle 22 | L-8287 Kehlen | Luxembourg_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
Atrium Building, Drève Richelle 167 | B-1410 Waterloo | BelgiumZone industrielle 22 | L-8287 Kehlen | Luxembourg
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- Enrico Stano coopdevs.org_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Valentín Vinagre Urteaga
CTO
Sygel Technology S.L
+34 662 68 78 95 
valentin.vinagre@sygel.es 
https://www.sygel.es 
C/ Àlaba 61, 5ª planta, 08005, Barcelona _______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING DIRECTORM: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office B, #34
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- Enrico Stano coopdevs.org_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Houssine BAKKALI - 11:01 - 10 Feb 2022 -
Re: New repositories : cooperative and participative supermarket
+1 on Rémy and/or Houssine of course.
If needed, from Coopdevs we would be glad to participate (Daniel Palomar or myself). Thanks.
Not sure about the "Association" PSC, it also seems unrelated IMHO. But maybe PSC members from "Association" have a different opinion. Could we ask?
Bye,
Enrico
coopdevs.org
On 2/9/22 19:17, robin@coopiteasy.be wrote:
Rémy Taymans (remy@coopiteasy.be) should be in the PSC as well. Is there candidates at Coopdevs ? If Houssine Bakkali is still around and interested, he would be a good candidate as well.
Expanding “Association” could work if we need to have people outside of Coop IT Easy in the PSC. Otherwise, it seems unrelated.
All the best,
On 9 Feb 2022, 18:42 +0100, Daniel Reis <dreis@opensourceintegrators.com>, wrote:
Would it be simpler to reuse/expand scope of the existing "Association" PSC?
https://odoo-community.org/psc-teams/association-91
/Daniel
On 09/02/22 17:32, Stéphane Bidoul wrote:
Ok, so what do we do in terms of PSC, PSC Representative, and PSC Members ?
I don't immediately see an existing PSC to cover this scope.So shall we create one new PSC (named Ccooperative?) for the 3 repos ?Who would be the PSC representative (Robin?). Who would be the first members ?-sbi
On Wed, Feb 9, 2022 at 10:47 AM Valentin Vinagre Urteaga <valentin.vinagre@sygel.es> wrote:
+1 :D
El mié, 9 feb 2022 a las 10:02, Enrico Stano (<enrico.stano@coopdevs.org>) escribió:
Hi,
+1 and a big thank you!
Bye,
Enrico Stano
On 1/27/22 18:57, Roussel, Denis wrote:
Hi Robin,
+1 for the three repos.
On Thu, Jan 27, 2022 at 6:22 PM <robin@coopiteasy.be> wrote:
Hi Denis,
Thank you for your answer, it looks like my last email did not go through. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.
As for refining the topics, I can try to rephrase :-)
- oca/cooperative would hold the modules allowing to
- Subscribe to a share, transfer a share or sell a share from the cooperative,
- Share subscription can be done online,
- Manage the cooperator registry of a cooperative,
- Generate legal reports for company and cooperators.
- oca/shift-planning would hold the modules allowing to
- Create a planning template of work shifts of the company
- Generate the shifts based on these templates,
- Allow partners to subscribe to regular tasks,
- Allow partners to subscribe to any task with available spot,
- Track the attendance to the shifts.
- oca/vertical-cooperative-supermarket* glues all these together to
- Track who can work in the cooperative
- Track who can shop in the cooperative
- welcome screens and member cards
* once cleaned up from all sale, purchase, pos, ... customisations.
I hope it’s clearer that way,
On 17 Jan 2022, 18:25 +0100, robin@coopiteasy.be, wrote:Hi Denis,
Thank you for your answer. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.
Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
As for refining the topics, I can try to rephrase :-)
• oca/cooperative would hold the modules allowing to
• Subscribe to a share, transfer a share or sell a share from the cooperative,
• Share subscription can be done online,
• Manage the cooperator registry of a cooperative,
• Generate legal reports for company and cooperators.
• oca/shift-planning would hold the modules allowing to
• Create a planning template of work shifts of the company
• Generate the shifts based on these templates,
• Allow partners to subscribe to regular tasks,
• Allow partners to subscribe to any task with available spot,
• Track the attendance to the shifts.
• oca/vertical-cooperative-supermarket* glues all these together to
• Track who can work in the cooperative
• Track who can shop in the cooperative
* once cleaned up from all sale, purchase, pos, ... customisations.
I hope it’s clearer that way,
Robin Keunen
Coop IT Easy
robin@coopiteasy.be
+32 488 86 57 40
On 14 Jan 2022, 18:32 +0100, Roussel, Denis <denis.roussel@acsone.eu>, wrote:
Hi Robin,
That's great to hear this!
My two cents on this. Maybe you should refine the topics the repositories you want to create will cover (it does not help saying they are in beta). Especially for the first one.
For the third, we usually don't create 'temporary' repositories. I suggest you to create issues/PR's directly on OCA specific repos for modules you want to move. It will be more efficient and avoiding creation of one that will be deleted actually.
Don't hesitate if you have more technical questions, but for sure you have a good OCA contact person near you !
On Fri, Jan 14, 2022 at 11:27 AM <robin@coopiteasy.be> wrote:
Hi all,
At Coop IT Easy, we’ve been working for 5 years with cooperative and participatory supermarkets (aka Food Coop, ex: BEES coop). We would like to bring most of that code under the OCA umbrella. The code is now divided into two repositories :
cooperative/vertical-cooperative modules deal with share subscriptions, cooperator registry, online registrations, etc. equivalent to oca/vertical-association ;
beescoop/obeesdoo contains modules to manage the work of the members (planning their shifts) and many customisations to sales, purchase, stock and point of sales.
We will need to
remove all references to Obeesdoo and Easy My Coop (debranding) ;
split modules by features ;
cover more code with unit tests.
These solutions have been used in production for several years now and is now used by 11 supermarkets and 25+ cooperatives (plus a few others by other integrators). Everything is in version 12 and we will soon migrate cooperative modules to version 14.
Based on the OCA repository policy, we would like to propose to create these 3 new repositories :
cooperative with all modules in beta-stage while we debrand them.
shift-planning (or shift-management ?) with all modules dealing with shifts in beta stage as well.
vertical-cooperative-supermarket as an incubation repository while we move all the features to oca/purchase-workflow, oca/pos, …
What do you think ? Is there room for these projects at the OCA ?
You can find more information on these Github Issues RFC Moving Obeesdoo to OCA #247 and RFC Moving Easy My Coop to OCA.
All inputs welcome,
Robin Keunen
Robin Keunen
Coop IT Easy
robin@coopiteasy.be
+32 488 86 57 40
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe
--
Denis RousselSoftware EngineerT : +32 2 888 31 49M : +32 472 22 00 57
Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
Atrium Building, Drève Richelle 167 | B-1410 Waterloo | BelgiumZone industrielle 22 | L-8287 Kehlen | Luxembourg
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- Enrico Stano coopdevs.org_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Valentín Vinagre Urteaga
CTO
Sygel Technology S.L
+34 662 68 78 95 valentin.vinagre@sygel.es https://www.sygel.es C/ Àlaba 61, 5ª planta, 08005, Barcelona _______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING DIRECTORM: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office B, #34
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- Enrico Stano coopdevs.org
by Enrico Stano - 10:45 - 10 Feb 2022 -
Re: New repositories : cooperative and participative supermarket
Rémy Taymans (remy@coopiteasy.be) should be in the PSC as well. Is there candidates at Coopdevs ? If Houssine Bakkali is still around and interested, he would be a good candidate as well.
Expanding “Association” could work if we need to have people outside of Coop IT Easy in the PSC. Otherwise, it seems unrelated.
All the best,
Robin KeunenCoop IT Easyrobin@coopiteasy.be+32 488 86 57 40On 9 Feb 2022, 18:42 +0100, Daniel Reis <dreis@opensourceintegrators.com>, wrote:
Would it be simpler to reuse/expand scope of the existing "Association" PSC?
https://odoo-community.org/psc-teams/association-91
/Daniel
On 09/02/22 17:32, Stéphane Bidoul wrote:Ok, so what do we do in terms of PSC, PSC Representative, and PSC Members ?I don't immediately see an existing PSC to cover this scope.So shall we create one new PSC (named Ccooperative?) for the 3 repos ?Who would be the PSC representative (Robin?). Who would be the first members ?-sbi
On Wed, Feb 9, 2022 at 10:47 AM Valentin Vinagre Urteaga <valentin.vinagre@sygel.es> wrote:+1 :D
El mié, 9 feb 2022 a las 10:02, Enrico Stano (<enrico.stano@coopdevs.org>) escribió:Hi,
+1 and a big thank you!
Bye,
Enrico Stano
On 1/27/22 18:57, Roussel, Denis wrote:Hi Robin,+1 for the three repos.
On Thu, Jan 27, 2022 at 6:22 PM <robin@coopiteasy.be> wrote:Hi Denis,
Thank you for your answer, it looks like my last email did not go through. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.
As for refining the topics, I can try to rephrase :-)
- oca/cooperative would hold the modules allowing to
- Subscribe to a share, transfer a share or sell a share from the cooperative,
- Share subscription can be done online,
- Manage the cooperator registry of a cooperative,
- Generate legal reports for company and cooperators.
- oca/shift-planning would hold the modules allowing to
- Create a planning template of work shifts of the company
- Generate the shifts based on these templates,
- Allow partners to subscribe to regular tasks,
- Allow partners to subscribe to any task with available spot,
- Track the attendance to the shifts.
- oca/vertical-cooperative-supermarket* glues all these together to
- Track who can work in the cooperative
- Track who can shop in the cooperative
- welcome screens and member cards
* once cleaned up from all sale, purchase, pos, ... customisations.
I hope it’s clearer that way,
On 17 Jan 2022, 18:25 +0100, robin@coopiteasy.be, wrote:Hi Denis,
Thank you for your answer. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.
Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
As for refining the topics, I can try to rephrase :-)
• oca/cooperative would hold the modules allowing to
• Subscribe to a share, transfer a share or sell a share from the cooperative,
• Share subscription can be done online,
• Manage the cooperator registry of a cooperative,
• Generate legal reports for company and cooperators.
• oca/shift-planning would hold the modules allowing to
• Create a planning template of work shifts of the company
• Generate the shifts based on these templates,
• Allow partners to subscribe to regular tasks,
• Allow partners to subscribe to any task with available spot,
• Track the attendance to the shifts.
• oca/vertical-cooperative-supermarket* glues all these together to
• Track who can work in the cooperative
• Track who can shop in the cooperative
* once cleaned up from all sale, purchase, pos, ... customisations.
I hope it’s clearer that way,
Robin Keunen
Coop IT Easy
robin@coopiteasy.be
+32 488 86 57 40
On 14 Jan 2022, 18:32 +0100, Roussel, Denis <denis.roussel@acsone.eu>, wrote:
Hi Robin,
That's great to hear this!
My two cents on this. Maybe you should refine the topics the repositories you want to create will cover (it does not help saying they are in beta). Especially for the first one.
For the third, we usually don't create 'temporary' repositories. I suggest you to create issues/PR's directly on OCA specific repos for modules you want to move. It will be more efficient and avoiding creation of one that will be deleted actually.
Don't hesitate if you have more technical questions, but for sure you have a good OCA contact person near you !
On Fri, Jan 14, 2022 at 11:27 AM <robin@coopiteasy.be> wrote:
Hi all,
At Coop IT Easy, we’ve been working for 5 years with cooperative and participatory supermarkets (aka Food Coop, ex: BEES coop). We would like to bring most of that code under the OCA umbrella. The code is now divided into two repositories :
cooperative/vertical-cooperative modules deal with share subscriptions, cooperator registry, online registrations, etc. equivalent to oca/vertical-association ;
beescoop/obeesdoo contains modules to manage the work of the members (planning their shifts) and many customisations to sales, purchase, stock and point of sales.
We will need to
remove all references to Obeesdoo and Easy My Coop (debranding) ;
split modules by features ;
cover more code with unit tests.
These solutions have been used in production for several years now and is now used by 11 supermarkets and 25+ cooperatives (plus a few others by other integrators). Everything is in version 12 and we will soon migrate cooperative modules to version 14.
Based on the OCA repository policy, we would like to propose to create these 3 new repositories :
cooperative with all modules in beta-stage while we debrand them.
shift-planning (or shift-management ?) with all modules dealing with shifts in beta stage as well.
vertical-cooperative-supermarket as an incubation repository while we move all the features to oca/purchase-workflow, oca/pos, …
What do you think ? Is there room for these projects at the OCA ?
You can find more information on these Github Issues RFC Moving Obeesdoo to OCA #247 and RFC Moving Easy My Coop to OCA.
All inputs welcome,
Robin Keunen
Robin Keunen
Coop IT Easy
robin@coopiteasy.be
+32 488 86 57 40
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe
--
Denis RousselSoftware EngineerT : +32 2 888 31 49M : +32 472 22 00 57
Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Val Benoit, Quai Banning 6 | B-4000 Liège | BelgiumAtrium Building, Drève Richelle 167 | B-1410 Waterloo | BelgiumZone industrielle 22 | L-8287 Kehlen | Luxembourg_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe-- Enrico Stano coopdevs.org_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Valentín Vinagre Urteaga
CTO
Sygel Technology S.L
+34 662 68 78 95 valentin.vinagre@sygel.es https://www.sygel.es C/ Àlaba 61, 5ª planta, 08005, Barcelona _______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING DIRECTORM: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office B, #34_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Robin Keunen - 07:16 - 9 Feb 2022 -
Re: New repositories : cooperative and participative supermarket
Would it be simpler to reuse/expand scope of the existing "Association" PSC?
https://odoo-community.org/psc-teams/association-91
/Daniel
On 09/02/22 17:32, Stéphane Bidoul wrote:
Ok, so what do we do in terms of PSC, PSC Representative, and PSC Members ?
I don't immediately see an existing PSC to cover this scope.So shall we create one new PSC (named Ccooperative?) for the 3 repos ?Who would be the PSC representative (Robin?). Who would be the first members ?-sbi
On Wed, Feb 9, 2022 at 10:47 AM Valentin Vinagre Urteaga <valentin.vinagre@sygel.es> wrote:
+1 :D
El mié, 9 feb 2022 a las 10:02, Enrico Stano (<enrico.stano@coopdevs.org>) escribió:
Hi,
+1 and a big thank you!
Bye,
Enrico Stano
On 1/27/22 18:57, Roussel, Denis wrote:
Hi Robin,
+1 for the three repos.
On Thu, Jan 27, 2022 at 6:22 PM <robin@coopiteasy.be> wrote:
Hi Denis,
Thank you for your answer, it looks like my last email did not go through. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.
As for refining the topics, I can try to rephrase :-)
- oca/cooperative would hold the modules allowing to
- Subscribe to a share, transfer a share or sell a share from the cooperative,
- Share subscription can be done online,
- Manage the cooperator registry of a cooperative,
- Generate legal reports for company and cooperators.
- oca/shift-planning would hold the modules allowing to
- Create a planning template of work shifts of the company
- Generate the shifts based on these templates,
- Allow partners to subscribe to regular tasks,
- Allow partners to subscribe to any task with available spot,
- Track the attendance to the shifts.
- oca/vertical-cooperative-supermarket* glues all these together to
- Track who can work in the cooperative
- Track who can shop in the cooperative
- welcome screens and member cards
* once cleaned up from all sale, purchase, pos, ... customisations.
I hope it’s clearer that way,
On 17 Jan 2022, 18:25 +0100, robin@coopiteasy.be, wrote:Hi Denis,
Thank you for your answer. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.
Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
As for refining the topics, I can try to rephrase :-)
• oca/cooperative would hold the modules allowing to
• Subscribe to a share, transfer a share or sell a share from the cooperative,
• Share subscription can be done online,
• Manage the cooperator registry of a cooperative,
• Generate legal reports for company and cooperators.
• oca/shift-planning would hold the modules allowing to
• Create a planning template of work shifts of the company
• Generate the shifts based on these templates,
• Allow partners to subscribe to regular tasks,
• Allow partners to subscribe to any task with available spot,
• Track the attendance to the shifts.
• oca/vertical-cooperative-supermarket* glues all these together to
• Track who can work in the cooperative
• Track who can shop in the cooperative
* once cleaned up from all sale, purchase, pos, ... customisations.
I hope it’s clearer that way,
Robin Keunen
Coop IT Easy
robin@coopiteasy.be
+32 488 86 57 40
On 14 Jan 2022, 18:32 +0100, Roussel, Denis <denis.roussel@acsone.eu>, wrote:
Hi Robin,
That's great to hear this!
My two cents on this. Maybe you should refine the topics the repositories you want to create will cover (it does not help saying they are in beta). Especially for the first one.
For the third, we usually don't create 'temporary' repositories. I suggest you to create issues/PR's directly on OCA specific repos for modules you want to move. It will be more efficient and avoiding creation of one that will be deleted actually.
Don't hesitate if you have more technical questions, but for sure you have a good OCA contact person near you !
On Fri, Jan 14, 2022 at 11:27 AM <robin@coopiteasy.be> wrote:
Hi all,
At Coop IT Easy, we’ve been working for 5 years with cooperative and participatory supermarkets (aka Food Coop, ex: BEES coop). We would like to bring most of that code under the OCA umbrella. The code is now divided into two repositories :
cooperative/vertical-cooperative modules deal with share subscriptions, cooperator registry, online registrations, etc. equivalent to oca/vertical-association ;
beescoop/obeesdoo contains modules to manage the work of the members (planning their shifts) and many customisations to sales, purchase, stock and point of sales.
We will need to
remove all references to Obeesdoo and Easy My Coop (debranding) ;
split modules by features ;
cover more code with unit tests.
These solutions have been used in production for several years now and is now used by 11 supermarkets and 25+ cooperatives (plus a few others by other integrators). Everything is in version 12 and we will soon migrate cooperative modules to version 14.
Based on the OCA repository policy, we would like to propose to create these 3 new repositories :
cooperative with all modules in beta-stage while we debrand them.
shift-planning (or shift-management ?) with all modules dealing with shifts in beta stage as well.
vertical-cooperative-supermarket as an incubation repository while we move all the features to oca/purchase-workflow, oca/pos, …
What do you think ? Is there room for these projects at the OCA ?
You can find more information on these Github Issues RFC Moving Obeesdoo to OCA #247 and RFC Moving Easy My Coop to OCA.
All inputs welcome,
Robin Keunen
Robin Keunen
Coop IT Easy
robin@coopiteasy.be
+32 488 86 57 40
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe
--
Denis RousselSoftware EngineerT : +32 2 888 31 49M : +32 472 22 00 57
Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
Atrium Building, Drève Richelle 167 | B-1410 Waterloo | BelgiumZone industrielle 22 | L-8287 Kehlen | Luxembourg
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- Enrico Stano coopdevs.org_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Valentín Vinagre Urteaga
CTO
Sygel Technology S.L
+34 662 68 78 95 valentin.vinagre@sygel.es https://www.sygel.es C/ Àlaba 61, 5ª planta, 08005, Barcelona _______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING DIRECTORM: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office B, #34
by Daniel Reis - 06:41 - 9 Feb 2022 -
Re: New repositories : cooperative and participative supermarket
Ok, so what do we do in terms of PSC, PSC Representative, and PSC Members ?I don't immediately see an existing PSC to cover this scope.So shall we create one new PSC (named Ccooperative?) for the 3 repos ?Who would be the PSC representative (Robin?). Who would be the first members ?-sbiOn Wed, Feb 9, 2022 at 10:47 AM Valentin Vinagre Urteaga <valentin.vinagre@sygel.es> wrote:+1 :DEl mié, 9 feb 2022 a las 10:02, Enrico Stano (<enrico.stano@coopdevs.org>) escribió:Hi,
+1 and a big thank you!
Bye,
Enrico Stano
On 1/27/22 18:57, Roussel, Denis wrote:
Hi Robin,
+1 for the three repos.
On Thu, Jan 27, 2022 at 6:22 PM <robin@coopiteasy.be> wrote:
Hi Denis,
Thank you for your answer, it looks like my last email did not go through. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.
As for refining the topics, I can try to rephrase :-)
- oca/cooperative would hold the modules allowing to
- Subscribe to a share, transfer a share or sell a share from the cooperative,
- Share subscription can be done online,
- Manage the cooperator registry of a cooperative,
- Generate legal reports for company and cooperators.
- oca/shift-planning would hold the modules allowing to
- Create a planning template of work shifts of the company
- Generate the shifts based on these templates,
- Allow partners to subscribe to regular tasks,
- Allow partners to subscribe to any task with available spot,
- Track the attendance to the shifts.
- oca/vertical-cooperative-supermarket* glues all these together to
- Track who can work in the cooperative
- Track who can shop in the cooperative
- welcome screens and member cards
* once cleaned up from all sale, purchase, pos, ... customisations.
I hope it’s clearer that way,
On 17 Jan 2022, 18:25 +0100, robin@coopiteasy.be, wrote:Hi Denis,
Thank you for your answer. My suggestion to create an temporary or incubation repository comes from this oca_repository_policy.rst but I may have dug up a deprecated article. In this article, I also read about beta modules :
The incubation approach was introduced to lower the barrier to the entry of new contributors and ease collaboration. Code that is included in the OCA under the incubation process is intended to be actively improved until it reaches a Stable level, or can stands as a challenger to an existing Stable module providing a similar feature. Incubation code that was abandoned should be deleted.
The idea was to mark the modules as beta while we remove all the references to customer names but it’s all stable in the current state.
Incubated modules are hosted in the same repositories as stable ones, but are labelled with a Alpha or Beta maturity level.
As for refining the topics, I can try to rephrase :-)
• oca/cooperative would hold the modules allowing to
• Subscribe to a share, transfer a share or sell a share from the cooperative,
• Share subscription can be done online,
• Manage the cooperator registry of a cooperative,
• Generate legal reports for company and cooperators.
• oca/shift-planning would hold the modules allowing to
• Create a planning template of work shifts of the company
• Generate the shifts based on these templates,
• Allow partners to subscribe to regular tasks,
• Allow partners to subscribe to any task with available spot,
• Track the attendance to the shifts.
• oca/vertical-cooperative-supermarket* glues all these together to
• Track who can work in the cooperative
• Track who can shop in the cooperative
* once cleaned up from all sale, purchase, pos, ... customisations.
I hope it’s clearer that way,
Robin Keunen
Coop IT Easy
robin@coopiteasy.be
+32 488 86 57 40
On 14 Jan 2022, 18:32 +0100, Roussel, Denis <denis.roussel@acsone.eu>, wrote:
Hi Robin,
That's great to hear this!
My two cents on this. Maybe you should refine the topics the repositories you want to create will cover (it does not help saying they are in beta). Especially for the first one.
For the third, we usually don't create 'temporary' repositories. I suggest you to create issues/PR's directly on OCA specific repos for modules you want to move. It will be more efficient and avoiding creation of one that will be deleted actually.
Don't hesitate if you have more technical questions, but for sure you have a good OCA contact person near you !
On Fri, Jan 14, 2022 at 11:27 AM <robin@coopiteasy.be> wrote:
Hi all,
At Coop IT Easy, we’ve been working for 5 years with cooperative and participatory supermarkets (aka Food Coop, ex: BEES coop). We would like to bring most of that code under the OCA umbrella. The code is now divided into two repositories :
cooperative/vertical-cooperative modules deal with share subscriptions, cooperator registry, online registrations, etc. equivalent to oca/vertical-association ;
beescoop/obeesdoo contains modules to manage the work of the members (planning their shifts) and many customisations to sales, purchase, stock and point of sales.
We will need to
remove all references to Obeesdoo and Easy My Coop (debranding) ;
split modules by features ;
cover more code with unit tests.
These solutions have been used in production for several years now and is now used by 11 supermarkets and 25+ cooperatives (plus a few others by other integrators). Everything is in version 12 and we will soon migrate cooperative modules to version 14.
Based on the OCA repository policy, we would like to propose to create these 3 new repositories :
cooperative with all modules in beta-stage while we debrand them.
shift-planning (or shift-management ?) with all modules dealing with shifts in beta stage as well.
vertical-cooperative-supermarket as an incubation repository while we move all the features to oca/purchase-workflow, oca/pos, …
What do you think ? Is there room for these projects at the OCA ?
You can find more information on these Github Issues RFC Moving Obeesdoo to OCA #247 and RFC Moving Easy My Coop to OCA.
All inputs welcome,
Robin Keunen
Robin Keunen
Coop IT Easy
robin@coopiteasy.be
+32 488 86 57 40
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe
--
Denis RousselSoftware EngineerT : +32 2 888 31 49M : +32 472 22 00 57
Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
Atrium Building, Drève Richelle 167 | B-1410 Waterloo | BelgiumZone industrielle 22 | L-8287 Kehlen | Luxembourg
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- Enrico Stano coopdevs.org_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Valentín Vinagre Urteaga
CTO
Sygel Technology S.L
+34 662 68 78 95 valentin.vinagre@sygel.es https://www.sygel.es C/ Àlaba 61, 5ª planta, 08005, Barcelona _______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 06:31 - 9 Feb 2022 -
Re: Lots of our modules do not handle multi-company correctly with Odoo >= 13
On Wed, Feb 9, 2022 at 2:41 PM Holger Brunn <mail@hunki-enterprises.nl> wrote:
could we write the AST version of grep -RE 'user(_id|).company_id[^s]' --include=*.py ?
I recently came across https://semgrep.dev/ which might be handy in such situations.-sbi
by Stéphane Bidoul - 02:51 - 9 Feb 2022 -
Re: Lots of our modules do not handle multi-company correctly with Odoo >= 13
On 09/02/2022 14:37, Holger Brunn wrote: > Thank you for raising this. > >> * gather information about affected modules and versions (so that people >> can quickly check if their instances are affected by this) > > could we write the AST version of > grep -RE 'user(_id|).company_id[^s]' --include=*.py > ? > (which already finds a lot of problematic cases, but also a lot of false > positives we could exclude when knowing the code, like in default lambdas) > > When we have that we could even flag such lines in PRs to have reviewers/ > contributors pay extra attention. > I don't think we want to exclude default lambdas. In my opinion we want env.company_id in these (and this is what Odoo is using). Tests are a bit more of an issue. We should have a pylint check for this, I think, which would require an explicit deactivation to be able to use user.company_id anywhere. -- Alexandre Fayolle Senior Software Engineer Tel : +33 4 58 48 20 30 Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
by Alexandre Fayolle - 02:51 - 9 Feb 2022 -
Re: Plugin/module multiplexer/switcher for multi company
The only problem with the dynamic dispatching according method name is that the code discoverability is more difficult, as you usually look for occurrences of your full method name in other parts of the code, which doesn't happen here. I recently suggest to use a similar approach using inheritance here:and attended by Denis here:Regards.
by Pedro M. Baeza - 02:40 - 9 Feb 2022 -
Re: Lots of our modules do not handle multi-company correctly with Odoo >= 13
Hi Alex.Indeed as `self.env.user.company_id` is used to represent the default company of the user and not the current one.I think effort can be split through PSC's and I'll be pleased to be part of that effort.We can at least create an issue for that in every repo (I don't know if it has been done automatically or not...)Le mer. 9 févr. 2022 à 13:47, Alexandre Fayolle <alexandre.fayolle@camptocamp.com> a écrit :Dear colleagues, It seems we have a widely spread bug on our code base, related to Odoo >= 13.0 and multi-company. Starting on Odoo 13.0 the company switch widget in the UI no longer changes the user's company_id field. It changes the company via the force_company context key, and you get the value of the current company by checking `self.env.company`, and not any longer through `self.env.user.company_id` This is documented in https://www.odoo.com/documentation/13.0/developer/howtos/company.html However, in many places in our code base, I see things such as https://github.com/OCA/account-invoicing/blob/13.0/stock_picking_invoicing/wizards/stock_invoice_onshipping.py#L209 This calls for a massive bug fix campaign (and probably for an official statement from the community to ask customers to upgrade their modules if they are in multi-company). I am not sure what the best course of action is. Things I think we should do: * gather information about affected modules and versions (so that people can quickly check if their instances are affected by this) * prepare fixes and get them applied * publish the fix versions * be super careful about this in the reviews of module migration pull requests (I admit I have been careless on this, and I really feel bad about it) Feedback welcome, -- Alexandre Fayolle Senior Software Engineer Tel : +33 4 58 48 20 30 Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Denis Roussel - 02:25 - 9 Feb 2022 -
Re: Plugin/module multiplexer/switcher for multi company
Yes, dispatcher is sort of what I'm looking for. What you suggest is ingenious! Me coming from languages like Java/Pascal/C/Assembler would never think of approach you suggested :-) I mean dynamically calling method name like that. I wanted to do this by standard inheritance chaining of the same method where only the appropriate one would process the request.Thanks for the eye-opener!Best regardsRadovanSent via BlackBerry Hub+ Inbox for AndroidFrom: gdgellatly@gmail.comSent: February 9, 2022 12:36To: contributors@odoo-community.orgReply-to: contributors@odoo-community.orgSubject: Re: Plugin/module multiplexer/switcher for multi company
Hi,It sounds to me like you are suggesting a standard dispatcher.There is already plenty of this in Odoo. Company specific headers, company specific pricelists, bank specific imports, EDI processing orders,mail.channel specific commands (those are dynamically defined and executed, probably best example for this). Just define a parent module with a standard API dispatcher and a selection field (or Char) where it makes sense.e.g in base module - very pseudo if its python, if it is web based or you just need a URL for standard data maybe it may be different but you get the idea.class Company:field =fields.Selection (base) class Partner:def complete:ensure_one()def complete baseextension moduleadd field to selection say modbdef complete_modb()On Wed, Feb 9, 2022 at 8:51 PM Radovan Skolnik <radovan@skolnik.info> wrote:Hi, the question was meant more towards good design of something that covers the same area functionally (in this case partner autocomplete) but needs to provide more implementations that are chosen based on certain criteria. So in my case I need to have more than one different implementation of the same functionality present in the system and choose the appropriate one - in my case based on current company being active and configuration for that company. That leads me to some kind plugin system and was wondering if there was anything like that existing in Odoo / OCA already. Best regards Radovan On streda 9. februára 2022 6:52:24 CET Bruno Joliveau wrote: > Hi, > I think it's probably different from a context to another. > In our case, the majority of our customers work internationally. Their > search for information is dissociated. The autocomplete is not linked to > the company in which the user is connected but the country on which he > creates the new partner for which he is looking for information. All the > countries we needed to cover for this customer had different connection > modes and incompatible data structures. We have therefore chosen to process > outside Odoo in order to standardize the structure of the results thanks to > different mappings. Odoo connects to the service, the service gets data and > digests the information. Hope it helps ! > > > *Bruno Joliveau* - Président NUMIGI SOLUTIONS INC. > bruno.joliveau@numigi.com [1] (514) 317-7944 > Longueuil, Québec, Canada http://www.numigi.com/ [2] > None [3] None [4] None [5] None [6] > [7] > > Le mar. 8 févr. 2022 à 17:27, Radovan Skolnik < radovan@skolnik.info [8] > a > écrit : Hi! > I have a client that has multi company installation. Each company resides in > a different country. For each country I have created a module that acts the > same as partner_autocomplate but retrieveing data from their local > authorities (state registers). Now I would like to create something as a > plugin system where the client could use all of these modules for different > companies. So I'd need to create some sort of plugins and > multiplexer/switcher that would route requests to appropriate plugin. Is > there anything like that already existing in Odoo? One approach that I see > would be creating that multiplexer/switcher as a main module that would > provide company-specific configuration. Each of the plugin modules would be > a module of its own extending the main module's list of available plugins > implemented as
fields.Selection via selection_add. That selection would be > used as company-specific configuration to know, which plugin should server > the requests. So when requests comes and it is passed through plugins each > would be able to tell whether it's the correct one to serve it. Is there a > better way to do this? Any suggestions are welcome. > Best regards > Radovan Skolnik > > > _______________________________________________ > Mailing-List:https://odoo-community.org/groups/contributors-15 [9] > Post to: mailto: contributors@odoo-community.org [10] > Unsubscribe: https://odoo-community.org/groups?unsubscribe [11] > > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [12] > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe [13] > > > > [1] mailto:bruno.joliveau@numigi.com > [2] http://www.numigi.com/ > [3] https://fr.linkedin.com/company/numigi > [4] https://www.youtube.com/channel/UC2z69q_2XnumQEE9E7BmelQ > [5] https://blogue.numigi.com/ > [6] https://twitter.com/numigi_ca?lang=fr > [7] https://bit.ly/5W-Numigi > [8] mailto:radovan@skolnik.info > [9] https://odoo-community.org/groups/contributors-15 > [10] mailto:contributors@odoo-community.org > [11] https://odoo-community.org/groups?unsubscribe > [12] https://odoo-community.org/groups/contributors-15 > [13] https://odoo-community.org/groups?unsubscribe _______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 02:21 - 9 Feb 2022 -
Lots of our modules do not handle multi-company correctly with Odoo >= 13
Dear colleagues, It seems we have a widely spread bug on our code base, related to Odoo >= 13.0 and multi-company. Starting on Odoo 13.0 the company switch widget in the UI no longer changes the user's company_id field. It changes the company via the force_company context key, and you get the value of the current company by checking `self.env.company`, and not any longer through `self.env.user.company_id` This is documented in https://www.odoo.com/documentation/13.0/developer/howtos/company.html However, in many places in our code base, I see things such as https://github.com/OCA/account-invoicing/blob/13.0/stock_picking_invoicing/wizards/stock_invoice_onshipping.py#L209 This calls for a massive bug fix campaign (and probably for an official statement from the community to ask customers to upgrade their modules if they are in multi-company). I am not sure what the best course of action is. Things I think we should do: * gather information about affected modules and versions (so that people can quickly check if their instances are affected by this) * prepare fixes and get them applied * publish the fix versions * be super careful about this in the reviews of module migration pull requests (I admit I have been careless on this, and I really feel bad about it) Feedback welcome, -- Alexandre Fayolle Senior Software Engineer Tel : +33 4 58 48 20 30 Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
by Alexandre Fayolle - 01:46 - 9 Feb 2022 -
Re: Plugin/module multiplexer/switcher for multi company
Lois, that definitely seems like well-thought-out system for even much more complex cases than mine. For the sake of learning something new I will probably try to use it. Thanx a lot. Best regards Radovan On streda 9. februára 2022 10:37:26 CET Lois Rilo Antelo wrote: > Hi Radovan, > I think that components ( > https://github.com/OCA/connector/tree/14.0/component [1] ) might be the > concept you are looking for. You can have a base module and then different > modules that introduce new components for each country (following your > example). Then on execution, the appropriate component will be used > depending on the working context. You can see different examples on how to > use components in the OCA: different connectors, edi... My 2 cents. > Kind regards, > On Wed, Feb 9, 2022 at 8:51 AM Radovan Skolnik < radovan@skolnik.info [2] > > wrote: Hi, > the question was meant more towards good design of something that covers the > same area functionally (in this case partner autocomplete) but needs to > provide more implementations that are chosen based on certain criteria. So > in my case I need to have more than one different implementation of the > same functionality present in the system and choose the appropriate one - > in my case based on current company being active and configuration for that > company. That leads me to some kind plugin system and was wondering if > there was anything like that existing in Odoo / OCA already. > Best regards > Radovan > > On streda 9. februára 2022 6:52:24 CET Bruno Joliveau wrote: > > Hi, > > I think it's probably different from a context to another. > > In our case, the majority of our customers work internationally. Their > > search for information is dissociated. The autocomplete is not linked to > > the company in which the user is connected but the country on which he > > creates the new partner for which he is looking for information. All the > > countries we needed to cover for this customer had different connection > > modes and incompatible data structures. We have therefore chosen to > > process > > outside Odoo in order to standardize the structure of the results thanks > > to > > different mappings. Odoo connects to the service, the service gets data > > and > > digests the information. Hope it helps ! > > > > > > *Bruno Joliveau* - Président NUMIGI SOLUTIONS INC. > > > > bruno.joliveau@numigi.com [3] [1] (514) 317-7944 > > > > Longueuil, Québec, Canada http://www.numigi.com/ [4] [2] > > None [3] None [4] None [5] None [6] > > [7] > > > > Le mar. 8 févr. 2022 à 17:27, Radovan Skolnik < radovan@skolnik.info [5] > > [8] > a écrit : Hi! > > I have a client that has multi company installation. Each company resides > > in a different country. For each country I have created a module that > > acts the same as partner_autocomplate but retrieveing data from their > > local authorities (state registers). Now I would like to create something > > as a plugin system where the client could use all of these modules for > > different companies. So I'd need to create some sort of plugins and > > multiplexer/switcher that would route requests to appropriate plugin. Is > > there anything like that already existing in Odoo? One approach that I see > > would be creating that multiplexer/switcher as a main module that would > > provide company-specific configuration. Each of the plugin modules would > > be > > a module of its own extending the main module's list of available plugins > > implemented as fields.Selection via selection_add. That selection would be > > used as company-specific configuration to know, which plugin should server > > the requests. So when requests comes and it is passed through plugins each > > would be able to tell whether it's the correct one to serve it. Is there a > > better way to do this? Any suggestions are welcome. > > Best regards > > Radovan Skolnik > > > > > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 [6] [9] > > Post to: mailto: contributors@odoo-community.org [7] [10] > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [8] [11] > > > > > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 [9] [12] > > Post to: mailto: contributors@odoo-community.org [10] > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [11] [13] > > > > > > > > [1] mailto: bruno.joliveau@numigi.com [12] > > [2] http://www.numigi.com/ [13] > > [3] https://fr.linkedin.com/company/numigi [14] > > [4] https://www.youtube.com/channel/UC2z69q_2XnumQEE9E7BmelQ [15] > > [5] https://blogue.numigi.com/ [16] > > [6] https://twitter.com/numigi_ca?lang=fr [17] > > [7] https://bit.ly/5W-Numigi [18] > > [8] mailto: radovan@skolnik.info [19] > > [9] https://odoo-community.org/groups/contributors-15 [20] > > [10] mailto: contributors@odoo-community.org [21] > > [11] https://odoo-community.org/groups?unsubscribe [22] > > [12] https://odoo-community.org/groups/contributors-15 [23] > > [13] https://odoo-community.org/groups?unsubscribe [24] > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [25] > Post to: mailto: contributors@odoo-community.org [26] > Unsubscribe: https://odoo-community.org/groups?unsubscribe [27] > > -- > *Lois Rilo Antelo* Odoo consultant at ForgeFlow S.L. > lois.rilo@forgeflow.com [28] | https://www.forgeflow.com [29] Twitter: > /LoisRForgeFlow [30] > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [31] > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe [32] > > > > [1] https://github.com/OCA/connector/tree/14.0/component > [2] mailto:radovan@skolnik.info > [3] mailto:bruno.joliveau@numigi.com > [4] http://www.numigi.com/ > [5] mailto:radovan@skolnik.info > [6] https://odoo-community.org/groups/contributors-15 > [7] mailto:contributors@odoo-community.org > [8] https://odoo-community.org/groups?unsubscribe > [9] https://odoo-community.org/groups/contributors-15 > [10] mailto:contributors@odoo-community.org > [11] https://odoo-community.org/groups?unsubscribe > [12] mailto:bruno.joliveau@numigi.com > [13] http://www.numigi.com/ > [14] https://fr.linkedin.com/company/numigi > [15] https://www.youtube.com/channel/UC2z69q_2XnumQEE9E7BmelQ > [16] https://blogue.numigi.com/ > [17] https://twitter.com/numigi_ca?lang=fr > [18] https://bit.ly/5W-Numigi > [19] mailto:radovan@skolnik.info > [20] https://odoo-community.org/groups/contributors-15 > [21] mailto:contributors@odoo-community.org > [22] https://odoo-community.org/groups?unsubscribe > [23] https://odoo-community.org/groups/contributors-15 > [24] https://odoo-community.org/groups?unsubscribe > [25] https://odoo-community.org/groups/contributors-15 > [26] mailto:contributors@odoo-community.org > [27] https://odoo-community.org/groups?unsubscribe > [28] mailto:lois.rilo@eficent.com > [29] https://www.forgeflow.com/ > [30] https://twitter.com/LoisRForgeFlow > [31] https://odoo-community.org/groups/contributors-15 > [32] https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 11:51 - 9 Feb 2022
