shopinvader_api_delivery_carrier: hide delivery line in cart

[sebastienbeau]

Hide delivery line in cart
Depends on

• [16.0] shopinvader_schema_sale: allow to hide some line in the schema (like delivery...) odoo-shopinvader#1564

[sbidoul]

Can you elaborate the use case?

[lmignon]

@sebastienbeau I don't really see why we should hide lines from a SO. You always have the 'name' field, which gives information describing what the line represents (you can have lines that are notes, sections, delivery charges, ....). Even if the line refers to a technical product that may not be available in ES, this should not matter. The product life cycle will mean that a product purchased in the past will no longer be present in ES, and this should not block the display of an order in the UI. Taking this a step further, the fact that the product identifier may or may not be available to the consumer of the API should not be a factor in this discussion, since we are dealing here with the API and not with its use by a website. But maybe I miss something...

[sebastienbeau]

Hi @sbidoul @sbidoul sorry for the delay

The idea it to give a better experience for the front-end developer (like we had in version 14 see: https://github.com/shopinvader/odoo-shopinvader/blob/0b031e87c4a64e7f013598e2f8c76ac206c126cd/shopinvader_delivery_carrier/services/abstract_sale.py#L48).

In the schema of the cart / sale the delivery price is accessible with special key see here: https://github.com/shopinvader/odoo-shopinvader-carrier/blob/d681c1a788d886a0da5e37c8a73cea2cf05c6b98/shopinvader_api_delivery_carrier/schemas/amount.py

Before this PR we have a duplicated information

• the price of the delivery is accessible in the cart / sale with the key tax_without_shipping, tax_without_shipping, tax_without_shipping, total_without_shipping_without_discount
• and the also as a line in the cart / sale

In a front end point of view. It make no sense to have the delivery as a product and they always have to remove it (If the delivery cost exist in a line in odoo is only because of the implementation, so It should not design our API).

Note: I choose to add a computed field so It's easier to reuse this computed field when trying to read the sale.line directly using this API : shopinvader/odoo-shopinvader#1508 without creating too many glue module.

Thanks for your feedback

[sbidoul]

I sort of see your point, but visible_in_shopinvader_api does not sound right to me.

give a better experience for the front-end developer

How does the front end dev filter today? In a project I see this:

Indeed it does not seem very easy to detect shipping and reward lines.

Would a is_shipping or is_reward flag on sale lines help?

cc/ @marielejeune @qgroulard who may have an opinion on this too.

[marielejeune]

Indeed from the schema it is impossible to detect reward and delivery lines for now.
In our projects the prices computations (such as for total_wo_discount_wo_shipping_wo_reward which is a custom field) are done in the schemas, not letting the front-end dev dealing with that.
We thus used the is_delivery and is_reward_line flags that are present on a SOL. But we could expose these flags directly in the SOL schema.