Archives
Contributors
-
Re: How do you solve invoicing period?
Hello,
I don't know if this is what you want, but I'm using date_range module, plus another one that creates months, quarters, semesters and years via ir.cron.
Then, I added some date_range_id fields on account.move.line model.
Regards,
João Jerónimo
Às 16:32 de 16/08/2022, Rafael Blasco escreveu:
Hello Contributors!
I write because I don’t see a common straight solution (and user friendly) for this general use case.
Usually, I have been using the OCA module “sale_order_type” when a client have the need of defining invoicing periods like:
- Monthly
- B-weekly
- Weekly
- Daily
With sale_order_type +plus+ sale_order_invoicing_grouping_criteria you can group by. This module allow multiple criterias.
In the other hand there is the OCA module “account_invoice_base_invoicing_mode”, this looks like more specific but it has a huge dependency (I don’t know why): depends: account, queue_job, sale
With account_invoice_base_invoicing_mode +plus+ account_invoice_mode_monthly and other modules becomes the logic, but the customer cannot create their invoicing modes themselves, and need from us a new module each time.
The usability (UX) in my mind looks like clients (users) have a field like “invoicing period” (like invoicing mode) where they can create monthly, weekly, etc. (like payment terms) and after that they can set it in the partners form (customers or supplier). And after that improve with more modules automatism.
What do you think?
I write here before opening an issue in GitHub (maybe sale-workflow, maybe account-invoicing).
Thank you in advance
Best regards
Rafael
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by j_j_b_o_devel - 05:41 - 16 Aug 2022 -
How do you solve invoicing period?
Hello Contributors!
I write because I don’t see a common straight solution (and user friendly) for this general use case.
Usually, I have been using the OCA module “sale_order_type” when a client have the need of defining invoicing periods like:
- Monthly
- B-weekly
- Weekly
- Daily
With sale_order_type +plus+ sale_order_invoicing_grouping_criteria you can group by. This module allow multiple criterias.
In the other hand there is the OCA module “account_invoice_base_invoicing_mode”, this looks like more specific but it has a huge dependency (I don’t know why): depends: account, queue_job, sale
With account_invoice_base_invoicing_mode +plus+ account_invoice_mode_monthly and other modules becomes the logic, but the customer cannot create their invoicing modes themselves, and need from us a new module each time.
The usability (UX) in my mind looks like clients (users) have a field like “invoicing period” (like invoicing mode) where they can create monthly, weekly, etc. (like payment terms) and after that they can set it in the partners form (customers or supplier). And after that improve with more modules automatism.
What do you think?
I write here before opening an issue in GitHub (maybe sale-workflow, maybe account-invoicing).
Thank you in advance
Best regards
Rafael
by Rafael Blasco (Moduon) - 05:31 - 16 Aug 2022 -
Re: Filestore in the cloud
Hi Jordi,
Did you work on something already ? if open sourced will be great.
If it's still in progress, I'm interested to contribute :pray:
Thanks,Le mar. 4 févr. 2020 à 16:02, Jordi Riera <jordi.riera@numigi.com> a écrit :Awesome!As always the community is awesome. Thanks to your help we will work this week on the transition to our filestores in the blob ;)Cheers!JordiLe sam. 1 févr. 2020 03 h 52, Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com> a écrit :Thanks :)Le ven. 31 janv. 2020 à 19:47, Russell Briggs <russ@paraflyer.net> a écrit :Camptocamp cloud platform modules look awesome - thanks!On Sat, 1 Feb 2020, 4:02 AM Stéphane Bidoul, <stephane.bidoul@acsone.eu> wrote:Hi Jordi,Don't forget the session storage if you go that route.A good starting point is here: https://github.com/camptocamp/odoo-cloud-platform-sbiOn Fri, Jan 31, 2020 at 3:37 PM Jordi Riera <jordi.riera@numigi.com> wrote:Hello everyone,I was under my shower, and, as I often had a strange idea.What about putting the filestore in a storage in the cloud ? Something like D3 Azure Storage etc.The aim is to be able to scale up like crazy without to care about the location of the filestore (like volumes mounted on a single machine)Do you know any module, article, or initiative that worked on that ?Does it seem realistic to you ?Let's chat !Jordi
--
Jordi Riera - VP TechniqueNUMIGI SOLUTIONS INC.(514) 317-7944Longueuil, Québec, Canada
_______________________________________________
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
_______________________________________________
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-----[ Youness @ MAAFI ]
by Youness Maafi - 02:40 - 16 Aug 2022 -
Call for Speakers - OCA Days 2022 - Deadline 31st August
Hello OCA Contributors.
We are so excited to see so many of you heading to the OCA Days in October. We are almost at capacity!
I wanted to make sure you were aware that our "Call for Speakers" deadline is 31st of August.
We have some great proposals that have been sent through already and we would love to have more! We want to hear about what you have been up to, have you got a new module to share, an update, a tutorial, a workshop, a great discussion topic.....?
We want to know about it. Share your talk proposals here.We look forward to hearing from you.Rebecca--Rebecca GellatlyGeneral SecretaryOdoo Community Association
by Rebecca Gellatly - 03:31 - 16 Aug 2022 -
OCA Days 2022 - Info Blog Post
Hello Dear OCA Contributors.
I hope this email finds you all well.
I wanted to draw your attention to our latest blog post with a few more details about the OCA Days. Please have a read here.
Please note, that we only have 200 spaces (in past years we've only been able to sit around 150 in person, we are excited to be able to increase this), but we need to know who is coming and spaces are starting to fill up! Register here.We are so excited to hear your talk proposals too - the deadline is 31st August.
We can't wait to see you in Liège!Warmest regards,Rebecca--Rebecca GellatlyGeneral SecretaryOdoo Community Association
by Rebecca Gellatly - 10:46 - 10 Aug 2022 -
Re: How to import old invoices from legacy system
I dealt with importing at scale and it did not work well. Though I was able to import and get all the lines, etc. but then balancing tax ids and numbers was a really a challenge and we gave up at the end. I like David's approach of creating your own model and just move the meta data for reporting purposes and not use account.move.Regards,Vishal MehraeMail: vishal.mehra@bizalytics.netcell: (972) 853-1805website: http://www.bizalytics.netBizAlytics ConsultingAnalyzing Your Business for SuccessOn Thu, Jun 9, 2022 at 11:22 AM David Beal <david.beal@akretion.com> wrote:Hi Radovan,I think that a good approach to bring legacy data in Odoo is to create a model like in your case account.move.imported or account.invoice.imported.In this table you'll create some of important fields to use for comparison with new data.Don't set too many constraints on these fields even if you can setup many2one.After imported data, you can create sql views (query in init function of the new model including the 2 previous ones) in which you can aggregate the two models with Union sqlWith this you can have real statistics on whole history without too many headaches on importYou may customize functions used in Smart Buttons to have a real count or create new ones to have the 2 statsMy 2 cents.Le jeu. 9 juin 2022 à 14:02, Dominique k <dominique.k@elico-corp.com.sg> a écrit :importing old and paid invoices is complicated.you need to import invoicesand the payment entries. then you would need to reconcile them. consequently, they won't appear any longer in your list of unpaid invoicesnext you need to reverse them: let me explain. as you enter old invoices, they would generate revenue and the yearly balance will go to accumulated profit on the balance sheet. But this will be double counted when you will import your actual opening accounting balances. so.. the easiest method would be to reverse (to zero-ise) the entries so that you start with a clean balance sheet.hope this helps--On Thu, 9 Jun 2022 at 6:27 PM, Radovan Skolnik <radovan@skolnik.info> wrote:That makes sense but I guess this will enter into "accounting" and affect many things (accounting-wise). These are invoices spanning more than 15 years and have been "processed" (for the lack of better term on my side). Also not sure I am able to create those balanced entries. So I guess I'd stick with Sale Orders. Best regards Radovan On štvrtok 9. júna 2022 12:17:26 CEST Pedro M. Baeza (Tecnativa) wrote: > You have to create the whole `account.move` with `line_ids` one2many totally > filled and balanced. > > > Regards. > > > _______________________________________________ > 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
Dominique KON-SUN-TACK [Project Manager]Odoo Gold Partner, best Odoo Partner 2014 for APACMobile: + 65 8502 2399Skype: dominique_elicoWebsite: www.elico-corp.com
_______________________________________________
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 Vishal Mehra - 12:51 - 9 Aug 2022 -
Firebase integration with Odoo
Hello everybody, for a potential project, we need to integrate Odoo with Firebase DB and create a lot of Endpoint to exchange data like customer, product, sale order and so on. Has anyone done something similar? Thanks -- Stefano Sforzi Tel (CH): +41 91 210 23 40 Tel (IT): +39 0331 158 7090 https://www.agilebg.com
by stefano sforzi - 04:20 - 8 Aug 2022 -
Re: Procedure to create 16.0 branches
Hi,I'm no techie, and don't pretend to deeply understand this stuff. Also not a PSC of any repo. I am not very personally affected by whatever decision is made here and will happily defer to any decision.Regards benefits of this approach, the first question I ask is can this be achieved in other ways. Usually people tell me it is impossible immediately. I won't argue back, just random thoughts.- Improve security. One thought regards nefarious commits injected into migration. Is this solvable in other ways? Something like an AST/semantic diff maybe or even just a regular diff against last release. In fact a regular diff against last release may identify missed commits too. But anyway some kind of semantic diff outside of migration may be useful too as it would just ignore format changes. However, I think security is a separate important topic that needs a wider discussion regardless of whatever outcomes here are and we should be vigilant to those risks. But also as a reviewer, I think I'd rather review a semantic diff anyway.
- Avoid CLA bot issues: Do we really need to preserve ALL history every release - what about a squash merge - that maintains all the prior authors? Then maybe we can get an excpetion for that case in bot. For that 1 time ever you need a blame on a file 6 years ago, you can still traceback through versions.
- Reduce oca-github-bot complexity: I actually thought that work was done already. But in any case, is the argument here valid? Because not all modules in prior repo(s) would be merged at time the new one is created. So don't you avoid the complexity, until you don't? Wouldn't we need the functionality regardless? I don't know, genuine question.
- Slow git repo growth: As above for CLA Bot.
My general feeling I am getting -- Maintainers with tightly controlled, homogenous repos with a small number of maintainers and modules are in favour. These also tend to be "additive" repos, i.e. it is new functionality with not a lot of integration points. They also tend to be a bit more "technical". There is a very high likelihood of migration and also fairly rapidly. However, the contributors on those repos are more than capable of a 5 minute dance to do the port work.
- PSC's with large heterogeneous repos with many modules and contributors aren't so much in favour. Of course in these repos there tends to be a LOT of flux from version to version. Place like product-attribute, sale-workflow. These are often "insertive" type modules, putting themselves in middle of business processes. Design changes, upstream functionality changes, lots of modules dropping, reappearing.
I know for myself and some modules I have some involvement with.office 365 auth - hasn't changed between versions for 7 years. I don't even have any clients paying for it anymore - but 1 guy emails me once a year asking me to bump version number because it still works.partner statements - we did a big refactor for 11 or 12.0 maybe, a few minor changes for 13.0 accounting but less than you'd think because it is fundamentally just adding a couple reports.Now when I'm doing/reviewing those, I'll admit it does seem a bit wasteful this whole dance but it is no big deal.operating-unit - literally just a bunch of modules sticking a single field on a model, these are often awful to migrate because that happens in the middle of all sorts of functions, lots of interdependencies, stupid broken Odoo record rules. Plus they look easy, so often people seem to pick them for their first ever migration, review sucks on these and we get quite a few unexpected oversights. You really do need to download and test these PR's.I know it should make no difference, but my head just thinks better starting clean.sale-workflow/product-attribute type repos - honestly, a lot of the time in these repos it is about merging modules, deprecating modules, combining functionality, finding better repos as focus changes. I'm probably wrong, but I feel like prepopulating uninstallable is probably more work and missed opportunities.Anyway just my thoughts.But also, even if it is OK for 16, what about odd number version :) (This is a joke).On Thu, Jul 21, 2022 at 10:42 PM Pedro M. Baeza (Tecnativa) <notifications@odoo-community.org> wrote:> To make sure people reason about the correct arguments, let me emphasize again that the migration process would be strictly identical.Although theoretically you can use the same commands (but I repeat, I remember some problems in the past with this - I will try to dig on the history to find any -), what will happen for sure is that people forget to do/don't know such initial steps and appear that the migration pull request is correct, while it doesn't contain the missing commits, charging on the reviews to check this, so that's the real issue, together with other strong arguments like the IDE search, cleaning, etc.And I also agree having some repositories with one approach and another with the other approach is a mess. You have done the installable=False approach in the past for your specific repositories (mis-builder, storage, product-pim and queue mostly), because you do the migration yourself, not involving other contributors, but the rest of the repositories can't apply this method.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Graeme Gellatly - 03:15 - 21 Jul 2022 - Improve security. One thought regards nefarious commits injected into migration. Is this solvable in other ways? Something like an AST/semantic diff maybe or even just a regular diff against last release. In fact a regular diff against last release may identify missed commits too. But anyway some kind of semantic diff outside of migration may be useful too as it would just ignore format changes. However, I think security is a separate important topic that needs a wider discussion regardless of whatever outcomes here are and we should be vigilant to those risks. But also as a reviewer, I think I'd rather review a semantic diff anyway.
-
Re: Procedure to create 16.0 branches
> To make sure people reason about the correct arguments, let me emphasize again that the migration process would be strictly identical.Although theoretically you can use the same commands (but I repeat, I remember some problems in the past with this - I will try to dig on the history to find any -), what will happen for sure is that people forget to do/don't know such initial steps and appear that the migration pull request is correct, while it doesn't contain the missing commits, charging on the reviews to check this, so that's the real issue, together with other strong arguments like the IDE search, cleaning, etc.And I also agree having some repositories with one approach and another with the other approach is a mess. You have done the installable=False approach in the past for your specific repositories (mis-builder, storage, product-pim and queue mostly), because you do the migration yourself, not involving other contributors, but the rest of the repositories can't apply this method.Regards.
by Pedro M. Baeza - 12:41 - 21 Jul 2022 -
Re: Procedure to create 16.0 branches
To make sure people reason about the correct arguments, let me emphasize again that the migration process would be strictly identical.On Thu, Jul 21, 2022 at 11:26 AM LuisDaniel Lafaurie <notifications@odoo-community.org> wrote:Hello everyone,
I agree with what Rémi has just explained.
It wouldn't be wise to put more pressure on the migration process for the ones (PSCs and/or reviewers) working more actively on that subject.
Keeping the current method will be the best option so far, IMHO.
Thus, my vote is -1Thanks,On Thu, 21 Jul 2022 at 10:02, Rémi CAZENAVE - Le Filament <notifications@odoo-community.org> wrote:Hi all,
I like better the current method (having only working/tested/maintained modules in each branch) for the following reasons :
- I find it easier to see what is available un a given version, what would still need to be migrated, and also to get an idea of which versions are being actively used (though I guess I could look at READMEs, migration issues and overall statistics to get the same info)
- on each Odoo instance we deploy we download specific branch and having lots of unusable code would increase bandwidth and storage (although mostly text that could be compressed, so probably not dramatic neither)
I agree that the process to migrate a module from one version to another is not really easy (at least the first times), but I understand that it would still probably need to be done in order to make sure you get the latest commits from previous branch. I am afraid that this would often be forgotten if not strictly necessary in migration process, and for sure we do not want to transfer this extra burden of checking for each PR whether based on latest commits or not to reviewers / PSC.
Last, I am not in favour of having 2 different processes that can be applied per repo, since it would increase complexity for understanding why 2 repos are not behaving the same, and we may lose newcomers (but also for people not so much involved in OCA) - although here again I understand from discussions this is already the case for some repos.
My 2 cents...
Best Regards,
Rémi CAZENAVE
SCOP Le FilamentLe July 21, 2022 3:52:02 AM UTC, "Raphaël Valyi" <notifications@odoo-community.org> a écrit :Hello,My vote goes to the opt-in option at least unless Pedro get convinced, because going against the will of somebody processing such a large portion of the PRs would be a terrible shot in the feet.That being said, earlier Pedro raised the concern about the possibility to craft an attack commit inside a missing commit that would be cherry-picked just like with the current way of migrating. But:On Wed, Jul 20, 2022, 3:42 PM Roussel, Denis <notifications@odoo-community.org> wrote:To summarize:- commits SHA are different with current behaviour
- commits SHA are equal with proposed one
Denis could you confirm this SHA conservation could make us safe against such crafted attack commits in the middle of the missing commits that one would need to cherry-pick with the new procedure?This crafted commit attack thing is indeed extremely concerning..._______________________________________________
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
_______________________________________________
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 - 12:05 - 21 Jul 2022 -
Re: Procedure to create 16.0 branches
Hi,For the moment, I prefer the empty branches. The lifecycle of the module is really different from the lifecycle of major version releases.I think the focus should be on improving tools /workflows for keeping in sync modules across versions.Regards,Le jeu. 21 juil. 2022 à 10:02, Rémi CAZENAVE - Le Filament <notifications@odoo-community.org> a écrit :Hi all,
I like better the current method (having only working/tested/maintained modules in each branch) for the following reasons :
- I find it easier to see what is available un a given version, what would still need to be migrated, and also to get an idea of which versions are being actively used (though I guess I could look at READMEs, migration issues and overall statistics to get the same info)
- on each Odoo instance we deploy we download specific branch and having lots of unusable code would increase bandwidth and storage (although mostly text that could be compressed, so probably not dramatic neither)
I agree that the process to migrate a module from one version to another is not really easy (at least the first times), but I understand that it would still probably need to be done in order to make sure you get the latest commits from previous branch. I am afraid that this would often be forgotten if not strictly necessary in migration process, and for sure we do not want to transfer this extra burden of checking for each PR whether based on latest commits or not to reviewers / PSC.
Last, I am not in favour of having 2 different processes that can be applied per repo, since it would increase complexity for understanding why 2 repos are not behaving the same, and we may lose newcomers (but also for people not so much involved in OCA) - although here again I understand from discussions this is already the case for some repos.
My 2 cents...
Best Regards,
Rémi CAZENAVE
SCOP Le FilamentLe July 21, 2022 3:52:02 AM UTC, "Raphaël Valyi" <notifications@odoo-community.org> a écrit :Hello,My vote goes to the opt-in option at least unless Pedro get convinced, because going against the will of somebody processing such a large portion of the PRs would be a terrible shot in the feet.That being said, earlier Pedro raised the concern about the possibility to craft an attack commit inside a missing commit that would be cherry-picked just like with the current way of migrating. But:On Wed, Jul 20, 2022, 3:42 PM Roussel, Denis <notifications@odoo-community.org> wrote:To summarize:- commits SHA are different with current behaviour
- commits SHA are equal with proposed one
Denis could you confirm this SHA conservation could make us safe against such crafted attack commits in the middle of the missing commits that one would need to cherry-pick with the new procedure?This crafted commit attack thing is indeed extremely concerning..._______________________________________________
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
--Raphaël ReverdyMobile +33 6 38 02 03 93Fixe +33 4 82 53 84 60
by Raphaël Reverdy - 11:46 - 21 Jul 2022 -
Re: Procedure to create 16.0 branches
Hi All,
I am not in favor of this and most of this has already been said by others, but I want to re-iterate:
1. It is currently easy to see at a glance the state of the branch and which modules have been migrated
2. The current migration process for most modules is relatively easy
3. If it hinders or causes friction for current OCA contributors and causes them to engage less in OCA it shouldn't be done. Period.
4. The most important reason:
Except for the few modules that are widely used most modules are migrated after 1+ years of the Odoo SA version release. Quite a few modules are also migrated after more than 1 Odoo SA version release. I.E. version 12 module skips 13 and is migrated to 14 and then someone else migrates it to 13. This will create chaos.
I am also not in favor of an opt-in option because it's just an additional difference that we (developers and users) have to keep in mind (re: #1) and frankly the purported benefits do not outweigh the headaches it will cause.
Regards,
Mike.
On 21/07/2022 12:12, Aarón Henríquez Quintana wrote:
As a developer I love the way it is now.
- You know clearly what is migrated, and all the history
- Easy to track what is being migrated
- The process is clean, and you get used to it very fast, barely 4 commands in git.
- I think it is safe also, it is a responsibility of the repo maintainer that approves the PR to look at the code and check everything is correct.
If we apply the proposal:
- It is way more complex for developers, it open a bunch of possibilities:
- If it was not in v15 at the time the 16.0 branch was created: in this case we will be doing the current procedure
- If it was, and there is no improvement, then we will do a "normal" migration with 1 single commit, that's ok
- if it was, but it was improved, we have to include those improvements as well, the diff is not reduced as well.
- Deleted modules will create greater diffs.
- If the module was deleted because no one wanted to use it, but later on someone decides to migrate it, the diff is going to be super huge.
- It is going to be harder to know what is migrated, and being migrated, and what is not necessary.
I understand the improvements of the change but I think those improvements are now important enough with respect to the drawbacks.
On Thu, 21 Jul 2022 at 10:02, Rémi CAZENAVE - Le Filament <notifications@odoo-community.org> wrote:
Hi all,
I like better the current method (having only working/tested/maintained modules in each branch) for the following reasons :
- I find it easier to see what is available un a given version, what would still need to be migrated, and also to get an idea of which versions are being actively used (though I guess I could look at READMEs, migration issues and overall statistics to get the same info)
- on each Odoo instance we deploy we download specific branch and having lots of unusable code would increase bandwidth and storage (although mostly text that could be compressed, so probably not dramatic neither)
I agree that the process to migrate a module from one version to another is not really easy (at least the first times), but I understand that it would still probably need to be done in order to make sure you get the latest commits from previous branch. I am afraid that this would often be forgotten if not strictly necessary in migration process, and for sure we do not want to transfer this extra burden of checking for each PR whether based on latest commits or not to reviewers / PSC.
Last, I am not in favour of having 2 different processes that can be applied per repo, since it would increase complexity for understanding why 2 repos are not behaving the same, and we may lose newcomers (but also for people not so much involved in OCA) - although here again I understand from discussions this is already the case for some repos.
My 2 cents...
Best Regards,
Rémi CAZENAVE
SCOP Le Filament
Le July 21, 2022 3:52:02 AM UTC, "Raphaël Valyi" <notifications@odoo-community.org> a écrit :Hello,
My vote goes to the opt-in option at least unless Pedro get convinced, because going against the will of somebody processing such a large portion of the PRs would be a terrible shot in the feet.
That being said, earlier Pedro raised the concern about the possibility to craft an attack commit inside a missing commit that would be cherry-picked just like with the current way of migrating. But:
On Wed, Jul 20, 2022, 3:42 PM Roussel, Denis <notifications@odoo-community.org> wrote:
To summarize:
- commits SHA are different with current behaviour
- commits SHA are equal with proposed one
Denis could you confirm this SHA conservation could make us safe against such crafted attack commits in the middle of the missing commits that one would need to cherry-pick with the new procedure?
This crafted commit attack thing is indeed extremely concerning..._______________________________________________
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Raphael Makonnen - 11:41 - 21 Jul 2022 -
Re: Procedure to create 16.0 branches
Hi, I already use that process of not using an empty repo for several repo where I am the PSC and I definitely like it.So +1 for meLe jeu. 21 juil. 2022 à 11:26, LuisDaniel Lafaurie <notifications@odoo-community.org> a écrit :Hello everyone,
I agree with what Rémi has just explained.
It wouldn't be wise to put more pressure on the migration process for the ones (PSCs and/or reviewers) working more actively on that subject.
Keeping the current method will be the best option so far, IMHO.
Thus, my vote is -1Thanks,On Thu, 21 Jul 2022 at 10:02, Rémi CAZENAVE - Le Filament <notifications@odoo-community.org> wrote:Hi all,
I like better the current method (having only working/tested/maintained modules in each branch) for the following reasons :
- I find it easier to see what is available un a given version, what would still need to be migrated, and also to get an idea of which versions are being actively used (though I guess I could look at READMEs, migration issues and overall statistics to get the same info)
- on each Odoo instance we deploy we download specific branch and having lots of unusable code would increase bandwidth and storage (although mostly text that could be compressed, so probably not dramatic neither)
I agree that the process to migrate a module from one version to another is not really easy (at least the first times), but I understand that it would still probably need to be done in order to make sure you get the latest commits from previous branch. I am afraid that this would often be forgotten if not strictly necessary in migration process, and for sure we do not want to transfer this extra burden of checking for each PR whether based on latest commits or not to reviewers / PSC.
Last, I am not in favour of having 2 different processes that can be applied per repo, since it would increase complexity for understanding why 2 repos are not behaving the same, and we may lose newcomers (but also for people not so much involved in OCA) - although here again I understand from discussions this is already the case for some repos.
My 2 cents...
Best Regards,
Rémi CAZENAVE
SCOP Le FilamentLe July 21, 2022 3:52:02 AM UTC, "Raphaël Valyi" <notifications@odoo-community.org> a écrit :Hello,My vote goes to the opt-in option at least unless Pedro get convinced, because going against the will of somebody processing such a large portion of the PRs would be a terrible shot in the feet.That being said, earlier Pedro raised the concern about the possibility to craft an attack commit inside a missing commit that would be cherry-picked just like with the current way of migrating. But:On Wed, Jul 20, 2022, 3:42 PM Roussel, Denis <notifications@odoo-community.org> wrote:To summarize:- commits SHA are different with current behaviour
- commits SHA are equal with proposed one
Denis could you confirm this SHA conservation could make us safe against such crafted attack commits in the middle of the missing commits that one would need to cherry-pick with the new procedure?This crafted commit attack thing is indeed extremely concerning..._______________________________________________
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Sébastien Beau - 11:36 - 21 Jul 2022 -
Re: Procedure to create 16.0 branches
Hello everyone,
I agree with what Rémi has just explained.
It wouldn't be wise to put more pressure on the migration process for the ones (PSCs and/or reviewers) working more actively on that subject.
Keeping the current method will be the best option so far, IMHO.
Thus, my vote is -1Thanks,On Thu, 21 Jul 2022 at 10:02, Rémi CAZENAVE - Le Filament <notifications@odoo-community.org> wrote:Hi all,
I like better the current method (having only working/tested/maintained modules in each branch) for the following reasons :
- I find it easier to see what is available un a given version, what would still need to be migrated, and also to get an idea of which versions are being actively used (though I guess I could look at READMEs, migration issues and overall statistics to get the same info)
- on each Odoo instance we deploy we download specific branch and having lots of unusable code would increase bandwidth and storage (although mostly text that could be compressed, so probably not dramatic neither)
I agree that the process to migrate a module from one version to another is not really easy (at least the first times), but I understand that it would still probably need to be done in order to make sure you get the latest commits from previous branch. I am afraid that this would often be forgotten if not strictly necessary in migration process, and for sure we do not want to transfer this extra burden of checking for each PR whether based on latest commits or not to reviewers / PSC.
Last, I am not in favour of having 2 different processes that can be applied per repo, since it would increase complexity for understanding why 2 repos are not behaving the same, and we may lose newcomers (but also for people not so much involved in OCA) - although here again I understand from discussions this is already the case for some repos.
My 2 cents...
Best Regards,
Rémi CAZENAVE
SCOP Le FilamentLe July 21, 2022 3:52:02 AM UTC, "Raphaël Valyi" <notifications@odoo-community.org> a écrit :Hello,My vote goes to the opt-in option at least unless Pedro get convinced, because going against the will of somebody processing such a large portion of the PRs would be a terrible shot in the feet.That being said, earlier Pedro raised the concern about the possibility to craft an attack commit inside a missing commit that would be cherry-picked just like with the current way of migrating. But:On Wed, Jul 20, 2022, 3:42 PM Roussel, Denis <notifications@odoo-community.org> wrote:To summarize:- commits SHA are different with current behaviour
- commits SHA are equal with proposed one
Denis could you confirm this SHA conservation could make us safe against such crafted attack commits in the middle of the missing commits that one would need to cherry-pick with the new procedure?This crafted commit attack thing is indeed extremely concerning..._______________________________________________
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 Luis Lafaurie - 11:25 - 21 Jul 2022 -
Re: Procedure to create 16.0 branches
Hi all,
I like better the current method (having only working/tested/maintained modules in each branch) for the following reasons :
- I find it easier to see what is available un a given version, what would still need to be migrated, and also to get an idea of which versions are being actively used (though I guess I could look at READMEs, migration issues and overall statistics to get the same info)
- on each Odoo instance we deploy we download specific branch and having lots of unusable code would increase bandwidth and storage (although mostly text that could be compressed, so probably not dramatic neither)
I agree that the process to migrate a module from one version to another is not really easy (at least the first times), but I understand that it would still probably need to be done in order to make sure you get the latest commits from previous branch. I am afraid that this would often be forgotten if not strictly necessary in migration process, and for sure we do not want to transfer this extra burden of checking for each PR whether based on latest commits or not to reviewers / PSC.
Last, I am not in favour of having 2 different processes that can be applied per repo, since it would increase complexity for understanding why 2 repos are not behaving the same, and we may lose newcomers (but also for people not so much involved in OCA) - although here again I understand from discussions this is already the case for some repos.
My 2 cents...
Best Regards,
Rémi CAZENAVE
SCOP Le FilamentLe July 21, 2022 3:52:02 AM UTC, "Raphaël Valyi" <notifications@odoo-community.org> a écrit :Hello,My vote goes to the opt-in option at least unless Pedro get convinced, because going against the will of somebody processing such a large portion of the PRs would be a terrible shot in the feet.That being said, earlier Pedro raised the concern about the possibility to craft an attack commit inside a missing commit that would be cherry-picked just like with the current way of migrating. But:On Wed, Jul 20, 2022, 3:42 PM Roussel, Denis <notifications@odoo-community.org> wrote:To summarize:- commits SHA are different with current behaviour
- commits SHA are equal with proposed one
Denis could you confirm this SHA conservation could make us safe against such crafted attack commits in the middle of the missing commits that one would need to cherry-pick with the new procedure?This crafted commit attack thing is indeed extremely concerning..._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Rémi Cazenave - 10:01 - 21 Jul 2022 -
Re: Procedure to create 16.0 branches
> Denis could you confirm this SHA conservation could make us safe against such crafted attack commits in the middle of the missing commits that one would need to cherry-pick with the new procedure?> This crafted commit attack thing is indeed extremely concerning...It will be safer if the commit already resides in the prior branch when creating the new branch (and the SHA or signings will be the same). The problem is for missing commits that come after the branch creation. The only way to totally avoid this risk is to have one module per repo, and only "fork" when migrating the module, but we all know that this is impossible technically and by permission scheme.Regards.
by Pedro M. Baeza - 08:20 - 21 Jul 2022 -
Re: Procedure to create 16.0 branches
Having just read through many points, I don't want to throw too much weight behind proposal for or against.
But I will echo some of the points Lois raised.
I too, often search code for bits and pieces using my IDE, and to then some time later realse that slabs of results are from 1 or 2 versions ago and are "uninstallable".
Or seeing things in results and thinking "oh, I thought that approach was now depracated".
Modules which miss a version and get taken up again is an issue I wonder about, too.
And finally, although only small, I often look at the modules list in a repo and would, based on that, assume it is available in that version.
As a small contributor, I look on and wish you the best outcome whichever way it goes. In house, we blanket start with a clean slate each revision as it encourages rethinking of the approach against what the current practices and architecture demands.
Good luck.
Kind Regards
T: (03) 9135 1900 | M: 0403 76 76 76 | A: Bld 10/435 Williamstown Road, Port Melbourne, 3207
MAKING GROWTH THROUGH TECHNOLOGY EASY
Notice: This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, you may not disclose or use the information in this email in any way. If you have received this email in error please notify the sender. Although reasonable precautions have been taken to ensure no viruses are present in this email, no responsibility is accepted by WilldooIT Pty Ltd or its related entities for any loss or damage arising from the use of this email or attachments. Any views expressed in this email or file attachments are those of the individual sender only, unless expressly stated to be those of WilldooIT Pty Ltd ABN 85 006 073 052 or any of its related entities.
From: Lois Rilo Antelo <notifications@odoo-community.org>
Sent: Thursday, 21 July 2022 4:47 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Procedure to create 16.0 branchesHi,
From my point of view, a change that would need more PSC dedication to make it work is not a good idea. With this proposal, that's what it looks like to me, PSCs would need to do these tasks that are not needed now:
- Review obsolete/discontinued modules modules and create a PR to remove them.
- Pay attention to missing commits on migration PRs. It is true that this can happen now if a migration PR is open for a long period (while the PR is open new changes can be merged in previous versions), but the chances are lower and almost zero at the moment of opening the PR (zero if the contributor fetches just before starting to migrate).- Attend more CI issues on forward ports as they will be more frequent. I would say that currently a bot that forward ports stuff is a "nice to have" but with this proposal it would be a "must have".
On top of this, in point one I think it is not an easy task either. Think about the following scenario: module A is in branch 16.0 of repo R but not migrated yet, 1 year goes by and therefore the PSC proceeds to remove module A. Then a couple of months later someone finally migrates module A to version 16, he/she will re-add all commits and code, so 3 big diffs for a single moduleone mor. This highlights a question that has a difficult answer for me: How long does it take for a module to be obsolete and be removed?
From the perspective of a contributor/developer, there is also a problem that annoyed me a lot when branches were created with installable false, and it was that you will find stuff that is not relevant when searching things in your IDE as the non-migrated code is there. I think it is worth thinking about this as it will affect the day-to-day work of frequent contributors.
Also, when looking at repositories browsing github it is now very quick and easy to see what is dead, what is not migrated to the latest version, etc. you just need to see if there is something in a given branch in a given repository. It is true that the README of the repo can help, but be honest... I never scroll down to see the README, I don't think many people would do that intuitively.
I think the proposed approach can work for a number of repos, but not for the majority:- imagine sale-workflow without the natural cleaning of the clean start each year.- imagine a repository that gets contributions in v15 and then never again in next versions, the modules will be copied during years to newer versions.
Obviously these things can be mitigated but I think now modules and repositories "die" more naturally.
Therefore, I like the idea proposed by Holger, I think the branch initialization mode can be have 2 options being the current mode the default, the new mode for sure can work for specific repos with very defined scope and clear and active PSC like mis-builder (I could even give it a try in ddmrp).
My 2 cents :)
Kind regards,
On Wed, Jul 20, 2022 at 8:42 PM Roussel, Denis <notifications@odoo-community.org> wrote:
To summarize:
- commits SHA are different with current behaviour
- commits SHA are equal with proposed one
Moreover, for your size problem, current behaviour is taking more place than proposed one as new main branches are sharing same commits with preceding one.
You can test it locally (I did it) with git rev-list --disk-usage --objects --all
So, that point is solved.
On Wed, Jul 20, 2022 at 7:57 PM Pedro M. Baeza (Tecnativa) <notifications@odoo-community.org> wrote:
Dennis, the images unfortunately are not shown (Odoo/OCA instance bug), but the point in `This will increase the size of the repository the same, as no common ancestor and then different SHA.` is that it will affect the same on size on one procedure or the other.
> I see advantages here as currently if a module is not there, that does not mean if it is migrated yet or has been deprecated. With proposed approach, you can detect it more easily (present in previous branch, not in current. Moreover in the commit history you can see why it has been deprecated and learn about changes you maybe missed).
I don't get your point here, but it's the same good or bad, as it depends when a possible new module has arrived on prior branches.
> From several same approach repositories knowledge, I would say this will lead to a cleaner situation and an easier newcomers contribution processes understanding.
I have already expressed why it won't be cleaner and the problem not only for newcomers, but for existing contributors or reviewers.
Regards.
_______________________________________________
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
--
Lois Rilo AnteloOdoo consultant at ForgeFlow S.L._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by "Richard deMeester" <richard.demeester@willdooit.com> - 07:11 - 21 Jul 2022
