Friday, September 20, 2024
4 changes · saas-17.4
Resolved issues and error corrections
This fixes an issue where Point of Sale could charge the variant price adjustment twice when a cashier scanned a variant barcode. Scanned products with variant-specific extra prices should now show the correct total, reducing pricing errors at checkout.
Original PR description
Problem: The calculation of the extra price for product variants is being applied twice: - In the product model:…
Problem: The calculation of the extra price for product variants is being applied twice: - In the product model: https://github.com/odoo/odoo/blob/b966f2acc15503eafdbc4bda0d7733adcd635208/addons/product/models/product_product.py#L283 - In the point of sale store: https://github.com/odoo/odoo/blob/b966f2acc15503eafdbc4bda0d7733adcd635208/addons/point_of_sale/static/src/app/store/pos_store.js#L588-L595 https://github.com/odoo/odoo/blob/b966f2acc15503eafdbc4bda0d7733adcd635208/addons/point_of_sale/static/src/app/store/pos_store.js#L709-L717 In the case of a barcode-scanned product, the extra price is already included in the price, so we should avoid adding it again. Steps to reproduce: - Create a product with 2 variants, each having an extra price. - Add a barcode to each variant. - Open PoS and scan the barcode of any variant. - The extra price is added twice. opw-4177407 I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This fix restores the expected behavior for multi-checkbox product options in the self-ordering flow. Customers can now select multiple available attribute choices when ordering eligible products, reducing ordering errors and friction.
Original PR description
Problem: The `display_type` attribute was being retrieved from the wrong field, causing issues when selecting multiple product attributes in Self-Ordering. Steps to reproduce: - Create a product available for Self-Ordering. - Add a "Multi-checkbox" type attribute to the product. - Go to the Self-Ordering interface. - Attempt to order the product. - You can only select one attribute option, even though multiple should be selectable. opw-4192992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale orders now carry the sales team configured for the shop through to newly created orders and their invoices. This ensures sales reporting and invoice information correctly reflect the responsible team without overwriting teams already tied to existing settled orders.
Original PR description
Currently, if you have a sale team related to a shop, making an order will not link the sale team to the order. Steps to reproduce: ------------------- * Go to the **Point of sale** App * Go into…
Currently, if you have a sale team related to a shop, making an order will not link the sale team to the order. Steps to reproduce: ------------------- * Go to the **Point of sale** App * Go into settings * Under **Sale team** select any team * Open the related shop session * Make an order * Invoice it right after paying. * Go to the **Accounting App** * Select **Customer** then **Invoices** * Select the related invoice * Select the tab **Extra info** > Observation: The sale team is not set. Why the fix: ------------ When generating the invoice we are supposed to set the sale team with https://github.com/odoo/odoo/blob/ce73a1e19f19526b59bde9cebe2751102e2d8b27/addons/pos_sale/models/pos_order.py#L22 With `values` a dictionnary. In saas-17.4, the key `crm_team_id` is present in the dictionnary, but is `false`. Since `setdefault` will not perform any change to a dictionnary if the key is already present inside, the value is not set with the `crm_team_id` from the config. We do not want to change this as `values['crm_team_id']=...` as it would systematically override the value and in the case when we settle an order we still want to use the sale team associated to that order. Why is `values['crm_team_id']` false? Because the order in the shop has the field `crm_team_id` available but it's `undefined` because not loaded to the session. https://github.com/odoo/odoo/blob/8dd35e194e54fd364100d57b32b8aff7b5ffec35/addons/point_of_sale/static/src/app/store/pos_store.js#L993-L995 What we do with this fix is to load the value of the sale team set in config to the shop and we set the value for every new order. opw-4151736
This fixes an error that could prevent users from opening projects after the Sales app was uninstalled. The cleanup process now properly removes leftover Sales-related project actions, avoiding confusing crashes and keeping Projects usable.
Original PR description
A traceback occurs when the user uninstalls the sales module and tries to open any project. To reproduce this issue: 1) Install sales, project 2) Uninstall sales 3) Try to open any project Error:-…
A traceback occurs when the user uninstalls the sales module and tries to open any project. To reproduce this issue: 1) Install sales, project 2) Uninstall sales 3) Try to open any project Error:- ``` KeyError: 'allow_billable' ``` This is because of the new embedded action introduced in the project module. When the user uninstalls the sale module the embedded action record of the sale needs to be deleted. https://github.com/odoo/odoo/blob/45e75693e8ee4f8cf9af842cd2facd4f2f6356d8/odoo/addons/base/models/ir_model.py#L2480-L2485 But an exception is raised because of the unlink method triggered during the uninstallation for embedded action and an exception is raised. https://github.com/odoo/odoo/blob/45e75693e8ee4f8cf9af842cd2facd4f2f6356d8/odoo/addons/base/models/ir_embedded_actions.py#L90-L94 Due to this, the embedded action record is stored in the `undeletable_ids`. Later it is removed from the `module_date` and the remaining module data is deleted. https://github.com/odoo/odoo/blob/45e75693e8ee4f8cf9af842cd2facd4f2f6356d8/odoo/addons/base/models/ir_model.py#L2524-L2531 Finally, the embedded action of the sale module is not deleted and has a domain, which contains `allow_billable`. This leads to the above traceback. sentry-5677055153