Wednesday, February 12, 2025
4 changes · 18.0
Resolved issues and error corrections
This fix prevents an error when users update the duration of a manufacturing work order that depends on another unfinished work order. It improves reliability in manufacturing planning by allowing the change to be saved without interruption.
Original PR description
Steps to recreate the issue: - Create a MO with the SEC-ASSEM bill of materials and confirm it - Unblock the Drill 1 workcenter - Start working on the packing work order - Modify the duration on the long time assembly work order - Save Current behavior before PR: Traceback Desired behavior after PR is merged: No traceback When a work order depends on a another workorder, setting the duration on the depending work order will trigger a call to `_plan_workorder`, but all workorders don't necessarily have a leave_id as their depending on a non-finished work order. The `min` and `max` functions can't work with False values, triggering the traceback. task-id: 4282910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a website test flow that expected an extra menu button to always be available. The change prevents failures in single-app installations where there are fewer menus and that button may not appear.
Original PR description
The PR: https://github.com/odoo/odoo/pull/197115 introduced some errors in the "single app" installation. The step assumed that the "extra menu" button is always there to click it. It work on enterprise builds as there is so many menus that the "extra menu" button will always appear. But it's not the case in the single app tests. To solve this issue, we partially revert a step to its original code rb-116096
Installing the Monster recruitment integration no longer fails when all employment types have previously been removed. This prevents setup interruptions and lets businesses enable the recruitment connector even after customizing employment type records.
Original PR description
Currently a ``ParseError`` is arising when the user installs the ``hr_recruitment_integration_monster`` module after deleting all types from Employment Types.
Steps to reproduce:
---
- Install ``hr_contract`` module
- Open ``Employment Types`` and delete all types
- Now try to install the ``hr_recruitment_integration_monster`` module.
Traceback:
---
```
ParseError: while parsing /home/odoo/src/enterprise/18.0/hr_recruitment_integration_monster/data/hr_contract_type_data.xml:8, somewhere inside <record id="hr.contract_type_temporary" model="hr.contract.type">
<field name="monster_id">2</field>
</record>
```
This commit solves the above issue by using ``noupdate="1"`` and ``forcecreate="False"`` to bypass record creation if it violates checks.
sentry-5731062091Fixed an issue where manually created variants of financial reports could initialize the same report options twice. This prevents duplicate action buttons, such as the Send button, and keeps report screens clearer for users.
Original PR description
To reproduce: (Note that this needs to be donne before https://github.com/odoo/enterprise/commit/03fd8fa9ce59f3b052ba112612ee288cd44f045a ; you can easily replicate by indenting the add of the "Send"…
To reproduce: (Note that this needs to be donne before https://github.com/odoo/enterprise/commit/03fd8fa9ce59f3b052ba112612ee288cd44f045a ; you can easily replicate by indenting the add of the "Send" button one more level to the left, so that the button is always added, as it used to be) 1) Duplicate the Partner Ledger 2) Set the original Partner Ledger as the root report of the duplicate 3) Open the Partner Ledger, and select the duplicate in the variant selector ===> The "Send" button is displayed twice on top of the report. This is due to the fact the custom handler is first called by the report itself (since the duplicate kept the same handler as the root Partner Ledger), then by the call to super() made in the _custom_options_initializer. In the case of the Partner Ledger, we could have removed that super call (since it's a root report), but we prefer a more generic and cleaner fix that just makes sure we don't reinitialize the same custom options if we notice the handler is the same. opw-4506968