[18.0] [MIG] delivery_postlogistics: Migration to 18.0

[StephaneMangin]

Includes:

• reusing of "delivery.carrier.template.option" from OCA module "delivery_carrier_option"
• reusing of "shipping.label" from OCA module "delivery_carrier_shipping_label" instead of custom "postlogistics.shipping.label"
• Add a default package type to fullfill postlogistics_send_shipping requirements (Using ECO default shipping pricing)

Depends on:

• [18][ADD/MIG] delivery_carrier_option (extracted from base_delivery_carrier_label module) #900
• [18.0][MIG] delivery_carrier_info: Migration to 18.0 #936
• [18][ADD] delivery_carrier_shipping_label : extracted from base_delivery_carrier_label #938

To avoid Odoo external URL calls restriction, decorate your test class with @common.tagged("-standard") (removing the standard tag which is by default). This way, Odoo doesn't patch the request.Session.send method to throw an exception in an external URL call case.

[StephaneMangin]

Superseeds #940

[yankinmax]

hello @StephaneMangin
There is an issue in migration. You're overriding the selection of the type field declared for delivery.carrier.template.option model in delivery_carrier_option module.
Here is Odoo logs:

WARNING testdb odoo.fields: delivery.carrier.template.option.type: selection=[('label_layout', 'Label Layout'), ('output_format', 'Output Format'), ('resolution', 'Output Resolution'), ('basic', 'Basic Service'), ('additional', 'Additional Service'), ('delivery', 'Delivery Instructions'), ('partner_option', 'Partner Option')] overrides existing selection; use selection_add instead

[rousseldenis]

/ocabot migration delivery_postlogistics

[StephaneMangin]

hello @StephaneMangin There is an issue in migration. You're overriding the selection of the type field declared for delivery.carrier.template.option model in delivery_carrier_option module. Here is Odoo logs:

WARNING testdb odoo.fields: delivery.carrier.template.option.type: selection=[('label_layout', 'Label Layout'), ('output_format', 'Output Format'), ('resolution', 'Output Resolution'), ('basic', 'Basic Service'), ('additional', 'Additional Service'), ('delivery', 'Delivery Instructions'), ('partner_option', 'Partner Option')] overrides existing selection; use selection_add instead

Yes it is transitional, because these values are added in a dependency. Updating...

[StephaneMangin]

@bizzappdev Hi, you can find the solution to external URL call avoid by Odoo on the description.

[bizzappdev]

This tag allows all traffic to the external URL.

From my understanding, VCR will only listen when use_cassette is in context. Additionally, Odoo has explicitly blocked external URLs, likely for a valid reason. Ideally, the URL used in the cassette and the shipping method for test cases should be set to localhost.

Using localhost should not cause any issues, while bypassing Odoo's URL check could introduce a potential risk. Could you confirm if there is a specific reason for allowing an external URL in this case?
@StephaneMangin

[StephaneMangin]

Yes, when we want to refresh the testcase when the API changes. We want to keep the original URLs and configuration.

Here the call is not done externally, Odoo check the validity of the URL before VCR applies... Which is difficult to get around easily. For now i don't see any risks with this configuration. Later on we could find a way to manage differently this approach or if someone finds it, we would update this module accordingly.

[bizzappdev]

Thanks for the clarification, I agree that these particular test cases and modules do not pose a risk. However, since this is a generic module, what if someone inherits a test case class or a module method that interacts with the external URL? Wouldn't that introduce a potential risk?

Additionally, since Odoo validates the URL before VCR applies, bypassing this check could lead to unforeseen issues in the future. While there may not be immediate concerns, would it be worth exploring an approach in the future where we mock the API response while still keeping the external URL intact in the cassettes? This might help maintain Odoo’s validation integrity while ensuring test cases remain up to date.

Alternatively, you could consider having separate test cases specifically for API changes and tagging them with a -standard tag, which would serve your purpose while also ensuring test cases remain risk-free and enhance the module’s extensibility.