Archives
Contributors
-
Re: HR Attendance - Performance Issue in "Theoretical vs Attended Time Analysis"
Hi,
Although I do not program Odoo modules, I do program.
I would suggest to go for option 3, and store balances every year or month (depending on performance impact), with an option to 'recalculate' when needed.
In the mean time, you could also have a look at the queries the current module fires and see if indexing can alliviate some pain.
My 0.02 of course.
Regards,
Jeroen Baten
Op 03-04-2025 om 11:22 schreef Emanuel Cino:
Hello Contributors,
We are using the module hr_attendance_report_theoretical_time for checking our employees working time balance (extra or minus hours), but are facing performance issues (on Odoo 14 at the moment).
We’ve noticed that the report in the module can be slow, especially when handling a large number of attendances. In our setup, it computes all attendances since we started using the module, which significantly impacts performance.While we sometimes need to analyze attendance over a limited period (e.g., the current year or semester), most of the time we need to retrieve the complete balance of an employee since their start date to assess total (=current) extra or missing hours.
Questions for the Community-
Have others experienced similar performance issues with this report?
-
How do you optimize performance? Have you implemented any workarounds?
-
Would there be interest in adding a mechanism to store computed balances at a pivot date to reduce the number of records processed?
-
Do you use another method for computing the total extra hours of any employee? What is your approach?
Any insights or suggestions would be greatly appreciated!
Thanks,Emanuel_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- Jeroen Baten | EMAIL : JBATEN@I2RS.NL ____ _ __ | web : www.i2rs.nl | )|_)(_ | tel : +31 (0)648519096 _|_/_| \__) | Frisolaan 16, 4101 JK, Culemborg, the Netherlands
by Jeroen Baten - 11:31 - 3 Apr 2025 -
-
Re: The future of oca/bank-payment
>>> The Spanish Odoo Days will be held in June soon: this could be a good opportunity.
Dates and Place ?
From: Virginie Dewulf <virginie@odoo-community.org>
Sent: Wednesday, April 2, 2025 9:36 PM
To: Contributors <contributors@odoo-community.org>
Subject: Re: The future of oca/bank-paymentHello contributors,
Thanks for sharing your opinions on this important topic.
Proposed next steps:A continuous chain of emails won't help to find a common solution. With the "Community Health" WG, I propose to organize an online meeting with the concerned parties to find a way towards an agreement. Luc's suggestion of having a few days together is a good one, if there is no agreement online. The Spanish Odoo Days will be held in June soon: this could be a good opportunity.
The result of the meeting will be shared in this thread to keep a public track of the conversation.
A reminder of our intention as a communityWe are all on the same team, trying to find an open source way in the Odoo ecosystem that changes every year. I sometimes picture Odoo S.A. as a big and super fast boat on the sea of ERPs. The OCA is a gathering of hundreds of small little sailboat (=our PSC teams responsible for managing several repos), trying to follow the wind and stay together as much as possible. But it is sometimes really hard and chaotic (like with the account apocalypse in v13).
The underlying problematic of this discussionHere we have an important question: who is the captain of this specific sailboat? As each part of the sailboat has been built by a different contributor and sometimes taken care for several years by another, who has the legitimacy to decide of the future? Or isn't something we can decide by principle and we might need to have a process to decide for each situation?
This is the question that we will need to answer as a community, because those discussions happened in the past and will continue to arise. And to not loose our time and energy on fighting between each others, we will need proper governance guidelines on this.
This will be a task for the Governance Working Group in the next months, with a proposition to be presented to the Delegates for the 2025 Annual General Assembly in autumn in a newer version of the PSC-guide (which at the moment mention nothing about process to find an agreement).
Enjoy your week!
Le mer. 2 avr. 2025 à 11:52, Enric Tobella Alomar <notifications@odoo-community.org> a écrit :
I know that Alexis did a massive job in the past, but if we check the contributors information provided by github we get the following that the main contributor is Pedro.
https://github.com/OCA/bank-payment/graphs/contributors
Also, it is similar if we check the collaboration data extracted from the PRs. In the last 5 years the Top 15 is the following:
User
Created PRs
Merged PRs
Comments
Reviews
OCI
pedrobaeza
49
49
776
539
623
victoralmau
72
68
38
64
147
HaraldPanten
-
-
93
80
90
alexis-via
41
22
84
48
86
carlosdauden
9
8
12
60
74
ValentinVinagre
5
5
40
49
63
sergio-teruel
5
4
11
35
45
luc-demeyer
26
14
38
15
40
joao-p-marques
12
12
19
18
38
etobella
16
15
14
12
35
ramiadavid
11
10
9
19
35
Tisho99
15
15
24
10
34
MiquelRForgeFlow
12
11
16
15
33
rousseldenis
7
4
28
19
31
StefanRijnhart
5
4
20
20
31
It is obvious that he is involved a lot in this repo, but there is a group of main authors. If we check data, Alexis is not "the main author", he is one of the main authors.
Kind regards,
El mié, 2 abr 2025 a las 11:17, Stéphane Bidoul (<notifications@odoo-community.org>) escribió:
On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar <notifications@odoo-community.org> wrote:I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.
I reviewed the account_payment_partner PR (https://github.com/OCA/bank-payment/pull/1439) and commented to explain again the drawback of keeping payment modes.
That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.
If we want to continue using payment modes, we need a better solution to that problem.My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer).I still hope we can converge. But if we can't, the way to fork is certainly debatable.
In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork.In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.
Best regards,
-Stéphane_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Enric Tobella AlomarCEO & Founder
_______________________________________________
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 Luc De Meyer. - 08:41 - 3 Apr 2025 -
Re: The future of oca/bank-payment
Hello contributors,Thanks for sharing your opinions on this important topic.Proposed next steps:A continuous chain of emails won't help to find a common solution. With the "Community Health" WG, I propose to organize an online meeting with the concerned parties to find a way towards an agreement. Luc's suggestion of having a few days together is a good one, if there is no agreement online. The Spanish Odoo Days will be held in June soon: this could be a good opportunity.The result of the meeting will be shared in this thread to keep a public track of the conversation.A reminder of our intention as a communityWe are all on the same team, trying to find an open source way in the Odoo ecosystem that changes every year. I sometimes picture Odoo S.A. as a big and super fast boat on the sea of ERPs. The OCA is a gathering of hundreds of small little sailboat (=our PSC teams responsible for managing several repos), trying to follow the wind and stay together as much as possible. But it is sometimes really hard and chaotic (like with the account apocalypse in v13).The underlying problematic of this discussionHere we have an important question: who is the captain of this specific sailboat? As each part of the sailboat has been built by a different contributor and sometimes taken care for several years by another, who has the legitimacy to decide of the future? Or isn't something we can decide by principle and we might need to have a process to decide for each situation?This is the question that we will need to answer as a community, because those discussions happened in the past and will continue to arise. And to not loose our time and energy on fighting between each others, we will need proper governance guidelines on this.This will be a task for the Governance Working Group in the next months, with a proposition to be presented to the Delegates for the 2025 Annual General Assembly in autumn in a newer version of the PSC-guide (which at the moment mention nothing about process to find an agreement).Enjoy your week!Le mer. 2 avr. 2025 à 11:52, Enric Tobella Alomar <notifications@odoo-community.org> a écrit :I know that Alexis did a massive job in the past, but if we check the contributors information provided by github we get the following that the main contributor is Pedro.
https://github.com/OCA/bank-payment/graphs/contributorsAlso, it is similar if we check the collaboration data extracted from the PRs. In the last 5 years the Top 15 is the following:User
Created PRs
Merged PRs
Comments
Reviews
OCI
pedrobaeza
49
49
776
539
623
victoralmau
72
68
38
64
147
HaraldPanten
-
-
93
80
90
alexis-via
41
22
84
48
86
carlosdauden
9
8
12
60
74
ValentinVinagre
5
5
40
49
63
sergio-teruel
5
4
11
35
45
luc-demeyer
26
14
38
15
40
joao-p-marques
12
12
19
18
38
etobella
16
15
14
12
35
ramiadavid
11
10
9
19
35
Tisho99
15
15
24
10
34
MiquelRForgeFlow
12
11
16
15
33
rousseldenis
7
4
28
19
31
StefanRijnhart
5
4
20
20
31
It is obvious that he is involved a lot in this repo, but there is a group of main authors. If we check data, Alexis is not "the main author", he is one of the main authors.Kind regards,El mié, 2 abr 2025 a las 11:17, Stéphane Bidoul (<notifications@odoo-community.org>) escribió:On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar <notifications@odoo-community.org> wrote:I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.I reviewed the account_payment_partner PR (https://github.com/OCA/bank-payment/pull/1439) and commented to explain again the drawback of keeping payment modes.That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.
If we want to continue using payment modes, we need a better solution to that problem.My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer).I still hope we can converge. But if we can't, the way to fork is certainly debatable.In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork.In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.Best regards,-Stéphane_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Enric Tobella AlomarCEO & Founder_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Virginie Dewulf - 09:35 - 2 Apr 2025 -
Re: report_py3o
Actually, the migration PR for report_py3o is ready to review. I have linked it in https://github.com/OCA/reporting-engine/issues/934Best regards,-Stéphane--Stéphane Bidoul
On Wed, Apr 2, 2025 at 7:17 PM Virginie Dewulf <virginie@odoo-community.org> wrote:Hello,
Generally spoken OCA or basically its contributors will work on migrating modules if there is a direct need to (by one of their customers) AND somebody (normally the customer) is willing to fund their work. The is no "OCA Teams being paid to provide the OCA Apps".
It's generally perceived a good habit, to contribute not only with code but also with funds and ideas, especially if one had a substantial benefit in the first place (by using what was already there in older versions). So what you may do as an well estabilshed Odoo Partner taking advantage of these modules, is contact the PSC for each of the modules repositories and ask the primary contributors of the module if and how you may support them to prioritize the migration of the module.In your case, you can followup the advancement of migration to v18 in this issue in this repo: https://github.com/OCA/reporting-engine/issues/934I see the py3o module is not in this list of work to do... This would be a good question to ask to the PSC's.To find the PSC's, you can check this website: https://oca.github.io/repo-maintainer-conf/In your case, the PSC team can be found here: https://oca.github.io/repo-maintainer-conf/reporting.html
Usually redirecting some of the funds of your customer to those contributors will naturally speed up the process enormously for the benefit of all parties.
As you are using OCA modules, you are also invited to contribute back to the association (if it is not already the case!) who supports the collaborative work and provides rules and a context for the OCA modules to being created and maintained, by buying a yearly membership for your employees (60€/year) or by becoming an OCA sponsor.
https://odoo-community.org/get-involved/become-a-member
https://odoo-community.org/get-involved/become-a-sponsor
All the best,Le ven. 28 mars 2025 à 21:02, Martin Bando <notifications@odoo-community.org> a écrit :Hello everyone,
we are currently using report_py3o under odoo 16. Is it possible to use report_py3o under odoo 18 or will it be possible in the future?
Please do not hesitate to contact us if you have any questions.
With kind regards
Martin Bando
Computer Science Expert - Software Development | OPAL Solutions GmbH
martin.bando@opal-solutions.de | https://opal-solutions.de
Niederlassung Bochum | T +49 (0)234 541 444 06
Technische Probleme?:
Schreiben Sie direkt eine Email an helpdesk@opal-solutions.de.
Hauptsitz Rheinland | Karl-Heinz-Beckurts-Straße 13 | 52428 Jülich
Niederlassung Ruhrgebiet/Sauerland | Heinrichstraße 67 | 44805 Bochum
Niederlassung Münster/Osnabrück | Gewerbepark 18 | 49143 Bissendorf
T +49 (0)2461 690 280 | F +49 (0)2461 690 284
Amtsgericht Düren | HRB 5889 | Geschäftsführung: Michael von Steht
OPAL Solutions GmbH ist ein Unternehmen der OPAL Associates Holding AGAGB | Impressum | Informationen zum Datenschutz
Follow us on
WICHTIGE MITTEILUNG
Diese E-Mail und deren Anlagen enthalten vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser E-Mail und deren Anlagen sind nicht gestattet. OPAL haftet nicht für Schäden, die durch den unerlaubten Gebrauch dieser E-Mail und deren Anlagen entstehen.
IMPORTANT MESSAGE
This e-mail and their attachments may contain confidential and / or privileged information. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this e-mail. Unauthorized copying and unauthorized distribution of this e-mail and their attachments are not allowed. OPAL is not liable for damages caused by unauthorized use of this e-mail and attachments._______________________________________________
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 Stéphane Bidoul - 07:46 - 2 Apr 2025 -
Re: report_py3o
Hello,
Generally spoken OCA or basically its contributors will work on migrating modules if there is a direct need to (by one of their customers) AND somebody (normally the customer) is willing to fund their work. The is no "OCA Teams being paid to provide the OCA Apps".
It's generally perceived a good habit, to contribute not only with code but also with funds and ideas, especially if one had a substantial benefit in the first place (by using what was already there in older versions). So what you may do as an well estabilshed Odoo Partner taking advantage of these modules, is contact the PSC for each of the modules repositories and ask the primary contributors of the module if and how you may support them to prioritize the migration of the module.In your case, you can followup the advancement of migration to v18 in this issue in this repo: https://github.com/OCA/reporting-engine/issues/934I see the py3o module is not in this list of work to do... This would be a good question to ask to the PSC's.To find the PSC's, you can check this website: https://oca.github.io/repo-maintainer-conf/In your case, the PSC team can be found here: https://oca.github.io/repo-maintainer-conf/reporting.html
Usually redirecting some of the funds of your customer to those contributors will naturally speed up the process enormously for the benefit of all parties.
As you are using OCA modules, you are also invited to contribute back to the association (if it is not already the case!) who supports the collaborative work and provides rules and a context for the OCA modules to being created and maintained, by buying a yearly membership for your employees (60€/year) or by becoming an OCA sponsor.
https://odoo-community.org/get-involved/become-a-member
https://odoo-community.org/get-involved/become-a-sponsor
All the best,Le ven. 28 mars 2025 à 21:02, Martin Bando <notifications@odoo-community.org> a écrit :Hello everyone,
we are currently using report_py3o under odoo 16. Is it possible to use report_py3o under odoo 18 or will it be possible in the future?
Please do not hesitate to contact us if you have any questions.
With kind regards
Martin Bando
Computer Science Expert - Software Development | OPAL Solutions GmbH
martin.bando@opal-solutions.de | https://opal-solutions.de
Niederlassung Bochum | T +49 (0)234 541 444 06
Technische Probleme?:
Schreiben Sie direkt eine Email an helpdesk@opal-solutions.de.
Hauptsitz Rheinland | Karl-Heinz-Beckurts-Straße 13 | 52428 Jülich
Niederlassung Ruhrgebiet/Sauerland | Heinrichstraße 67 | 44805 Bochum
Niederlassung Münster/Osnabrück | Gewerbepark 18 | 49143 Bissendorf
T +49 (0)2461 690 280 | F +49 (0)2461 690 284
Amtsgericht Düren | HRB 5889 | Geschäftsführung: Michael von Steht
OPAL Solutions GmbH ist ein Unternehmen der OPAL Associates Holding AGAGB | Impressum | Informationen zum Datenschutz
Follow us on
WICHTIGE MITTEILUNG
Diese E-Mail und deren Anlagen enthalten vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser E-Mail und deren Anlagen sind nicht gestattet. OPAL haftet nicht für Schäden, die durch den unerlaubten Gebrauch dieser E-Mail und deren Anlagen entstehen.
IMPORTANT MESSAGE
This e-mail and their attachments may contain confidential and / or privileged information. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this e-mail. Unauthorized copying and unauthorized distribution of this e-mail and their attachments are not allowed. OPAL is not liable for damages caused by unauthorized use of this e-mail and attachments._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Virginie Dewulf - 07:16 - 2 Apr 2025 -
Re: KU Leuven - Link to Interview form Thesis research Dylan Kaekelbergh
Hello Contributors,Dylan who is studying governance of open source projects is still looking for a few participants for his research.All info are below. Many thanks from him and myself.I think this can lead to a better knowledge about our way of working together, which is not always easy as we can see from several messages on this mailing list for the past days.Enjoy the day!Le lun. 24 févr. 2025 à 09:42, Virginie Dewulf <virginie@odoo-community.org> a écrit :
Hello OCA contributors,
I forward a message from a student from Belgium, currently studying the governance of open source projects. The OCA is a Case Study for his master thesis.
Would you help him? His findings will certainly help us understand how we currently work together and give us ideas to improve this together!
Schedule your meeting with him here:https://forms.office.com/e/esVRbvAPK7
Many thanks!
Dear OSS Community,
To introduce myself, I’m Dylan Kaekelbergh, master student at KU Leuven and fascinated by OSS Communities.
Software quality and technology thrives due to the effort and contributions made by Open-Source Software communities. The way that a community of volunteers comes together and work towards a shared vision poses an interesting field of study. Understanding this more deeply can provide insights to help more OSS projects graduate and deduct significant best practices.
As part of a Master Thesis, I’m conducting a qualitative empirical research on Governance configurations in OSS Communities to deeper explore this topic.
The study has the aim to explore the relationship between motivations of contributors and the governance configurations that the communities upholds. Additionally, the study explores if multiple governance configurations can exist within a community and how these contribute to the success of a community.
At this moment, I’m looking for OSS Community members and contributors of the Odoo Community Association to participate in a one hour (max. 1,5h) interview. The interviews will be conducted over a period of 4 weeks.
Each interview response will be treated confidentially and will be processed in the end paper anonymously.
Each interview will be conducted via Microsoft Teams. (If preferred F2F interviews in KU Leuven Brussels can also be organized)
Thank you in advance for assisting in this research.
Best Regards, DylanDylan Kaekelbergh
0491 62 34 82
Student KU LeuvenShort URL: https://forms.office.com/e/esVRbvAPK7
by Virginie Dewulf - 04:21 - 2 Apr 2025 -
AW: New module for uuid fields
Yes, for sure in most cases you will set the field to be readonly. Still using a native uuid type over a char type can have various benefits. I am certainly not an expert but you can refer to this stackoverflow post, why you would want to use a uuid field over a char field even if only for display reasons: https://stackoverflow.com/questions/32189129/performance-difference-between-uuid-char-and-varchar-in-postgresql-table
Von: Vincent Hatakeyama [mailto:notifications@odoo-community.org]
Gesendet: Mittwoch, 2. April 2025 11:58
An: Contributors
Betreff: Re: New module for uuid fieldsHi,
I’ve had the need to use an uuid column in the past. The column was not meant to be filled by users. The table was built manually and a Char field was used to display the content.
The code can be viewed at https://orus.io/xcg/odoo-modules/xbus_common/-/blob/branch/18.0/models/xbus_message.py?ref_type=heads#L94
I believe the server-tools repository is the place to put a module adding UUID fields.
Regards,
--
Vincent Hatakeyama
Directeur du pôle développement " Orbeet
+33 1 83 62 72 88
27, boulevard Saint-Martin
75003 Paris
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by mkoeck - 12:25 - 2 Apr 2025 -
Re: New module for uuid fields
Hi,I’ve had the need to use an uuid column in the past. The column was not meant to be filled by users. The table was built manually and a Char field was used to display the content.The code can be viewed at https://orus.io/xcg/odoo-modules/xbus_common/-/blob/branch/18.0/models/xbus_message.py?ref_type=heads#L94I believe the server-tools repository is the place to put a module adding UUID fields.--Regards,Vincent Hatakeyama Directeur du pôle développement " Orbeet
+33 1 83 62 72 88
vincent.hatakeyama@orbeet.io
27, boulevard Saint-Martin
75003 Paris
https://orbeet.io
by "Vincent Hatakeyama" <vincent.hatakeyama@orbeet.io> - 11:56 - 2 Apr 2025 -
Re: The future of oca/bank-payment
I know that Alexis did a massive job in the past, but if we check the contributors information provided by github we get the following that the main contributor is Pedro.
https://github.com/OCA/bank-payment/graphs/contributorsAlso, it is similar if we check the collaboration data extracted from the PRs. In the last 5 years the Top 15 is the following:User
Created PRs
Merged PRs
Comments
Reviews
OCI
pedrobaeza
49
49
776
539
623
victoralmau
72
68
38
64
147
HaraldPanten
-
-
93
80
90
alexis-via
41
22
84
48
86
carlosdauden
9
8
12
60
74
ValentinVinagre
5
5
40
49
63
sergio-teruel
5
4
11
35
45
luc-demeyer
26
14
38
15
40
joao-p-marques
12
12
19
18
38
etobella
16
15
14
12
35
ramiadavid
11
10
9
19
35
Tisho99
15
15
24
10
34
MiquelRForgeFlow
12
11
16
15
33
rousseldenis
7
4
28
19
31
StefanRijnhart
5
4
20
20
31
It is obvious that he is involved a lot in this repo, but there is a group of main authors. If we check data, Alexis is not "the main author", he is one of the main authors.Kind regards,El mié, 2 abr 2025 a las 11:17, Stéphane Bidoul (<notifications@odoo-community.org>) escribió:On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar <notifications@odoo-community.org> wrote:I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.I reviewed the account_payment_partner PR (https://github.com/OCA/bank-payment/pull/1439) and commented to explain again the drawback of keeping payment modes.That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.
If we want to continue using payment modes, we need a better solution to that problem.My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer).I still hope we can converge. But if we can't, the way to fork is certainly debatable.In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork.In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.Best regards,-Stéphane_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Enric Tobella AlomarCEO & Founder
by Enric Tobella Alomar - 11:51 - 2 Apr 2025 -
Re: The future of oca/bank-payment
> I reviewed the account_payment_partner PR (https://github.com/OCA/bank-payment/pull/1439) and commented to explain again the drawback of keeping payment modes.> That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.
If we want to continue using payment modes, we need a better solution to that problem.I hope all the problems we have in Odoo are of this difficulty ;)2 easy solutions:- With the existing group, hide the fields being added with this module with groups="!group" clause.- Add another security group, so you can select both, one, another or none fields to be shown.> In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork.> In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.I think he lost his rights not attending the project for years, being pinged continuously without any answer. Some non complete list of pings without answer:https://github.com/OCA/bank-payment/pull/979#issuecomment-1304825620 (my large previous refactoring to use native account.payment object)He has also refused several times to do forward-ports of his patches, or directly to not maintain the whole repository, because "he doesn't work on odd versions".Regards.
by Pedro M. Baeza - 11:45 - 2 Apr 2025 -
Re: The future of oca/bank-payment
On Wed, Apr 2, 2025 at 6:52 AM Enric Tobella Alomar <notifications@odoo-community.org> wrote:I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.I reviewed the account_payment_partner PR (https://github.com/OCA/bank-payment/pull/1439) and commented to explain again the drawback of keeping payment modes.That PR hides the standard fields behind a group, but if for any reason someone needs to use the standard fields, they end up with a very confusing user interface with duplicate Payment Method/Mode fields with almost identical names and meanings on partners and invoices.
If we want to continue using payment modes, we need a better solution to that problem.My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer).I still hope we can converge. But if we can't, the way to fork is certainly debatable.In "normal" open source projects, the main authors ensure the steering, and if some users are not happy with the direction taken they can fork.In that view, asking the main author (arguably Alexis in this case) to fork himself is a bit awkward.Best regards,-Stéphane
by Stéphane Bidoul - 11:16 - 2 Apr 2025 -
A bit of marketing: LinkedIn Banners for OCA contributors/members/delegates...
Hello everyone,We notice that many Odoo people are active on LinkedIn and are interested in the OCA content.With the Marketing Working Group, we have decided to create banners for our community members to show on their LinkedIn profile that they are part of the OCA.We designed 2 types of banners:- generic ones, that you can use as is on your profile- customizable ones, on top of which you can add your name, contact details, company logo... anything you want to make it look more like you but with the background and badge related to your OCA activity.For each of those types, they are mention of various labels: contributor, member, delegate and board member (only to use if you are one of them, we trust you of course to choose the one that is best for you).The result is available in PNG format on the marketing resources page:I customized one of those for my personal profile to have a concrete example:(screenshot in attachment).I hope you will find those banners nice and useful and that you will make use of them, for the ones of you having LinkedIn accounts!Special thanks to Thibault Rey and Dora Jurcevic (Akretion) active in the Marketing WG for this little project!
by Virginie Dewulf - 11:01 - 2 Apr 2025 -
Re: The future of oca/bank-payment
Hi everyone,I reviewed the video. And it doesn't change my position. I think that it is an overengineer work to do something that is more natural with the current system. I don't see the real benefits of the change, as the current system does it properly with a more direct and simple approach. I think we should end this discussion soon in order to get a solution for 18 soon.My proposal would be the following: Merge the modules migrated by Tecnativa. Create a separate system for your proposal (we could create a separate repo if you prefer). It might happen in the future that both systems are merged (similar to storage_backend and fs_storage... at the end, they merged, but they started splitted), but right now it doesn't seem soKind regards,El mar, 1 abr 2025 a las 18:37, Alexis de Lattre (<notifications@odoo-community.org>) escribió:Dear community,--Le mer. 26 mars 2025 à 18:09, Alexis de Lattre <alexis.delattre@akretion.com> a écrit :Dear Enric,Le mer. 26 mars 2025 à 12:47, Enric Tobella Alomar <notifications@odoo-community.org> a écrit :For example with the current system we can decide the bank to pay at the end in a simple way, no complication on that side. With this change, everything becomes more complicated, removing part of the functionality that we have and it was much better that the current Odoo behavior. Also, it implies that users will see one TRansference payment method for each journal, and that is a nonsense.Did you test my v18 PR that adds the module account_payment_base_oca https://github.com/OCA/bank-payment/pull/1401 ?My goal was to use the native object account.payment.method.line (used in v18 as "payment mode" on partners and invoices) while keeping the feature "decide the bank to pay at the end in a simple way". And I managed to implement it without breaking the native behavior. It was important to keep this feature !I prepared a short screencast of my PR 1401 that illustrate the fact that my implementation keeps the feature "decide the bank to pay at the end in a simple way", like in OCA/bank-payment v9 to v17 :So we can adopt the native object "account.payment.method.line" and keep the great features of OCA/bank-payment.I even added a small improvement : when you configure "Link to Bank Account" to "Variable", you can select a Default Bank Journal if you want (it's optional).Alexis de Lattre
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Enric Tobella AlomarCEO & Founder
by Enric Tobella Alomar - 06:51 - 2 Apr 2025 -
Re: The future of oca/bank-payment
Alexis, even if getting feature parity, that doesn't dismiss that the migration scripts must be done and we must re-educate all the users to the change, while it's not needed.And not only that, you are deforming the standard even more than the previous solution, and that without counting the still rough edges.I'm still standing on the current set of modules, and we already have them migrated.Regards.
by Pedro M. Baeza - 06:46 - 1 Apr 2025 -
Re: The future of oca/bank-payment
Dear community,--Le mer. 26 mars 2025 à 18:09, Alexis de Lattre <alexis.delattre@akretion.com> a écrit :Dear Enric,Le mer. 26 mars 2025 à 12:47, Enric Tobella Alomar <notifications@odoo-community.org> a écrit :For example with the current system we can decide the bank to pay at the end in a simple way, no complication on that side. With this change, everything becomes more complicated, removing part of the functionality that we have and it was much better that the current Odoo behavior. Also, it implies that users will see one TRansference payment method for each journal, and that is a nonsense.Did you test my v18 PR that adds the module account_payment_base_oca https://github.com/OCA/bank-payment/pull/1401 ?My goal was to use the native object account.payment.method.line (used in v18 as "payment mode" on partners and invoices) while keeping the feature "decide the bank to pay at the end in a simple way". And I managed to implement it without breaking the native behavior. It was important to keep this feature !I prepared a short screencast of my PR 1401 that illustrate the fact that my implementation keeps the feature "decide the bank to pay at the end in a simple way", like in OCA/bank-payment v9 to v17 :So we can adopt the native object "account.payment.method.line" and keep the great features of OCA/bank-payment.I even added a small improvement : when you configure "Link to Bank Account" to "Variable", you can select a Default Bank Journal if you want (it's optional).Alexis de Lattre
by Alexis de Lattre - 06:36 - 1 Apr 2025 -
Container Import Workflow
Hi everyone,
We’re working with a client that requires improvements to the container import process in Odoo, and we’re preparing to start development soon. As many of you may know, container imports typically involve a specific workflow, including:
Import documentation
Import type (air, sea, consolidated, etc.)
Landed costs allocation
Container tracking and scheduling
Customs and clearance milestones
Follow-ups on estimated arrival/departure dates
Our current approach is to extend the purchase order model to serve as the foundation of this workflow, allowing us to maintain a familiar structure while introducing the additional logic and tracking needed for container-level visibility and process automation.
Before we begin, we’d like to ask the community:
Is anyone else currently working on something similar or interested in collaborating on this?
Are there existing OCA modules or partial solutions we should consider extending?
We see potential value in making this a broader OCA-compliant project, especially as container tracking and landed cost accuracy are pain points for many companies working with international suppliers.
Happy to share a more detailed spec or jump on a call to discuss use cases. Looking forward to hearing your thoughts and ideas.
Best regards,--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy
by Jorge Elena Poblet - 04:21 - 1 Apr 2025 -
AW: New module for uuid fields
Hi Michael,this sounds interesting to me! Unfortunately, I can't access the repo.Can you share it?
Best,Friedrich
Email: friedrich.sauer@servicum.comPhone: 01721324603
Von: Elektro-Shop Köck GmbH - Michael Köck
Gesendet: Dienstag, 01. April 2025 13:17
Bis: Contributors
Betreff: New module for uuid fields
Hello everyone,
I am currently working on a project where I wanted to use the native postgres type uuid, instead of storing the uuids in plain char fields. Since such a field does not seem to be available in Odoo yet, I threw together a very simple module: https://github.com/mkoeck/base-uuid-field/
Since I saw that there are some existing OCA modules using uuid’s (but storing them in plain char fields), I thought this module might also be interesting to others. I would be happy to integrate this into an existing OCA repo, if someone guides me what the best direction for this would be.
Do note, that I am quite the novice with JS / owl, so any feedback, but especially on that is appreciated J
Best regards,
Michael
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Friedrich Sauer - 04:11 - 1 Apr 2025
