Friday, April 25, 2025
4 changes · saas-18.1
Resolved issues and error corrections
This fixes a problem where certain database validation errors could turn into a technical crash before a user was fully signed in. Instead, Odoo now returns the intended, understandable error message so users and support teams can see what actually went wrong.
Original PR description
During `retrying` method we still don't have any uid on the current env (the authentification is inside the `func` -> `_serve_ir_http`). If there is an Integrity Error coming from the…
During `retrying` method we still don't have any uid on the
current env (the authentification is inside the `func` ->
`_serve_ir_http`). If there is an Integrity Error coming from the
method/controller called, the error is catch by `retrying` and call
`_sql_error_to_message` leading to a traceback:
```
...
File "/home/odoo/src/odoo/saas-18.2/odoo/http.py", line 2016, in _transactioning
return service_model.retrying(func, env=self.env)
File "/home/odoo/src/odoo/saas-18.2/odoo/service/model.py", line 186, in retrying
message = env._("The operation cannot be completed: %s", model._sql_error_to_message(exc))
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 2916, in _sql_error_to_message
cons_rec = self.env['ir.model.constraint'].search_fetch([
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 1390, in search_fetch
query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 4993, in _search
self.browse().check_access('read')
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 3719, in check_access
if not self.env.su and (result := self._check_access(operation)):
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 3752, in _check_access
if not Access.check(self._name, operation, raise_exception=False):
File "/home/odoo/src/odoo/saas-18.2/odoo/addons/base/models/ir_model.py", line 2051, in check
has_access = model in self._get_allowed_models(mode)
File "decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "/home/odoo/src/odoo/saas-18.2/odoo/tools/cache.py", line 125, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/home/odoo/src/odoo/saas-18.2/odoo/addons/base/models/ir_model.py", line 2023, in _get_allowed_models
group_ids = self.env.user._get_group_ids()
File "decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "/home/odoo/src/odoo/saas-18.2/odoo/tools/cache.py", line 125, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/home/odoo/src/odoo/saas-18.2/odoo/addons/base/models/res_users.py", line 1026, in _get_group_ids
self.ensure_one()
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 5497, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
It actually hides the legit constraint message error.
Fix it by adding a sudo() to the constraint search, since whatever the
user (public or not), the error message should be accessible and
returned.This fix prevents Point of Sale sample store data from failing to load if a related product category was previously deleted. It helps restaurant and bakery POS setups continue loading correctly instead of stopping with an error.
Original PR description
Currently a `ParseError` arises when we try to load the store data after deleting the `Food` Category in Invoicing. Steps to reproduce: --- - Install `Invoicing` application (without demo data). -…
Currently a `ParseError` arises when we try to load the store data after deleting the `Food` Category in Invoicing.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Categories > Delete `Food`
- Now in POS try to load `Restaurant` and `Bar`
Traceback:
---
```
ValueError: External ID not found in the system: point_of_sale.product_category_food
ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/pos_restaurant/data/scenarios/restaurant_data.xml:56, somewhere inside <record model="product.product" id="pos_food_bacon">
<field name="name">Bacon Burger</field>
<field name="list_price">15.50</field>
<field name="standard_price">13.95</field>
<field name="description_sale">200G Irish Black Angus beef, caramelized onions with paprika, chopped iceberg salad, red onions, grilled bacon, tomato sauce, pickles, barbecue sauce</field>
<field name="type">consu</field>
<field name="weight">0.01</field>
<field name="uom_id" ref="uom.product_uom_unit"/>
<field name="image_1920" type="base64" file="pos_restaurant/static/img/th-burger.png"/>
<field name="available_in_pos" eval="True"/>
<field name="categ_id" ref="point_of_sale.product_category_food"/>
<field name="pos_categ_ids" eval="[(6, 0, [ref('food')])]"/>
</record>
```
The error occurs because the user deleted the category, and then tried to load the store data, that references the missing product category.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-6314696040
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe stock barcode module now has a stronger automated test for GS1 lot searches. This helps ensure the system correctly returns no lot when a search should not find one, reducing the risk of incorrect inventory handling.
Original PR description
Updated test case `test_searching_lot_gs1`. This commit updates the test_searching_lot_gs1 test case to include an assertion ensuring that no lot is returned while searching. Related Community PR: https://github.com/odoo/odoo/pull/206268 Sentry:6544673924 OPW: 4725056
Sign requests now only auto-fill fields when the field is configured for the same business document type. This prevents values from unrelated records, such as manufacturing orders, being inserted into signature documents by mistake.
Original PR description
Before this commit, when a sign field type was attached to a model, it could be automatically completed if the sign.request was linked to another model. Steps to reproduce: 1) Create a sign field type: text, model: sale.order, field: reference 2) Add this field in a sign.template. 3) Open a manufacturing order (mrp.production), create a sign request for it 4) sign the MO, the reference field is automatically filled. The method getting the value to fill, don't check the model. As a reuslt if the same field exists, it will be filled. taskid: 4672517