Wednesday, February 12, 2025
15 changes · 18.0
Enhancements to existing features
Checks and canceled payments are now easier to distinguish in list views through clearer color treatment. This helps users quickly spot active handed checks while visually de-emphasizing voided, debited, or canceled records, reducing confusion during payment review.
Original PR description
Description of the issue/feature this PR addresses: This PR aims to add better visibility to own checks. Made voided and debited checks appear gray on tree view in order to make handed checks more…
Description of the issue/feature this PR addresses: This PR aims to add better visibility to own checks. Made voided and debited checks appear gray on tree view in order to make handed checks more eye-catching. I also refactor the labels on search views for own and third party checks to make them consistent with "Issue state" field. Lastly, I refactored account.payment tree view to make decoration-muted work well when "state" is "Canceled". Current behavior before PR: - l10n_latam_check Debited checks records appear black on tree view, and "Issue state" tag on green. Voided checks records appear gray on tree view as well as "Issue state" tag.  - account "Canceled" payments records appear black on tree view. Desired behavior after PR is merged: - l10n_latam_check Voided or debited checks records will appear with gray color on tree view, as well as "Issue state" tag. Handed checks records will appear blue on tree view, as well as "Issue state" tag.  - account "Canceled" payments records appear gray on tree view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale orders now automatically remove lines with a quantity of zero when the customer pays. This keeps receipts and order records cleaner while still preserving the removed quantity details in the order history for traceability.
Original PR description
- Now when paying an order we want to remove empty order lines (lines with qty=0).
- In order to keep the deleted quantity of the order line in the order chatter, we add the deleted quantity in the message (Previously we would get the message `{product_name}: Ordered quantity: {qty}->0` when paying and order with a line quantity set to 0).
task-id: 4485551
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prResolved 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
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
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