[17.0][MIG] repair_picking_after_done: Migration to 17.0

[ppyczko]

Module migrated to version 17.0

cc https://github.com/APSL 162593

@miquelalzanillas @lbarry-apsl @mpascuall @peluko00 @javierobcn @BernatObrador please review

• Issue Migration to version 17.0 #36

Depends on:

• [repair_stock] [17.0][MIG] repair_stock: Migration to 17.0 #63

An [IMP] has been added to prevent the creation of transfers exceeding remaining quantities in repair orders.

[mpascuall]

LGTM, tested in runboat

[peluko00]

LGTM, code review

[ppyczko]

Hi @LoisRForgeFlow, sorry to ping directly. Could you please review this module and the dependency (#63) when you have a moment? Thank you!

[BernatObrador]

LGTM

[LoisRForgeFlow]

/ocabot migration repair_picking_after_done

[LoisRForgeFlow]

@ppyczko Dependency merged, you can remove the requirements commit

[ppyczko]

@ppyczko Dependency merged, you can remove the requirements commit

Done! Thank you @LoisRForgeFlow

[LoisRForgeFlow]

Overall looks good! One detail that I realized while testing (probably hapening in previous versions) is that when creating a backorder of one of these repair after done transfers, the backorder is not linked to the reapair order and you cannot find it navigating with the smart button.

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[ppyczko]

Overall looks good! One detail that I realized while testing (probably hapening in previous versions) is that when creating a backorder of one of these repair after done transfers, the backorder is not linked to the reapair order and you cannot find it navigating with the smart button.

Thank you for taking the time to review this module and for your feedback @LoisRForgeFlow!

While reviewing your input, I found out that these backorders are not only not linked to the repair order, but they actually aren’t created at all. This is due to this piece of code in core of Odoo:

• When creating a 'stock.move', the '_action_done' method checks if it has to create any backorders and, if it does, it eventually calls the '_split' method: https://github.com/odoo/odoo/blob/17.0/addons/stock/models/stock_move.py#L1900
• This '_split' method prevents stock moves from being split when they’re associated with a repair order, meaning that no backorders will be created: https://github.com/odoo/odoo/blob/17.0/addons/repair/models/stock_move.py#L189

This behavior seems intentional and aligns with the idea that, once a repair is marked as done, the items are fully ready and available, not partially available.

In my view, this makes sense -- backorders after a completed repair could cause confusion. In my opinion, when a repair is completed, it implies that all items in that order are ready to be returned to the customer. A backorder might imply partial availability, which doesn’t seem to fit with the concept of a finished repair.

That said, I may be missing some use case or context here, so I’d really appreciate any thoughts or perspectives you might have on this. If there’s a scenario where backorders after a repair could add value, I’d love to understand it better.

After all, if you think we do need backorders, it would be as easy as overriding this _split method, and we could make that adjustment quickly.

[LoisRForgeFlow]

@ppyczko Thanks for investigating and for the detailed feedback.

For me, Odoo has decided that they do not want to handle backorders of repairs, I am not against that as long as the code is consistent with that idea and it seems so, as you pointed out in the code. That part is fine, but here we are talking about an additional operation/transfer that takes places just after the repair is done, this operation is not anything else than an internal operation or a delivery like any other, it is just linked to the repair order for traceability purposes. Therefore from my perspective, this post-repair operation should allow backorders as any other, whatever the reason, I don't see why we should not allow that.

In short, I would keep restriction to split stock moves of the repair order and I would allow split in this related post-repair operations.

Does this make sense to you?

[ppyczko]

Thank you for the detailed explanation @LoisRForgeFlow. I hadn't considered it from that angle, and I agree with your resolution.

I’ve implemented the change, and backorders can now be created once a repair order is completed. Due to the dependency chain, I wasn't able to use super() to call the split() method, which would have been the cleanest approach. This is because, when calling super() from the repair_picking_after_done module, the split() method in the core Repair module is triggered (instead of the one in the core Stock module), preventing any stock moves related to a repair order from being split, regardless of whether the repair is completed. As a result, I had to override the split() method in the Stock module directly and add the repair validation at the start of the method. I’ve documented this in the method for future reference.

If you have any suggestions for improvement, I’d greatly appreciate your advice. Otherwise, the module is ready for testing again. Thank you!

[peluko00]

It's ready to merge @LoisRForgeFlow ? When it merge we will do an IMP to this module

[LoisRForgeFlow]

Thanks for the proposal, I think we can do it a bit cleaner, see below my proposals:

[LoisRForgeFlow]

@ppyczko I looks good now!

Thanks for attending all the comments 👍

[LoisRForgeFlow]

/ocabot merge nobump

[OCA-git-bot]

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 17.0-ocabot-merge-pr-65-by-LoisRForgeFlow-bump-nobump, awaiting test results.

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[OCA-git-bot]

Congratulations, your PR was merged at cd8301a. Thanks a lot for contributing to OCA. ❤️