Tuesday, May 20, 2025
7 changes
3 changes
Resolved issues and error corrections
The AI agent configuration page now gives the title and subtitle enough space to display properly. This prevents important agent information from being cut off, making the page easier to read and use.
Original PR description
This PR fixes an issue about the title and subtitle of an AI agent being cut on the configuration form view. Prior to this PR, the layout was using a regular div, which badly computed the size of the inner content, which resulted in a cut text due to the lack of a `flex-grow-1` class, as we do in other form views. To handle the issue, we simply add the missing class to the layout. task-4793748 | saas-18.3 | This PR | |--------|--------| |  |  |
Planning Gantt shift labels now hide allocated hours when the shift is already allocated at 100%. This prevents redundant information from appearing in schedule blocks, making planning views easier to read for users.
Original PR description
Before this commit, when a shift has an allocated hours set, the allocated hours is displayed in the gantt pill even if the allocated percentage is at 100%. This commit adds the allocated_percentage field in the gantt view to make sure the allocated percentage is fetched to be able to know if the slot has an allocated percentage set to 100% if yes then the allocated hours will not be displayed in the display name of the gantt pill. This commit also reviews a bit the code to display or not the allocated hours to only call the parent method when it is really needed. task-4801407
This fixes an issue that caused an error when users tried to load sample manufacturing data after enabling work orders. The change restores missing demo data information so the shop floor setup works as expected.
Original PR description
This error occurs when trying to load sample data from the shop floor module with work orders enabled. It appears that a parameter has been removed by mistake on this quality check documents commit:https://github.com/odoo/enterprise/commit/7ebd2ec679cc7649baece6b21a1d78c399d8995b#diff-aed5e2f84ffd8889ad58e6b2a1ba2991b24d055d1fb8bb9d4803ac89bb16894aL236 **Steps to reproduce this error:** * Install MRP (No need of demo data) * `Settings>Enable work order` * Open shop floor and `Load samples` `Value error:not enough values to unpack (expected 6, got 5)` **Solution:** * Adding the missing title parameter in the demo data. **Sentry-6607676446**
1 change
Resolved issues and error corrections
This update prevents Belgian tax report forms from failing when no partner is selected, improving reliability during form edits. It also removes a temporary rental workaround because the underlying issue has been fixed elsewhere, keeping rental behavior aligned with the main system.
Original PR description
In the community PR, onchange has been fixed to legitimely recompute more fields. Fix _compute_partner_address() to manage empty partner_id (issue discovered by the new test of all Form). #### [REV] sale_renting: revert of 01149e9fd550bcf8c3f18ba90339cf4bd659e247 Revert since the root cause has been solved in the community version. (keep the test for now but update the comment). https://github.com/odoo/odoo/pull/209587
3 changes
Resolved issues and error corrections
Restaurant receipt wording is now translated as complete phrases instead of separate fragments, making translations more natural across languages. This also avoids confusion between restaurant tables and spreadsheet tables in translated text.
Original PR description
Do not use t-out/t-esc to build human-readable content. This is basically the same as string concatenation. This commit wraps the entire string in a gettext call to prevent it from being split into several non-reorderable translations. As a lucky side effect, it also creates a separate translation for the word "table" (as in restaurant tables) which won't overlap with the translation for spreadsheet tables. opw-4754410
This fix makes an internal stock landed costs test use a reliable ordering method so automated checks no longer fail unpredictably. It helps keep the development pipeline stable without changing business functionality or user workflows.
Original PR description
Issue ===== In the test `test_stock_landed_costs_lots`, there is this `assertRecordValues`: ```python self.assertRecordValues(lc.stock_valuation_layer_ids.sorted('product_id'), [ {'lot_id':…
Issue
=====
In the test `test_stock_landed_costs_lots`, there is this `assertRecordValues`:
```python
self.assertRecordValues(lc.stock_valuation_layer_ids.sorted('product_id'), [
{'lot_id': lot_product_b[0].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[0].id, 'quantity': 0, 'value': 1.5},
{'lot_id': lot_product_b[1].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[1].id, 'quantity': 0, 'value': 1.5},
{'lot_id': lot_product_a[0].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[0].id, 'quantity': 0, 'value': 1},
{'lot_id': lot_product_a[1].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[1].id, 'quantity': 0, 'value': 1},
{'lot_id': lot_product_a[2].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[2].id, 'quantity': 0, 'value': 1},
])
```
This issue is sometime the records order is not the expected one.
Cause of the issue
==================
By doing `recordset.sorted('product_id')`, it will sort the records by compare their `product_id` records, using the python built-in `sorted`. The built-in `sorted` function simply check if record A is lower than record B, using the < operation. But in Odoo, comparing two recordsets is equal than comparing their ids as a `set`:
```python
def __lt__(self, other):
try:
if self._name == other._name:
return set(self._ids) < set(other._ids)
except AttributeError:
pass
return NotImplemented
```
In python, the comparaison between two sets compares is a set is a subset of the other one, which means than:
```python
{1} < {2} # is false
{1} < {2, 1} # is true
```
So, comparing SVLs by their product won't sort them by their product's id. If we want to do that, we have to explicitly do it by passing a function as the `sorted` `key` argument.
For more information, see:
-https://docs.python.org/3/library/functions.html#sorted -https://docs.python.org/3/reference/expressions.html#comparisons
runbot-build-error: 99086DIN5008 formatted reports now show partner and shipping addresses with the same font size. This fixes a visual inconsistency in printed quotations, making customer-facing documents look more polished and uniform.
Original PR description
### Steps to reproduce: - Install "l10n_din5008" - In Settings > Layout, select DIN5008 as the report layout - Create a quotation, print it - The address of the partner and the sipping address have different font size ### Cause: Since this [commit](https://github.com/odoo/odoo/commit/92e4c3cb3bec0b3d5537a50fd441a22fa6509ed1) the partner address is a span which is applied a [`font-size: 0.8em;`](https://github.com/odoo/odoo/blob/f77b40bba0c92a9a225eb7ade694e79cb804f7bf/addons/l10n_din5008/static/src/scss/report_din5008.scss#L51). But not the shipping address. ### Solution: Remove the restriction of `span` to apply the font-size. This way all text in address should have the same font-size. Before:  After:  opw-4725169