Daily updates from Odoo
Wednesday, February 12, 2025
21 changes
4 changes
Resolved issues and error corrections
This fixes an error that occurred when loading sample appraisal data in databases without demo data. The sample data now matches the updated goal manager setup, so users can try the Appraisal app without hitting a crash.
Original PR description
STEPS TO REPRODUCE: 1- Install a database without demo data 2- Go on Appraisal 3- Click on Load sample data You will have a traceback Reason: Before a goal only has one manager, and now multiples managers can be linked to a goal (introduced by this commit : https://github.com/odoo/enterprise/commit/dd90f66a536539413a3886e0f165d30d8f79ef89 ) task-4563359
This update fixes two minor issues in the Czech reports module: a duplicated read-only setting in an accounting screen and inconsistent internal logic for a reporting code calculation. These changes help keep accounting report behavior cleaner and more consistent without changing user workflows.
Original PR description
This commit fixes the following issues of the module l10n_cz_reports: 1. The readonly attribute was duplicated in account move view. 2. The account_move_line supplies code compute method was different from that of the transaction code (although the logic is identical). X-original-commit: https://github.com/odoo-dev/enterprise/commit/71279841b3db65f577804e0749b594aea386d67b
This fixes visual issues in Odoo Knowledge where comment icons could jump or stick in the wrong place when using Chrome zoom, and calendar event text could overlap. Calendar embeds also resize more reliably when the sidebar or article width changes, making Knowledge pages easier to read and use.
Original PR description
In Knowledge, on Chrome, zooming at certain levels will cause the comment icon to flail around the editor and lock in unwanted places. (This behavior was not reproductible in Firefox.) To circumvent this, the margin calculations for the purposes of calculating the comment icon horizontal location are now done manually. -- In Knowledge, the calendar event text descriptions and properties tend to overlap with each other, and the header. This commit makes it so that event descriptions and properties do not overlap. task-4558391
This fixes two small visual inconsistencies on the Helpdesk website form page. The form title now matches the standard front-end title styling, and the card background no longer depends on a theme color that may vary by customer setup.
Original PR description
This PR fixes two minor color issues on the `website_helpdesk` form page. Prior to this PR, the title of the form was using a `text-muted`, which is inconsistent with the other titles design across the front-end. There was also an issue about the card using a `bg-secondary` utility class to tweak its design, which doesn't work anymore with the new secondary color we introduced in 13d4d48 and highlight the fact we can't rely on utility classes for this scenario since we don't know what color will be set by the user. | Master | This PR | |--------|--------| |  |  | task-4498381
17 changes
Resolved issues and error corrections
This fixes an issue where point-of-sale record updates could lose original field values when the matching record was not already available locally. It helps keep POS and self-order data consistent during synchronization, reducing the chance of incomplete or incorrect records.
Original PR description
Before this commit, when updating a record, the raw value of the field was lost if the specific record was not found locally.
The HTML editor now treats dragging selected content like cutting and pasting it. This prevents unwanted duplicate text or elements, making document editing more predictable for users.
Original PR description
**Current behavior before PR:** When dragging and dropping selected content excluding images in the editor, the content was duplicated at the new location, leaving the original content intact. **Desired behavior after PR is merged:** Dragging and dropping selected content now removes it from its original location and places it in the new location, effectively functioning as a cut and paste operation. task:4369910
Pasting text with line breaks into the HTML editor now correctly updates the cursor selection after the content is inserted. This prevents an error that could interrupt users when replacing selected text with multi-line pasted content.
Original PR description
**Problem**: When pasting text containing line breaks (`\n`), after executing `this.dependencies.dom.insert(modifiedTextFragment);`, the selection collapses to the end of the newly inserted content. At this step, `selection` becomes stale and needs to be updated. **Solution**: Update the selection after inserting the text node. **Steps to Reproduce**: 1. Copy text content with line breaks (`\n`). 2. Select some text in the editor. 3. Paste the copied text. 4. Traceback. opw-4481257 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
Recruitment surveys now show completed participant responses in the Participations section. This helps recruiters review candidate survey results without missing records due to an incorrect filter.
Original PR description
**Issue** Recruitment-type surveys do not appear in the Participations section, even when participants have completed the survey. Steps to Reproduce: 1. Install hr_recruitment_survey module 2. Open…
**Issue** Recruitment-type surveys do not appear in the Participations section, even when participants have completed the survey. Steps to Reproduce: 1. Install hr_recruitment_survey module 2. Open the Surveys app. 3. Create a new survey or open an existing one. 4. Set the survey type to Recruitment. 5. Click on the Participations smart button. Expected behavior: Participants who completed the survey should be listed. Actual behavior: No participants are shown. **Root Cause** https://github.com/odoo/odoo/blob/de935a1b3ad96e24b5fd1bd317c73c12e9b3a08f/addons/survey/models/survey_survey.py#L1090-L1096 Once the smart button is clicked, the action variable is populated through the following record https://github.com/odoo/odoo/blob/de935a1b3ad96e24b5fd1bd317c73c12e9b3a08f/addons/survey/views/survey_user_views.xml#L153-L168 The record includes a domain filter that restricts the displayed results to specific survey types. Since "recruitment" is not listed among the accepted survey types, it fails the check and is excluded from the results. **Fix** Overriding the action_survey_user_input action template in XML to extend the domain was impractical because it replaced the existing domain rather than extending it. This prevented seamless integration with other modules, limiting flexibility. Instead, we opted to extend the domain within the action's returned values, ensuring better modularity and maintainability. opw-4516112 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures combo meal options are loaded even when their individual products are not assigned to the visible POS categories. Customers using QR self-ordering can now select affected combos without the menu crashing or showing missing choices.
Original PR description
Currently, if the products included in a combo don't have a pos category included in the pos config, they will not load. Selecting the combo product could result in crashing the page or just no…
Currently, if the products included in a combo don't have a pos category included in the pos config, they will not load. Selecting the combo product could result in crashing the page or just no selection showing. Steps to reproduce: ------------------- * Change restaurant to **QR menu + Ordering** * Go to products, select the Burger combo * Delete Drinks choice * For the burger choice, delete one of the product and modify the other by removing the pos category. * Open mobile menu * Select the burger combo > Observation: Page crashes Why the fix: ------------ https://github.com/odoo/odoo/blob/2ab0b63b7042293f8229b29bcea478d37d4c3df5/addons/pos_self_order/static/src/app/pages/combo_page/combo_page.js#L141-L148 The page would crash because `c.product_id` is undefined so you cannot access `attribute_line_ids`. `product_id` is undefined because the products were not loaded. Currently only the products that have a pos category defined in `iface_available_categ_ids` are loaded. We now load all the products included in the loaded combo. Similarly as done in the shop: https://github.com/odoo/odoo/blob/2ab0b63b7042293f8229b29bcea478d37d4c3df5/addons/point_of_sale/models/pos_config.py#L797-L798 opw-4516061
The online store now checks available stock before letting shoppers add products when in-store pickup is enabled. This prevents customers from ordering items that cannot actually be fulfilled, reducing failed orders and support issues.
Original PR description
Before the user could add a product when in-store delivery method was activated even if the product was not available for any delivery. Now, we will check free quantities before adding. opw-4479075
Simplified invoices sent to TicketBAI will no longer include recipient details unless the customer has a VAT/NIF number. This prevents validation errors that could block Spanish electronic invoice reporting for affected sales.
Original PR description
Since Odoo 18.0, the recipient is always included when sending a simplified invoice. While this is allowed by TicketBAI, it is only valid if the partner has a VAT number (NIF). Steps to reproduce: - Install the l10n_es_edi_tbai module and setup an ES company - Create a simplified invoice with the partner "Simplified Invoice Partner (ES)" - Send the invoice to TicketBAI The following error will be returned: "B4_1000002: Todos los registros incluidos en la petición son incorrectos." The Fix: For simplified invoices, this fix ensures that the recipient is only included in the XML if the partner has a VAT/NIF. If not, the recipient is omitted to avoid TicketBAI validation errors. opw-4525875 opw-4522938 opw-4553030
Reordering rules now keep a consistent default planning horizon instead of resetting when users leave the replenishment dashboard. This makes automatic replenishment more reliable and reduces repeated manual setup for inventory teams.
Original PR description
Backport of odoo/odoo#190450 Odoo 18 introduced a new horizon concept for reordering rules, but it lacks persistence and usability. The horizon value resets when navigating away from the…
Backport of odoo/odoo#190450 Odoo 18 introduced a new horizon concept for reordering rules, but it lacks persistence and usability. The horizon value resets when navigating away from the replenishment dashboard, affecting both usability and automatic reordering functionality: 1. Users must manually reset the horizon after consulting other views, disrupting workflows. 2. The horizon fails as a replacement for the old `visibility_days` parameter, rendering automatic reordering unreliable. This commit reintroduces the `stock.visibility_days` system parameter: - Acts as the default horizon when no custom value is set or after navigating away. - Ensures consistency for automatic reordering rules in the back-end. - Defaults to 0, aligning with prior behavior. This approach prevents arbitrary horizon changes by users from persisting globally, while maintaining a manageable and reliable workflow for all use cases. Task 4346100 --- 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
Document folders can again create follow-up activities when files are uploaded through an email alias, as long as an activity type and user are configured. This restores a used workflow while simplifying the setup by removing the need for an extra checkbox, and also fixes related display issues in document shortcuts and list views.
Original PR description
Turns out it's used. To minimize the UI space, setting an activity type and user should be enough to "activate" the feature, no need to check a box. Note: removing the creation of activity at upload, this flow is supposed to work on alias upload (setting unavailable without alias defined). Task-4551761 Note: Only the last commit is really part of this PR
Fixed a timing issue where components added from the shopfloor catalog could be saved but not appear immediately if the catalog was closed too quickly. The shopfloor now waits for catalog changes to finish before refreshing, improving reliability for manufacturing users and automated workflows.
Original PR description
### Issue: Since 18.0, the catalog is used in certain actions of the shopfloor However, if you leave the catalog fast enough after your last change (something of the order of ~0.5 sec in localhost),…
### Issue: Since 18.0, the catalog is used in certain actions of the shopfloor However, if you leave the catalog fast enough after your last change (something of the order of ~0.5 sec in localhost), you can trigger a reload of the shopfloor records and call a `web_read` prior to the update of these records. ### Note: This is easily reproducible by hand in localhost and should worsen if you have server delay. In addition, it makes it impossible to write a proper tour involving the catalog in the shopfloor. ### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > wheel > Add component - Add a component to be consumed in that operation - Close the catalog fast (using ESC for instance) #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on the shopfloor. ### Cause of the issue: When a product is added from the catalog it triggers an rpc call to update the data's of the MO (notably creating a new raw move): https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/product/static/src/product_catalog/kanban_record.js#L62-L69 https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/mrp/models/mrp_production.py#L2898-L2901 On the other hand, closing the product catalog will reload the mrp record that started the action that opened the catalog: https://github.com/odoo/enterprise/blob/c1346dd2279bf3882b47b260b8d03ef9651ffaf1/mrp_workorder/static/src/mrp_display/dialog/mrp_menu_dialog.js#L41-L45 Since this reload is currently not waiting for the update of the record the associated `web_read` might be called prior to the last update of the record and the newly created raw moves might not be displayed. ### Fix: We use the props option of the action opening the catalog to transfer a callback to reload the records when all the record update promisses are resolved. #### To be more precise: The `ProductCatalogKanbanController` component contains a list of promises (initially empty): `catalogKanbanUpdates` aswell as an optional callback props `onCatalogUpdated`. This list is going to be populated each time that a `ProductCatalogKanbanRecord` make a quantity update (used stock moves on the mrp.production). To populate this array of promises a method is defined in the controller: `pushCatalogKanbanUpdate`. This method needs to be called by the `KanbanRecords` an hence is transported using xpath from the `ProductCatalogKanbanController` to the `ProductCatalogKanbanRecord` via the `ProductCatalogKanbanRenderer`. Once the controller is detroyed (and hence each kanban record that had to update a quantity started its call) if a callback was given to the props of the Kanban controller we wait for all the update promises to be resolved and we call that call back. opw-4199156 ---
Publishing a job to Monster.com could fail when a salary range was included, preventing recruiters from posting roles. This update corrects the handling of the salary time unit so the job posting process can complete successfully.
Original PR description
When the user tries to publish a job position on the job board monster, a traceback will appear. Steps to reproduce the error: - Install ``hr_recruitment_integration_monster`` module - Go to Recruitment > Applications > By Job Positions > Click on the dropdown menu of any job position > Configuration (Make sure that the job position is published on the website) - Add Salary Range > Publish on Job Board > Job Board: Monster.com > Post Traceback: ``` AttributeError: 'int' object has no attribute 'monster_id' ``` https://github.com/odoo/enterprise/blob/245a38f320db56fd22d946471f626adf6cfeb397/hr_recruitment_integration_monster/wizard/hr_recruitment_post.py#L130-L146 Here, ``monster_time_unit`` is integer, it does not have ``monster_id`` attribute. sentry-6027416420
The UAE payroll setup no longer automatically links newly installed leave types to the default company. This prevents multi-company users from losing access to those leave types when the default company is not based in the UAE.
Original PR description
When installing the module, do not assign new leave type to the default company, as in multi-company context that default company may not be a UAE based company, preventing users to see/select those new leave types. This commit force no company when creating those new leave types. opw-4353549
This update corrects how AEC files are prepared for Chilean electronic factoring. The file is now decoded properly before being sent, helping avoid submission errors and improving reliability for affected accounting workflows.
Original PR description
Before this PR: AEC file is sent encoded as base64. After this PR: we decode the file properly
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