Migration to version 11.0

[pedrobaeza]

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0

Modules to migrate

• [x] account_operating_unit - By @grindtildeath - #140
• [ ] account_voucher_operating_unit
• [x] analytic_operating_unit - By @gdgellatly - #101
• [ ] crm_operating_unit
• [x] operating_unit - By @gdgellatly - #99
• [ ] procurement_operating_unit
• [ ] purchase_operating_unit
• [x] sale_operating_unit - BY @bjeficent - #163
• [ ] sale_stock_operating_unit
• [x] sales_team_operating_unit - By @gdgellatly - #100
• [ ] stock_operating_unit - By @meigallodixital - #132

[gdgellatly]

Hi @pedrobaeza @jbeficent are you happy for me to migrate this whole repo and commit to review (or at least helping me find a reviewer)? I don't really use it, but I think I'd like to, so would be a straight port unless you have specific comments. Also any other warnings based on current open PR's and issues.

Obviously 1 PR per module, all done by Nov 30 maybe all done next week.

I've had a quick look, there is not much work there really for a straight port. Probably less than a day, a lot of it won't even need a single edit, mostly mangling with git.

[pedrobaeza]

Thanks for the initiative, Graeme. Of course it's very welcome. The coordinator of this repository is @elicoidal .

[pedrobaeza]

Ah, no sorry, my fault. It's @jbeficent indeed.

[elicoidal]

:)

[AaronHForgeFlow]

Hi @gdgellatly, you are very welcome to collaborate to this repo. We will review your PRs and we will try to get more reviewers. Besides It'd be very nice if you review some of the opened PRs in v10 :relaxed:

[gdgellatly]

@aheficent Of course I will review. There seems some ready to merge, others under discussion. Nothing really left out in the cold needing review. But anything pinged at me I will always review, or just label them as needs review and I'll check back as I get through things.

[AaronHForgeFlow]

@gdgellatly Thank you. I will label the PRs that are ready to review.

[gdgellatly]

@aheficent OK I have migrated everything, I'll just make PR's as they merge as they are all stacked, so when there are changes I'll need to update everything above. It's all at https://github.com/gdgellatly/operating-unit - I did sale_stock_operating_unit last.

After some testing, the repo doesn't quite meet my use case, so I'll probably start something a bit more radical on my own, but I like the concept. Its just too restrictive that each operating unit must have its own warehouses and locations, but was worthwhile getting through the code.

For the most part I can summarize the changes as

• remove now extraneous header and update version
• ensure operating_unit_id is positioned before company in all view where possible
• fix constraints to raise ValidationError rather than UserError
• fix constraints to not constrain related readonly fields
• neaten up most error messages
• don't store fields for no reason
• add some indexes where appropriate (I probably missed a couple here)
• fix some tests that were pulling ids from different models to what they were testing, a few other general test fixups
• where there were obvious bugs (e.g. super call to different function) or performance refactorings I generally did them.

[JordiBForgeFlow]

@gdgellatly Perhaps the restriction that warehouses and locations should be owned by an operating unit should be relaxed, so that only in the case where you expect a separate balance sheet per operating unit should this restriction be put in place.

[JordiBForgeFlow]

@gdgellatly In general the issue is that as soon as you use real time inventory accounting, every time you ship a product from a warehouse it is going to hit a COGS account. So how can you decide what operating unit should be attributed for that cost?

[AaronHForgeFlow]

@gdgellatly thank you for your work, I'll review when creating the PR's to OCA

[gdgellatly]

@jbeficent Indeed those are questions I need to answer, I didn't say it was easy. But if I take a logical look at it, even in a self balancing environment I think it can be done.

The COGS case is simple under AngloSaxon as it is accrued at time of sale, and as such easy to apply.

But there is a more general case, beyond stock for difficult to apply items, e.g. Finance and Intangible type items. As I say I'm not sure yet, I have some ideas which I want to test.

From a balance sheet perspective there are always items that cannot be specifically assigned to an OU, e.g. A trademark, or a general bond issue etc but

[JordiBForgeFlow]

@gdgellatly For trademark, etc. you can have a "corporate" OU.

[edser-pcg]

Hello, is there any time estimate for when these PRs will be merged?

[JordiBForgeFlow]

No estimate. People migrate them to v11 as they need them.

[edser-pcg]

Yes but @gdgellatly made a bunch of PRs and states the work is done but awaiting for revision. Need testers? We can do the testing if required

[JordiBForgeFlow]

@edsersolis Testing would indeed help a lot to get them merged. Please ping me on each PR as you have reviewed.

[gdgellatly]

@edsersolis @jbeficent realistically once #99 is merged, and it is mergeable now (all reviews done etc) I can clean up the rest, but no point testing the others yet as we ended up having to change quite a bit.

[JordiBForgeFlow]

@gdgellatly #99 is now merged. Feel free to propose other PR's. Thank you for the great contribution!

[pedrobaeza]

@jbeficent the remember to check the mark on the main comment :wink:

[marnicodigital]

Hi all. We are new here. We found this modules and could need them in a project. Is there any roadmap on migration to v11?. Regards.

[gdgellatly]

@jbeficent #100 has been ready for a few weeks. I've been without reliable internet the last few weeks so will catch up on the rest later.

@marnicodigital its a volunteer community. No one tells anyone to or stops anyone from migrating or reviewing proposals. So there is no roadmap. It is as/when people commit their time and a lot of us are involved in many OCA projects at once. Because the modules are all interdependent, I'm just migrating them as each one is approved and porting the improvements from the review process.

[meigallodixital]

We have installed the base module, checked the Multi Operating Unit checkbox in the user's permissions, but it gives us a read permission error. We can create records without problem. We do not even see the operational unit created by default in the installation (OU1). The core is OCB.

We are trying to simulate independent physical stores with this addon, I do not know if apart from the above we are on the wrong way.

[AaronHForgeFlow]

@meigallodixital Can you provide more info? Where do you get the error in the Operating unit records? Maybe in the Sales team? Have you assigned the problematic user to the operating units in the user form view?

[meigallodixital]

@aheficent At Settings -> User & Companies -> Operating Units

We have only installed: operating_unit

I attach screenshot: https://snag.gy/zFVfgi.jpg

[AaronHForgeFlow]

@meigallodixital Please follow up this issue I created for this: https://github.com/OCA/operating-unit/issues/129 This issue is for sharing the status of the migration only

[emagdalenaC2i]

@pedrobaeza please check in the list account_operating_unit - By @grindtildeath - #140

[nikul-serpentcs]

res_partner_operating_unit #324

[github-actions[bot]]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.