Odoo Changelog — 2024-12-05

Thursday, December 5, 2024

3 changes · master

Bug Fixes(3)

Resolved issues and error corrections

[FIX] social_demo: don't duplicate dependency data

Enterprisemastersocial_demo

The Social Demo module now reuses existing standard records instead of creating duplicate copies. This reduces test database inconsistencies and helps avoid unexpected issues when the demo module is installed accidentally or for testing.

Original PR description

Although `social_demo` is a strong independent module it's a bit odd that it partially duplicates a bunch of data from `base` and `product`, and if it gets installed (possibly by mistake) into a database for testing, some tests don't cope well with the issue.

Remove the duplicated records and just reference the base ones. Leave `product_product_4d` as it's either novel to `social_demo` or was removed from `product` since it was initially duplicated.

#demo data#testing#data consistency

[FIX] point_of_sale: link records cache to the reactivity

PR #74960

Enterprisemasterpoint_of_salepos_avataxpos_restaurant_appointmentMEDIUM

This fix ensures Point of Sale screens refresh properly when orders are added or removed. It prevents outdated order tabs from staying visible, improving reliability for staff managing active or floating orders.

Original PR description

The records cache (from `related_models` module) isn't properly linked to the
reactivity of `posmodel`. As a result, some expected rerenderings aren't
executed. An example of this is the `OrderTab`. When a new floating order is
created the `OrderTab` rerenders listing the new order. However, when that empty
order is deleted, the corresponding tab item isn't removed in the list. That is
because the `OrderTab`'s render method isn't properly subscribed to the changes
in `models['pos.order']`. The render subscription doesn't exist because
`models['pos.order'].readAll` isn't reading on the reactive version of the
`records` cache. That is because `get orderedRecords` is pointing to the
non-reactive version of `records`. `get records` exists in `models` and that's
what we should use to properly link it to the reactivity and that `OrderTab`
properly subscribes `models['pos.order']`.

In this PR we are making sure that the methods of `models` (return value of
`createCRUD`) is properly using the `reactive` version of the `records` cache.
We then pass that version to the CRUD methods to ensure continuity of reactivity
in the records.

We also need to make changes in the `OrderTab` template, converting
`floating-order-container` from `id` to `class` since it's being used for each
order. We should not have multiple instances of an id in the html.

TASK-ID: 4369054

#point of sale#order tabs#screen refresh#reactivity

[FIX] stock_barcode_barcodelookup: Misspelled error message

PR #73499

Enterprisemasterstock_barcode_barcodelookup

The barcode scanning flow now shows a correctly spelled and grammatically improved error message when a scanned barcode is not found. This makes the receipt process clearer for users and reduces confusion during warehouse operations.

Original PR description

Barcode --> Operations --> Receipts --> NEW
Scan a barcode that doesn't exist in the DB ie: "5449000000996"

The current error message's spelling and grammar are off.

opw-4307102

#barcode#receipts#error-message

Although `social_demo` is a strong independent module it's a bit odd that it partially duplicates a bunch of data from `base` and `product`, and if it gets installed (possibly by mistake) into a database for testing, some tests don't cope well with the issue. Remove the duplicated records and just reference the base ones. Leave `product_product_4d` as it's either novel to `social_demo` or was removed from `product` since it was initially duplicated.

The records cache (from `related_models` module) isn't properly linked to the reactivity of `posmodel`. As a result, some expected rerenderings aren't executed. An example of this is the `OrderTab`. When a new floating order is created the `OrderTab` rerenders listing the new order. However, when that empty order is deleted, the corresponding tab item isn't removed in the list. That is because the `OrderTab`'s render method isn't properly subscribed to the changes in `models['pos.order']`. The render subscription doesn't exist because `models['pos.order'].readAll` isn't reading on the reactive version of the `records` cache. That is because `get orderedRecords` is pointing to the non-reactive version of `records`. `get records` exists in `models` and that's what we should use to properly link it to the reactivity and that `OrderTab` properly subscribes `models['pos.order']`. In this PR we are making sure that the methods of `models` (return value of `createCRUD`) is properly using the `reactive` version of the `records` cache. We then pass that version to the CRUD methods to ensure continuity of reactivity in the records. We also need to make changes in the `OrderTab` template, converting `floating-order-container` from `id` to `class` since it's being used for each order. We should not have multiple instances of an id in the html. TASK-ID: 4369054