[16.0][MIG] sale_delivery_state

[atchuthan]

cc: @SodexisTeam

[atchuthan]

@OCA/community-maintainers Test fails due to mock python package missing at https:/OCA/sale-workflow/actions/runs/3540792580/jobs/5944271297

  File "/__w/sale-workflow/sale-workflow/sale_delivery_state/tests/__init__.py", line 1, in <module>
    from . import test_delivery_state
  File "/__w/sale-workflow/sale-workflow/sale_delivery_state/tests/test_delivery_state.py", line 6, in <module>
    import mock
ModuleNotFoundError: No module named 'mock'

[rousseldenis]

/ocabot migration sale_delivery_state

[RodrigoBM]

@rousseldenis you think it is a good idea to remove the logic associated with force_delivery_state?

I think that if I have decided to set the status of a sale to delivered as done manually, this status should not be recalculated if the quantity of any line is changed.

But if this change is correct, the action_unforce_delivery_state method is not needed, as the delivery_state field is now selectable. And the name of the function action_unforce_delivery_state should be changed to for example action_recalculate_delivery_state

[rousseldenis]

@rousseldenis you think it is a good idea to remove the logic associated with force_delivery_state?

I think that if I have decided to set the status of a sale to delivered as done manually, this status should not be recalculated if the quantity of any line is changed.

But if this change is correct, the action_unforce_delivery_state method is not needed, as the delivery_state field is now selectable. And the name of the function action_unforce_delivery_state should be changed to for example action_recalculate_delivery_state

As I said:

But maybe this is something unwanted as we really want to force it (even if qty_delivered on lines change)

So, maybe it's a good idea to keep the force field with current changes too.

[RodrigoBM]

I think that both solutions can be correct

@rousseldenis you think it is a good idea to remove the logic associated with force_delivery_state?
I think that if I have decided to set the status of a sale to delivered as done manually, this status should not be recalculated if the quantity of any line is changed.
But if this change is correct, the action_unforce_delivery_state method is not needed, as the delivery_state field is now selectable. And the name of the function action_unforce_delivery_state should be changed to for example action_recalculate_delivery_state

As I said:

But maybe this is something unwanted as we really want to force it (even if qty_delivered on lines change)

So, maybe it's a good idea to keep the force field with current changes too.

But considering that this is a migration issue, we should keep the development logic. What do you think? @atchuthan @dreispt

[atchuthan]

I think that both solutions can be correct

@rousseldenis you think it is a good idea to remove the logic associated with force_delivery_state?
I think that if I have decided to set the status of a sale to delivered as done manually, this status should not be recalculated if the quantity of any line is changed.
But if this change is correct, the action_unforce_delivery_state method is not needed, as the delivery_state field is now selectable. And the name of the function action_unforce_delivery_state should be changed to for example action_recalculate_delivery_state

As I said:

But maybe this is something unwanted as we really want to force it (even if qty_delivered on lines change)

So, maybe it's a good idea to keep the force field with current changes too.

But considering that this is a migration issue, we should keep the development logic. What do you think? @atchuthan @dreispt

so, do we revert the code to use force field as it was in v15? @rousseldenis @RodrigoBM

[RodrigoBM]

I think that both solutions can be correct

@rousseldenis you think it is a good idea to remove the logic associated with force_delivery_state?
I think that if I have decided to set the status of a sale to delivered as done manually, this status should not be recalculated if the quantity of any line is changed.
But if this change is correct, the action_unforce_delivery_state method is not needed, as the delivery_state field is now selectable. And the name of the function action_unforce_delivery_state should be changed to for example action_recalculate_delivery_state

As I said:

But maybe this is something unwanted as we really want to force it (even if qty_delivered on lines change)

So, maybe it's a good idea to keep the force field with current changes too.

But considering that this is a migration issue, we should keep the development logic. What do you think? @atchuthan @dreispt

so, do we revert the code to use force field as it was in v15? @rousseldenis @RodrigoBM

In my opinion, I think so.

[RodrigoBM]

@atchuthan, can you revert the last change?

[atchuthan]

@atchuthan, can you revert the last change?

@RodrigoBM reverted. Please review

[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). 🤖

[RodrigoBM]

Checking version 16, in the base module sale_stock it adds the delivery_status field which is the same logic as the delivery_state field in this module.
I think this module is no more necessary. And create a new module called sale_force_delivery for example, to add the force status logic for the new delivery_status base field.
cc: @atchuthan @rousseldenis @dreispt

[RodrigoBM]

#2280 (review)

[atchuthan]

Checking version 16, in the base module sale_stock it adds the delivery_status field which is the same logic as the delivery_state field in this module. I think this module is no more necessary. And create a new module called sale_force_delivery for example, to add the force status logic for the new delivery_status base field. cc: @atchuthan @rousseldenis @dreispt

I am okay with removing this module in favor of odoo's already field, and we will remove the dependency to sale_automatic_workflow too. Please confirm whether I can proceed or not?

[atchuthan]

Closing this PR as this module is not needed for v16