Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[15.0][MIG]stock_picking_type_shipping_policy: Migration to 15.0 #540

Conversation

bizzappdev
Copy link

No description provided.

grindtildeath and others added 19 commits January 18, 2023 14:29
... stock_picking_group_by_partner_by_carrier (of
OCA/stock-logistics-workflow).

In stock_picking_group_by_partner_by_carrier, the override of the method
_search_picking_for_assignation adds a domain on:

("move_type", "=", self.group_id.move_type)

(self is the move to assign in a picking).

When the move_type of the procurement group is "direct", the transfer is
normally created with the move_type "direct": when a first move is
assigned to a picking and none is found, it creates one with type
"direct", the second move should find the same and be assigned to it.

This is not what happens, with stock_picking_type_shipping_policy
configured to "force_all_product_ready", as it changes the way the first
stock.picking is created:

    def _get_new_picking_values(self):
        res = super()._get_new_picking_values()
        picking_type = self.mapped("picking_type_id")
        if picking_type.shipping_policy == "force_as_soon_as_possible":
            res["move_type"] = "direct"
        elif picking_type.shipping_policy == "force_all_products_ready":
            res["move_type"] = "one"
        return res

The first stock.picking is created with a move_type of "one", so when
the second move search a stock.picking, it can't find it as it looks for
a "direct" one.

This glue module changes the domain of the grouping to take into account the
picking type's shipping policy when both modules are installed.
Currently translated at 100.0% (4 of 4 strings)

Translation: wms-13.0/wms-13.0-stock_picking_type_shipping_policy
Translate-URL: https://translation.odoo-community.org/projects/wms-13-0/wms-13-0-stock_picking_type_shipping_policy/es_MX/
Currently translated at 100.0% (4 of 4 strings)

Translation: wms-13.0/wms-13.0-stock_picking_type_shipping_policy
Translate-URL: https://translation.odoo-community.org/projects/wms-13-0/wms-13-0-stock_picking_type_shipping_policy/es_AR/
@bizzappdev bizzappdev changed the title [WIP][15.0][MIG]stock_picking_type_shipping_policy: Migration to 15.0 [15.0][MIG]stock_picking_type_shipping_policy: Migration to 15.0 Mar 4, 2023
@bizzappdev
Copy link
Author

Ready for the review

@pedrobaeza
Copy link
Member

/ocabot migration stock_picking_type_shipping_policy

@OCA-git-bot OCA-git-bot added this to the 15.0 milestone Mar 4, 2023
@OCA-git-bot OCA-git-bot mentioned this pull request Mar 4, 2023
35 tasks
@@ -3,7 +3,7 @@
{
"name": "Stock Picking Type Shipping Policy",
"summary": "Define different shipping policies according to picking type",
"version": "14.0.1.1.0",
"version": "15.0.1.1.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To reset to 15.0.1.0.0

Comment on lines +18 to +19
("force_as_soon_as_possible", "Force to as soon as possible"),
("force_all_products_ready", "Force to when all products are ready"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO we could ease the mapping to one or direct value by redefining these to force_one and force_direct and add a migration script. Not blocking though, but please add in the roadmap if we don't do it in this version.

@bizzappdev bizzappdev force-pushed the 15.0-mig-stock-picking-type-shipping-policy-BAD-SIP branch from f0dec16 to d660a85 Compare May 11, 2023 12:35
@github-actions
Copy link

There hasn't been any activity on this pull request in the past 4 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 PR to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Sep 10, 2023
@github-actions github-actions bot closed this Oct 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale PR/Issue without recent activity, it'll be soon closed automatically.
Projects
None yet
Development

Successfully merging this pull request may close these issues.