Daily updates from Odoo
Wednesday, January 28, 2026
105 changes
32 changes
Enhancements to existing features
This update allows tooltips in the Odoo application to now include newlines, improving readability and making them easier to understand for users. This change was driven by a need to better organize information within tooltips, enhancing the overall user experience. It's a minor improvement that addresses a usability concern.
Original PR description
We need to have a new line in tooltips. related task-5367117 Allow to have a new line in tooltips strings --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
A previous bug prevented users from adding attachments when sending emails to large groups of contacts (501+). This update corrects a technical issue related to how the system handles large contact lists, ensuring attachments can now be successfully added during mass email campaigns. This improves the reliability of the email sending process.
Original PR description
Steps to reproduce: 1. Install 'contact' 2. Create 501+ contacts (e.g. by duplicating existing one) 3. Select all contacts in list view and click Send Email (from Action menu) 4. Try to add an attachment Issue: - A traceback is raised in the mail composer: `SyntaxError: Unexpected end of JSON input` Cause: `res_ids` is not set on the composer when more than 500 records are selected. This is expected, as the compute method `_compute_res_ids()` does not write `res_ids` when the number of active_ids exceeds 500 (to avoid storing large payloads on the field). Because of this, the code trying to JSON.parse(res_ids) fails. see: https://github.com/odoo/odoo/blob/abc8417413faf598fb83106de4328571d71888aa/addons/mail/wizard/mail_compose_message.py#L400 Solution: - Fallback to context.active_ids when res_ids is not available opw-5351374 Forward-Port-Of: odoo/odoo#238311
This update resolves an issue where contract templates were incorrectly preventing users from creating them. The system has been adjusted to ignore filing status requirements for contract templates, ensuring they can be created without error. This change aligns with the correct process of determining filing status based on the employee, not the template itself.
Original PR description
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is…
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is empty..." A constraint ensures an l10n_us_state_filing_status is set on `hr.version`. The field is used by the salary rules. This field used to be on `hr.employee` and was moved to `hr.version` [1]. There's two types of `hr.version` records: templates without employee_id and actual contract versions linked to an employee. We don't want to evaluate the constraint for the templates, the only way to set a filing status is through the employee so it will always raise. This is functionally correct as well, contract templates should not have a hardcoded filing status, this should be determined per employee. The constraint will now only raise when loading a contract template on the employee or editing the field through the employee. [1] odoo/enterprise#83136 opw-5458566 Forward-Port-Of: odoo/enterprise#105575 Forward-Port-Of: odoo/enterprise#104990
This update fixes a naming inconsistency in the Spanish reporting module (l10n_es_reports). During a recent system update, the names of some reporting wizards were incorrectly updated. This change ensures consistent and accurate reporting functionality for Spanish businesses.
Original PR description
Problem --------- During the FWP moving the dictionnary definition from in-class to standalone, the naming of the wizards was wrongly updated. Solution --------- Change the naming from `l10n_es_reports_2025` to `l10n_es_reports`. error-237536
This update fixes a problem that occurred when installing new chart of accounts for Odoo's payroll system. Previously, creating a new payroll database with a specific chart of accounts (ZA) would trigger an error. This change ensures that the system correctly handles account deletions during installation, preventing this issue and improving stability.
Original PR description
When installing a chart of account, previous records are deleted to be replaced by the one of the installed chart. Since odoo/odoo@4400130eb32, we need to explicitly check for force_delete flag. Before this commit, creating a new payroll database with the ZA chart of account was raising this constraint. opw-5879978
A recent update to the ESG app within the core Odoo system increased the number of menu items being accessed. This commit adjusts a performance test to reflect this change, ensuring the system continues to load menus efficiently. This improves overall system responsiveness.
Original PR description
Due to changes in the related enterprise PR where we add new menu items in the ESG app, the number of queries has increased. This commit increases the query count in the test. task-5172829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where editing a delivery order after adding a product (without selecting one) would cause an error. The fix ensures the system handles empty product selections gracefully, preventing disruptions to order management. This improves the reliability of delivery order modifications.
Original PR description
Currently, an error occurs when a user edits a delivery order after adding a product line, but without selecting any product. **Steps to Reproduce:** 1. Install the **Stock** module. 2. Create a new Delivery Order and click **"Mark as To-do"**. 3. Click **"Add a product"**, but do not select any product. 4. Change the 'Scheduled Date' or 'Delivery Address'. Video Ref: [LINK](https://drive.google.com/file/d/1v_MZ0nfNa_lzTjV1gChchCw4g_aKzP-8/view?usp=drive_link) **Error:** `ValueError - Expected singleton: uom.uom()` **Cause:** When a stock move is created without a product, `move.product_id` remains empty, which leads to the singleton error during product availability computation. **Fix:** This commit adds a check before performing the UOM comparison. sentry-7173331233 Forward-Port-Of: odoo/odoo#243561
This update resolves an issue where duplicate order warnings appeared when upselling subscriptions in version 19.0. The fix excludes upsell quotes from the duplicate order check, ensuring that these quotes are created and opened without unnecessary warnings. This improves the user experience and prevents potential disruptions to the sales process.
Original PR description
Version: - 19.0 Steps to reproduce: 1. Create a subscription. 2. Set a customer reference 3. Confirm the subscription and create an invoice. 4. Upsell the subscription to generate a upsell quote (state '7_upsell'). Issue: A duplicate order warning is displayed when upsell a subscription Solution: Exclude upsell quotes (`subscription_state == '7_upsell'`) from the duplicate order check in `_fetch_duplicate_orders`. This prevents incorrect warnings when creating or opening upsell quotes. taskid-5438769 Forward-Port-Of: odoo/enterprise#102795
This update resolves a test failure in the web_studio module caused by a missing dependency. The test was incorrectly reporting an error because a related module, `account_edi`, was installed but not properly accounted for in the test setup. This change ensures the test accurately reflects the installed modules and avoids false failures.
Original PR description
`RELATED_MODELS_TO_EXCLUDE` contains `account.edi.document`, which is installed by `account_edi`, which is neither in the `needed_modules` set nor a dependency of any of them. Therefore the test can fail because `account_edi` is not installed even though every module in the set is. Improve the test by checking that the models or fields we're checking for actually belong to the modules we've listed. Also add the missing module in the list. Forward-Port-Of: odoo/enterprise#105504 Forward-Port-Of: odoo/enterprise#104879
This update resolves a test failure related to how contract end dates are handled in the Enterprise Payroll module. The fix ensures contracts automatically end after two years, aligning with current payroll practices. This change improves the reliability of our payroll testing and reporting.
Original PR description
### Cause: Apparently the contract ends automatically after a period if `contract_date_end == False` ### Solution: Set `contract_end_date` to ` Date.today() + relativedelta(years=2)` like in `hr_payroll/tests/common.py` runbot-237945 runbot-237894 Forward-Port-Of: odoo/enterprise#104627
This update fixes a small visual issue in the canned responses displayed within the Odoo interface. Previously, canned responses were cropped, making the descriptions difficult to read. Now, canned responses take up the full available width, ensuring the descriptions are fully visible and easy to understand.
Original PR description
Canned responses have an arbitrary small width limit in the navigable list panel. Due to this restriction, the description of the canned response is barely readable. This commit makes it take the whole available width. task-5873810 || Before | After| | ------------- | ------------- | -----| |Discuss|<img width="832" height="318" alt="image" src="https://github.com/user-attachments/assets/4671ea44-7687-442a-a14c-1c56c3851930" /> |<img width="839" height="331" alt="image" src="https://github.com/user-attachments/assets/7fde9d8c-9682-43e5-b1b4-9a303331f445" />| |Chat window|<img width="453" height="437" alt="image" src="https://github.com/user-attachments/assets/c2b255f6-2552-4739-9a5d-d22e8c257a07" />|<img width="410" height="610" alt="image" src="https://github.com/user-attachments/assets/b8097f1b-04f4-4a3e-b11f-021bfcb9398e" />| Forward-Port-Of: odoo/odoo#245929
This update resolves a technical issue preventing accurate tracking of timesheet events. The fix corrects a categorization error that was disrupting event generation, ensuring timesheet data is properly recorded. This improves the reliability of timesheet reporting.
Original PR description
Fake events generation was broken since we categorized events by category instead of watcher in https://github.com/odoo/enterprise/pull/105263. Also something else that we shall not mention
This update fixes an issue where the 'Mark as Paid' button wasn't consistently appearing during the pay run tour. The fix ensures the button is always visible and accessible, streamlining the user experience. A related adjustment prevents the option button from being triggered multiple times, improving stability.
Original PR description
The Mark as Paid button doesn't appear in the view right away, but has been moved in the options (the ellipses button). It's enough to just add a click action on the ellipses so that the Mark as Paid button is visible and the tour can continue. Also, the button is secondary and not primary so we have removed that class altogether, since there is only one button with Mark as Paid text. This fix was already present for the hr_payroll_account_iso20022 but is now needed for the hr_payroll_account module too. However, since the iso20022 version doesn't depend on hr_payroll_account, we modify its override to only open the option if they are not already opened. This is to avoid the fact that when the override happens, the options ubtton is triggered twice, closing it and hiding the Mark as Paid button Runbot Error: 234625
This update resolves an issue in Odoo's Web Studio where incorrectly configured related fields could cause warnings and errors. The change ensures that related fields are only created when linked to searchable fields, preventing these technical problems and improving stability for business users.
Original PR description
Before this commit studio allowed to make a related field with a non-searchable field (ie standard computed fields) in the the chain. This triggered a warning at creation (at fields.py:resolve_depends) and errors when using in a business setting. After this commit, the filter to build the relational field is modified to take into account this. opw-5436158 Forward-Port-Of: odoo/enterprise#105668 Forward-Port-Of: odoo/enterprise#105607
This update fixes an issue where applicant stage changes weren't correctly displayed in the Odoo recruitment module's chatter. The fix ensures that stage change messages show the correct 'Stage changed' label and uses the accurate stage name ('Qualification') instead of 'Initial Qualification'.
Original PR description
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't…
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't show "Stage changed" label 4. Review mail.tracking.value records for applicant stage changes 5. Observe incorrect stage name "Initial Qualification" instead of "Qualification" Bug cause: mail.message records for applicant stage changes were missing the subtype_id field, which defaults to an incorrect subtype (mt_note instead of mt_applicant_stage_changed). This caused the messages to be treated as internal notes rather than stage change notifications. Additionally, mail.tracking.value records used "Initial Qualification" as the old_value_char or new_value_char, which doesn't match the actual stage name defined in hr_recruitment module. The correct stage name is simply "Qualification" (ref: hr_recruitment.stage_job1). Solution: - Add subtype_id field with reference to hr_recruitment.mt_applicant_stage_changed to all mail.message records that track applicant stage transitions - This ensures stage change events are properly identified and displayed in chatter with the correct "Stage changed" label - Update old_value_char and new_value_char fields in mail.tracking.value records to use the correct stage name "Qualification" instead of "Initial Qualification" - Ensures consistency with actual stage names and proper display in applicant chatter history Affected records: 20 mail.message records in hr_recruitment_reports_demo.xml Task Id:5454691 Forward-Port-Of: odoo/enterprise#105278
A bug was causing the Point of Sale system to unexpectedly close and open a new tab when the 'this device' button was clicked. This was due to an error in how the system generated the URL for redirection. This fix ensures that the correct URL is used, preventing unnecessary tab openings and improving the user experience.
Original PR description
Step to reproduce: - start pos - from top-right menu, click on display icon - a dialog will appear, click on "this device" button Observation: - current session will be closed and open in new tab Cause: - Incorrect url formed for redirection which, as a fallback loads currrent pos - base url is `undefined`, as we try to get it from `pos.session`, which now is attribute of `pos.config`. https://github.com/odoo/odoo/blob/06ddce00115c906a4d8396387dd3332482145d7f/addons/point_of_sale/models/pos_config.py#L288 opw-5502812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244494
This update resolves an issue where outdated sign requests were incorrectly sending notifications to the wrong users due to missing email addresses. The fix ensures that sign requests are only sent to users with matching email addresses, improving the accuracy and reliability of the sign request process. This prevents unnecessary notifications and streamlines document signing.
Original PR description
This commits fix the problem where the `signer_email` field of old sign items don't have a value defined then showed up as "next documents to be signed" for other users, even when the email doesn't match. task-5487349 Forward-Port-Of: odoo/enterprise#104755
This update resolves a visual discrepancy in email layouts when using Columns blocks. Previously, received emails displayed incorrectly formatted columns with extra spacing. The fix ensures the email's layout accurately reflects the editor preview, improving the overall email marketing experience.
Original PR description
Problem: When adding a Columns block, the received email layout differs from the editor preview and appears broken. Cause: The iframe used for processing the editable content did not have its size properly set before conversion. This leads to incorrect calculations during the conversion to inline styles, resulting in extra spacing and misaligned columns. Solution: Force the iframe to the correct size before running the conversion. This ensures that the inline-styled email matches the editor layout. Steps to reproduce: - Add a Columns block in email marketing. - Send the email. - Observe that the received email shows columns with extra space and misalignment. opw-5490792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245867
This update corrects a visual glitch that appeared on mobile devices when scrolling back to the top of the website. Specifically, a horizontal scrollbar briefly appeared due to a timing issue with the header's styling. The fix synchronizes header styles to prevent this momentary display problem, ensuring a consistent and professional user experience.
Original PR description
There was an horizontal scrollbar that would appear for a short time after scrolling back to the top of the page. This would occur because the header would still have the "transform" property but the class "o_header_affixed" was already removed. To fix the issue, the header transform is now applied using dynamicContent, to synchronize the style and class correctly. This requires the standard header to have "transition: none" applied after it is scrolled since "translate(0, -100%)" would trigger an animation when hiding the header. task-5155878 Forward-Port-Of: odoo/odoo#245091 Forward-Port-Of: odoo/odoo#241980
This update resolves an issue preventing non-administrator users from accessing the Stock Valuation report. The fix ensures the report can be opened without errors by securing the data access process, improving usability for all users. This change was made to enhance the overall user experience within the Odoo system.
Original PR description
## Issue before this commit: When opening the Stock Valuation report as a non-admin user, an access error occurred. The report attempted to read `tracking_value_ids` from `mail.message`. Since `mail.tracking.value` is restricted to system administrator users, this caused the stock report to fail for regular users. ## Steps to Reproduce: - Install the stock_account module. - Log in as a non-admin user. - Open Accounting -> Review -> Inventory Valuation Report. ## Cause of the Issue: The system reads `mail.tracking.value` to get the last stock valuation closing date. Without a trusted context, this access fails for non-admin users. ## With This Commit: Tracking values are now accessed in a trusted context, allowing the stock report to open for non-admin users without changing the valuation logic. Steps To Reporduce: [Video Link](https://drive.google.com/file/d/1bFmLgadD7Z3PEntVQVM8flTAWCMDJXxK/view?usp=drive_link) opw-5483352 Forward-Port-Of: odoo/odoo#244697
This update fixes a minor usability issue in the chat window by adding a hover effect to the fold and close buttons. Previously, these buttons lacked visual feedback, making them harder to click. The change improves button visibility and responsiveness.
Original PR description
These 2 buttons had no hover effect, compared to other buttons like the "start a call". The lack of hover effect makes it harder to click on these buttons. This commit reduces slightly the opacity of button when not hovered, so that they are highlighted on hover from change to 100% opacity. The reduced opacity also makes these buttons slightly less visible, which is actually an improvement. Before / After (hover on "x") <img width="383" height="48" alt="Screenshot 2026-01-26 at 17 25 10" src="https://github.com/user-attachments/assets/7d4578cc-fcde-44b6-91e9-e0956e789c54" /> <img width="380" height="49" alt="Screenshot 2026-01-26 at 17 14 40" src="https://github.com/user-attachments/assets/e8f3690e-4202-4afd-85a5-d1459b13946e" /> Forward-Port-Of: odoo/odoo#245773
This update resolves a technical issue that could cause errors when processing Peruvian VAT (PE) invoices within the Odoo Enterprise system. The fix ensures that the system handles cases where invoice data is missing, preventing a traceback and maintaining smooth invoice processing. This improves the reliability of the PE VAT module.
Original PR description
Forward-Port-Of: odoo/enterprise#105610 Forward-Port-Of: odoo/enterprise#105462
This update resolves a technical issue where performing an undo operation after inserting a code block would generate a traceback. Now, undoing actions correctly removes inserted content without errors, ensuring a smoother user experience for the HTML editor.
Original PR description
Current behavior before PR: - Inserting a /code block, then adding text above it and performing an undo would trigger a traceback. Desired behavior after PR is merged: - Undo now correctly removes the inserted character without causing any traceback. task-5445873 Forward-Port-Of: odoo/odoo#241839
This update corrects a previous change that prevented the system from automatically selecting a default shipping method when available. It now allows the system to choose a suitable carrier from the list of options, ensuring a smoother and more efficient order fulfillment process. This resolves an issue where users were restricted from utilizing the system's intelligent shipping suggestions.
Original PR description
https://github.com/odoo/odoo/pull/203955, by wanting to ensure no unallowed carrier was set as default, removed the possibility to set one. This PR puts back the possibility of having a default shipping method if part of the available carriers. opw-5263540 Forward-Port-Of: odoo/odoo#242867
This update resolves an issue where Time-Off Responsibles lacked the ability to refuse fully accepted leaves, resulting in an access error. The fix ensures they can correctly unlink related calendar entries, aligning with existing approval workflows and improving usability.
Original PR description
****Behavior:**** When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs. This…
****Behavior:**** When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs. This occurs because approving a leave creates a resource.calendar.leave linked to the hr.leave, and when refusing it, the system will try to unlink it. https://github.com/odoo/odoo/blob/72e8a29dd0edb0ca3d464142ce869f38f96c730a/addons/hr_holidays/models/hr_leave.py#L896-L901 According to access rules of r.calendar.leaves, Time-off Responsibles are not allowed any access for entries of other employees. Approving them doesn't cause an error because the create operation uses sudo(), assuming that the user must have had valid rights to access the function. This is not the case for the unlink. **Solution:** This fix checks wether the user has write access to the related hr.leave record, then uses sudo(). The idea is that if they are allowed to modify the state of the leave, they can refuse the leave, and therefore should be able to go through the following operations. This is in a similar fashion as the behavior for approving the leaves. ****Steps to Reproduce:**** - Create a Leave Type that requires validation from a manager, and assign one to an employee. - Remove any access rights to Time-Off for the user, but leave Time off Responsible checked. - Assign the user as time-off responsible for the employee - Log in as the user and approve the leave - When refusing the leave, you should get an access error. opw-5178783 Forward-Port-Of: odoo/odoo#243405 Forward-Port-Of: odoo/odoo#238205
This update resolves an error that occurred when a repair order's scheduled date was updated without a product assigned to a move line. The issue stemmed from incorrect calculations related to unit of measure, preventing the update from completing successfully. This ensures repair orders can be scheduled reliably.
Original PR description
An error occurs when the product is not set in the repair move line, and the Scheduled Date is being updated. **Steps to Reproduce:** - Install the **Repairs** module. - Create a new **Repair Orders**. - Add a product and confirm the repair. - In the **Parts** tab, **add a new line** and change the **demanded** quantity without selecting a product. - Update the **Scheduled Date**. **Error:** `AssertionError: precision_rounding must be positive, got 0.0` `ValueError: Expected singleton: uom.uom()` (v19.0) When the move line has no `product_id`, its Unit of Measure (uom_id) is also empty. Updating the scheduled date triggers a computation, which leads to the error. Forward-Port-Of: odoo/odoo#246011 Forward-Port-Of: odoo/odoo#244179
This update fixes an issue where the tour pointer was appearing in unwanted locations, like above dialogs, creating a confusing user experience. Now, the pointer only appears when the trigger element (like the 'My Profile' menu) is actively visible, ensuring a cleaner and more intuitive tour experience.
Original PR description
POC for task-5490670 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-pr Forward-Port-Of: odoo/odoo#245949 Forward-Port-Of: odoo/odoo#243852
This update resolves an issue where the Gantt chart's date range controls would overlap with other UI elements, particularly on smaller screens. The fix adjusts the scale selector to prevent this overlap, ensuring a cleaner and more usable Gantt chart experience. This improves usability for all users.
Original PR description
Steps to reproduce ================== - Switch to dutch - Emulate an iPhone SE viewport in the browser settings - Open a project - Switch to the gantt view - Use a custom date range -> The gantt controls are displayed on top due to the daterange format being to long Note ==== The fix is in the ViewScaleSelector component, but only the gantt view uses a custom scale opw-5340869 Forward-Port-Of: odoo/odoo#245552
A recent update to the hr_expense_stripe_demo module caused a problem when users attempted to connect a demo account. This fix corrects an error in how system parameters were updated, ensuring the demo account setup now functions correctly. This resolves a minor disruption for users exploring the demo.
Original PR description
Forward port wasn't done right, and the way to get the system parameter changed. To reproduce: - Install hr_expense_stripe_demo - confirm agreeing to the terms - Save - click on "Connect (Demo)"
This update improves the reliability of the IoT Box upgrade process. Previously, a failed upgrade could cause the box to repeatedly attempt the upgrade on subsequent starts. Now, the system checks if the upgrade command was successful before renaming the branch, preventing unnecessary and potentially disruptive restarts.
Original PR description
If the upgrade fails, the branch name can already be set to the target one. Making the IoT Box not upgrading on next start. We now check `git` method return value, to ensure the command succeeded, before renaming the branch. Forward-Port-Of: odoo/odoo#245875
A recent issue prevented the Point of Sale appointment tour from working correctly when tests were run close to midnight. The fix ensures appointments are scheduled and displayed accurately, regardless of the time of day. This improves the reliability of the appointment booking process for users.
Original PR description
The `test_pos_restaurant_appointment_tour_basic` test was failing when run late in the day. The test creates an appointment 30 minutes in the future and expects a corresponding label to appear underneath the table in the POS floor plan. However, if the test is executed near midnight (e.g. 23:45 UTC), the appointment is scheduled for the following day. Since the Point of Sale frontend only displays appointments for the current day, it filters the booking out, causing the tour to timeout while waiting for the label. runbot-232601 Forward-Port-Of: odoo/enterprise#105738
This update fixes a technical issue preventing users without WhatsApp access from viewing WhatsApp conversations in Discuss. The problem stemmed from a configuration error that caused access issues when retrieving message status. This ensures all users can access and view WhatsApp conversations.
Original PR description
Steps to reproduce: - Open any WhatsApp conversation in Discuss. - post a message. - Invite an internal user who does not have WhatsApp access (e.g., Marc Demo). - Log in as the invited user. - Open the invited WhatsApp conversation. => it shows `An error occured while fetching messages` Since [1], this happens because `sudo()` was accidentally removed while storing `whatsappStatus` on messages, leading to an access error. This commit fixes the issue. [1]: https://github.com/odoo/enterprise/pull/100237 Task-5794783
2 changes
Resolved issues and error corrections
This update hides live chat commands (like `/help`) from website visitors and guests. Previously, these commands were visible, potentially leading to confusion or misuse. This change enhances website security and the user experience for standard visitors.
Original PR description
**Before PR:** channel commands like `/help ` or `/leave` and more are visible to visitors or guest even it is not functional for them. **After PR:** all commands are now hidden from visitors/guests. task-4548666 Forward-Port-Of: odoo/enterprise#105133 Forward-Port-Of: odoo/enterprise#82963
This update ensures that sign templates created in languages other than English automatically use the correct document name. Previously, templates defaulted to 'New Template' regardless of the selected language. This fix corrects a translation issue, guaranteeing accurate template naming across all supported languages.
Original PR description
## Steps to reproduce: 1. Upload a new PDF document to be signed. 2. Select it in the Documents app to sign it. 3. Check the name of the sign template created. ## Issue: When creating signature templates in languages other than English, the template name would stay as "New Template" instead of updating to the actual document name. This happened because the code was comparing the template name against a translated version of "New Template", but the template was initially created with the English default value. Since "New Template" ≠ "Nueva Plantilla" (Spanish), the comparison failed and the name never got updated. The fix ensures we always compare against the original English default value, so the template name gets properly updated to match the document name regardless of the user's language. Related commit: 4254542 opw-4980747 Forward-Port-Of: odoo/enterprise#92682
9 changes
Resolved issues and error corrections
This update resolves an issue that prevented users from scheduling repairs when a product wasn't assigned to a repair move line. The fix addresses a calculation error triggered by updating the scheduled date, ensuring repairs can be properly scheduled without causing system failures. This improves the reliability of the Repairs module.
Original PR description
An error occurs when the product is not set in the repair move line, and the Scheduled Date is being updated. **Steps to Reproduce:** - Install the **Repairs** module. - Create a new **Repair Orders**. - Add a product and confirm the repair. - In the **Parts** tab, **add a new line** and change the **demanded** quantity without selecting a product. - Update the **Scheduled Date**. **Error:** `AssertionError: precision_rounding must be positive, got 0.0` `ValueError: Expected singleton: uom.uom()` (v19.0) When the move line has no `product_id`, its Unit of Measure (uom_id) is also empty. Updating the scheduled date triggers a computation, which leads to the error. Forward-Port-Of: odoo/odoo#244179
This update increases the width of the barcode printed on customer receipts generated through the Point of Sale (POS) loyalty program. Previously, the barcode was too narrow, causing scanning difficulties. This change ensures receipts can be reliably scanned, improving the customer experience and order processing efficiency.
Original PR description
Step to reproduce; - install pos_loyalty - create a loyalty program of type "next order coupon" with minimum spend of 1$. - open pos and settle a order, see receipt. Issue: - currently bar-code is too narrow, making it difficult for to be scanned Fix: - increase the width of barcode, so it can be easily scanned. <table> <tr> <td> <b>Before</b> </td> <td> <b>After</b> </td> </tr> <tr> <td> <img width="441" height="557" alt="image" src="https://github.com/user-attachments/assets/658ee8dd-a4d5-4b2d-a12d-5ebd8db48c9d" /> </td> <td> <img width="447" height="569" alt="image" src="https://github.com/user-attachments/assets/59a2282b-8da7-4576-9dd1-edd787cd9314" /> </td> </tr> </table> opw-5363916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242469
This update fixes an issue where the Odoo tour pointer was appearing in unwanted locations, like above dialogs. Now, the pointer only shows if it's directly linked to the element being interacted with, creating a cleaner and more focused user experience. This improves the overall usability of the onboarding tour.
Original PR description
POC for task-5490670 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-pr Forward-Port-Of: odoo/odoo#245838 Forward-Port-Of: odoo/odoo#243852
A recent issue with the Point of Sale appointment tour was resolved. The test environment was scheduling appointments for the next day, causing the tour to fail when run near midnight. This fix ensures the tour functions correctly by addressing the scheduling discrepancy.
Original PR description
The `test_pos_restaurant_appointment_tour_basic` test was failing when run late in the day. The test creates an appointment 30 minutes in the future and expects a corresponding label to appear underneath the table in the POS floor plan. However, if the test is executed near midnight (e.g. 23:45 UTC), the appointment is scheduled for the following day. Since the Point of Sale frontend only displays appointments for the current day, it filters the booking out, causing the tour to timeout while waiting for the label. runbot-232601
This update fixes an issue where the IoT Box was incorrectly downloading standard drivers, potentially causing conflicts and reintroducing previous problems. To allow custom driver development, a checkbox was added, but this created a risk of overwriting existing drivers. Now, the system avoids downloading standard drivers to ensure stability and prevent issues.
Original PR description
The stable IoT Box uses drivers from git repository: it doesn't download them from the database as it used to do. However, sh/on premise clients might want to develop custom drivers that the IoT Box would download. For that, they have to enable a checkbox on the IoT homepage, making the IoT Box download handlers as before. The issue is it will also download standard drivers that are already present on the IoT Box: on newer databases it would simply overwrite them, but on older ones, it would duplicate as names might have changed. Also, it would introduce issues back that were already fixed. To avoid this, we avoid adding drivers from standard modules to the downloaded archive, to prevent issues with the main ones. Forward-Port-Of: odoo/enterprise#105634 Forward-Port-Of: odoo/enterprise#105531
This update fixes an issue where new CRM contacts created via quick create didn't automatically inherit the address of the associated company. The fix ensures that company address information is correctly applied during contact creation, improving data accuracy and consistency within the CRM.
Original PR description
**Steps to reproduce:** - Install Sales/CRM apps - Go to CRM app - Create new opportunity card - Set a company (`commercial_partner_id`) - Create a new contact using `quick_create` - The new contact is linked to the company but it doesn't inherit the company address **Issue:** Kanban quick create of crm app was modified to allow a company field, which is used as `default_parent_id` when creating a new partner from the card. This properly set the partner `parent_id` and `commercial_partner_id` but without applying the logic of `_fields_sync()` which also added the address (only for quick_create). **Fix:** Use `_add_missing_default_values` to check if a default value was given for `parent_id` in `_fields_sync()`. related: https://github.com/odoo/odoo/commit/a6c3ebc21c066ab4d5711f535ca5fc858e6485b0 opw-4932114
This update resolves an issue where Odoo couldn't connect to printers with overly long device names. The fix automatically shortens these names to comply with CUPS's 127-character limit, ensuring consistent printer functionality. This prevents connection errors and improves printer availability.
Original PR description
CUPS has a limit on printer names of 127 characters, which means that if a device has a very long device URI, it can exceed this limit and cause an error when we try to add it to CUPS:
```
Failed to add printer 'dnssdPhotosmart%207520%20series%20%40%20Guillaume%E2%80%99s%20MacBook%20Air%20(2)_ipp_tcplocalcups?96d0de60-096c-3d08-5e2d-893393e10c2b'
Traceback (most recent call last):
File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/printer_interface_L.py", line 242, in set_up_printer_in_cups
self.conn.addPrinter(name=device['identifier'], device=device['url'], **ppdname_argument)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cups.IPPError: (1024, 'client-error-bad-request')
```
We fix this error by truncating the identifier to 127 characters maximum.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245910This update fixes a visual issue where the Gantt chart's date range controls would overlap with the user interface, particularly when using custom date ranges in Dutch on smaller screens. The fix ensures the Gantt controls are displayed correctly, improving usability and preventing a confusing user experience. This resolves a reported problem impacting the Gantt chart functionality.
Original PR description
Steps to reproduce ================== - Switch to dutch - Emulate an iPhone SE viewport in the browser settings - Open a project - Switch to the gantt view - Use a custom date range -> The gantt controls are displayed on top due to the daterange format being to long Note ==== The fix is in the ViewScaleSelector component, but only the gantt view uses a custom scale opw-5340869 Forward-Port-Of: odoo/odoo#245552
This update fixes a technical issue in the stock orderpoint module that prevented accurate filtering of records based on the current orderpoint. The fix ensures that the system correctly restricts records to the current orderpoint, improving data accuracy and efficiency. This resolves a silent error that could have impacted orderpoint management.
Original PR description
Description of the issue/feature this PR addresses:
This PR fixes an incorrect domain construction when restricting records to the current recordset.
The existing code attempted to combine domains using expression.AND() but did not apply the result, and referenced an invalid domain field.
Current behavior before PR:
- expression.AND() was called without assigning its return value, so the combined domain was never applied.
- The domain condition used ('ids', 'in', self.ids), which is not a valid searchable field.
- As a result, the intended filtering by the current recordset was silently ignored.
Desired behavior after PR is merged:
- The domain is correctly rebuilt and assigned using expression.AND().
- The filter uses the valid field instead of ids
- Records are properly restricted to the current recordset
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#2427992 changes
Resolved issues and error corrections
This update resolves a problem that occurred when downloading journal audit reports with multiple companies selected. The issue was caused by duplicate sheet names in the XLSX file, which prevented the report from generating correctly. Now, the report header includes the company name and sheet names are unique, ensuring accurate and reliable downloads.
Original PR description
Before: When downloading the journal audit in XLSX format with multiple companies selected, each company could have journals with the same name (e.g., "Sales"). Since XLSX does not allow duplicate sheet names, this resulted in a traceback. After: Added the company name in the report header when multiple companies are selected. Ensured sheet name uniqueness by appending the journal ID to the journal name. task - 5097253
This update resolves an issue preventing the l10n_be_hr_payroll_fleet module from installing correctly when auto-installation is skipped. The fix ensures the module correctly relies on the hr_fleet module, preventing a missing field error during demo data creation. This ensures the module functions as intended.
Original PR description
Steps to reproduce: 1. Install l10n_be_hr_payroll_fleet with --skip-auto-install and demo data. 2. Traceback when creating demo data because driver_employee_id is missing on the model fleet.vehicle Cause: The module depends on fleet instead of hr_fleet so hr_fleet is only auto installed. Thus, when skipping auto install, the field driver_employee_id doesn't exist. Fix: Change the dependency from fleet to hr_fleet to force the module to be installed. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/237909 Task: 5875410 Forward-Port-Of: odoo/enterprise#105459
32 changes
Enhancements to existing features
This update enhances the clarity of settings related to group discussions within Odoo Enterprise. The PR has updated the help text across these settings to be more user-friendly and consistent. This improves the overall user experience and makes it easier for users to configure and manage their discussion groups.
Original PR description
**Description of the issue this PR addresses:** Revamp Discuss Settings **Desired behaviour after PR is merged:** This PR includes: - Updated help strings across settings for consistent and user-friendly phrasing. Community PR: https://github.com/odoo/odoo/pull/234674 part of - [5227387](https://www.odoo.com/odoo/project/1519/tasks/5227387) **Before**: <img width="556" height="524" alt="image" src="https://github.com/user-attachments/assets/7d853b01-68b7-4591-9492-604fc9c01ee2" /> **After**: <img width="554" height="500" alt="image" src="https://github.com/user-attachments/assets/11175f5c-3875-4e57-96fe-3ff81be86bec" />
This update replaces outdated inline links with proper button elements in the Odoo Enterprise interface. This change improves the user experience and aligns with best practices for interactive web elements, ensuring a more consistent and accessible design.
Original PR description
This commit is based on the community one which introduces the `.btn-link-inline` class to reproduce the inline styling of a `<a href="...">` tag as a variant of Bootstrap's `.btn.btn-link`. This allows to properly uses `<button>` element for interactive DOM elements instead of relying on a "hacky" and non-semantic `<a href="#">` (tl;dr: `<a>` HTML tag are for navigation, `<button>` are for interactivity). task-4380519
Resolved issues and error corrections
This update addresses a situation where quality checks wouldn't display a helpful message if no IoT device was connected. Now, a notification appears when a measure quality check doesn't have an associated IoT device, preventing confusion and ensuring users are aware of the setup.
Original PR description
We now display a notification when no device is configured for a measure quality check. opw-5409775 Forward-Port-Of: odoo/enterprise#105280 Forward-Port-Of: odoo/enterprise#105207
This update fixes an issue preventing bookings from being scheduled for the last hour of the day. The system was incorrectly interpreting the end of the day as an unavailable slot, blocking appointments. The fix adjusts a calculation to accurately recognize the 23:00-00:00 time range as available.
Original PR description
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to…
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to the website page of the appointment - Last slot is not showing (23:00-00:00) **Issue:** When computing the appointment slots of a resource using time range, the end of day is considered as an unavaibility resource slot with this interval in `_get_unavailable_intervals`: `i_start = 23:59:59.999999` `i_stop = 00:00` this conflicts with the given range (23:00-00:00) in `self._slot_availability_is_resource_available` It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)` is converted to `time.max` (23:59:59.999999) by: `day_to = datetime.combine(day, float_to_time(attendance.hour_to))` This introduces the microsecond unavaibility at the end of the day, which blocks the booking. (it's working properly for availability on users appointments) **Fix:** Changed the condition so that 23:59:59.999999 is considered as equal to 00:00. opw-5163892 Forward-Port-Of: odoo/enterprise#104927 Forward-Port-Of: odoo/enterprise#100853
This update resolves an issue where creating new contract templates in Odoo would trigger an error requiring a filing status. The change ensures contract templates don't need a filing status, aligning with the correct process of determining this setting per employee. This prevents unnecessary errors and simplifies template creation.
Original PR description
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is…
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is empty..." A constraint ensures an l10n_us_state_filing_status is set on `hr.version`. The field is used by the salary rules. This field used to be on `hr.employee` and was moved to `hr.version` [1]. There's two types of `hr.version` records: templates without employee_id and actual contract versions linked to an employee. We don't want to evaluate the constraint for the templates, the only way to set a filing status is through the employee so it will always raise. This is functionally correct as well, contract templates should not have a hardcoded filing status, this should be determined per employee. The constraint will now only raise when loading a contract template on the employee or editing the field through the employee. [1] odoo/enterprise#83136 opw-5458566 Forward-Port-Of: odoo/enterprise#105575 Forward-Port-Of: odoo/enterprise#104990
This change ensures the `account_number` field is consistently stored as a string, replacing the previous use of `False` when no account number is provided. The test case has been updated to account for this new behavior, improving the reliability of bank statement imports.
Original PR description
Due to the sanitization of the `account_number` field, the value is now consistently stored as a string. When no account number is available, an empty string (`''`) is used instead of `False`. The test case has been updated to reflect this behavior. Related: https://github.com/odoo/odoo/pull/245180 task-4872851
This update resolves minor UI issues related to the ActivityWatch download screen within the timesheet grid. It ensures a smoother and more reliable user experience when accessing and downloading timesheet data. This fix was previously deferred and is now implemented.
Original PR description
This PR fixes some minor stuff that didn't make it into the previous PR. Forward-Port-Of: odoo/enterprise#105300
This update resolves an issue where generating recruitment offers for new applicants in the 'Experienced Developer' role resulted in a multi-company error. The fix created a specific demo data record for the Belgian version of this job position, ensuring accurate offer generation within the US company setup. This resolves a reported bug impacting recruitment workflows.
Original PR description
## Issue: When we go to recruitment and try to generate offer for a new applicant for job position 'Experienced Developer', it shows multi company error. ## Steps to reproduce: 1. Go to recruitment for US company 2. Make a new applicant for the position 'Experienced Developer'. 3. Then generate offer for that applicant, multi company error will come. ## Cause: The job was inherited and given `contract_template_id`. ## Fix: Made a new record for Belgium Job position 'Experienced Devloper(BE)'. backport of task-4885755 task-5445798 Forward-Port-Of: odoo/enterprise#104186 Forward-Port-Of: odoo/enterprise#102991
This update resolves a misleading duplicate order warning that appeared when users upsell subscriptions in version 19.0. The change specifically excludes upsell quotes from the duplicate order check, ensuring that users aren't incorrectly alerted about potential duplicates. This improves the user experience and prevents unnecessary notifications.
Original PR description
Version: - 19.0 Steps to reproduce: 1. Create a subscription. 2. Set a customer reference 3. Confirm the subscription and create an invoice. 4. Upsell the subscription to generate a upsell quote (state '7_upsell'). Issue: A duplicate order warning is displayed when upsell a subscription Solution: Exclude upsell quotes (`subscription_state == '7_upsell'`) from the duplicate order check in `_fetch_duplicate_orders`. This prevents incorrect warnings when creating or opening upsell quotes. taskid-5438769 Forward-Port-Of: odoo/enterprise#102795
This update enhances the website editor by ensuring all images attached to a website are accessible, not just those automatically included. This prevents lost images from being unavailable to users, improving website content management and flexibility. It's a simple change to ensure a more complete and user-friendly experience.
Original PR description
Make it so that every image attachment is accessible in the website editor instead of just the ones present in the generated website. This is done to make sure that even if an image has been left over during the matching it is still accessible to the user.
This update resolves a test failure in the web_studio module caused by a dependency issue. The test incorrectly checked for models that weren't part of the installed modules, specifically due to the 'account_edi' module. The fix ensures the test accurately reflects the modules that are actually present, preventing false failures.
Original PR description
`RELATED_MODELS_TO_EXCLUDE` contains `account.edi.document`, which is installed by `account_edi`, which is neither in the `needed_modules` set nor a dependency of any of them. Therefore the test can fail because `account_edi` is not installed even though every module in the set is. Improve the test by checking that the models or fields we're checking for actually belong to the modules we've listed. Also add the missing module in the list. Forward-Port-Of: odoo/enterprise#105504 Forward-Port-Of: odoo/enterprise#104879
This update removes potentially problematic 'bare except' clauses in several Odoo modules. These clauses could inadvertently suppress critical errors like system exits, leading to instability. The change ensures more robust error handling and prevents unexpected application behavior.
Original PR description
Using bare except clauses is dangerous. They will also catch `BaseException` exceptions and may therefore suppress exceptions such as `SystemExit`, `KeyboardInterrupt`, etc. It is therefore good practice to explicitly mention the type of exception we want to catch. It is possible to use `except BaseException` if necessary. task-5008738
This update clarifies how SCSS variables are defined, ensuring only one of the !global or !default flags can be used. This change improves the consistency and predictability of our stylesheets, reducing potential styling issues. The update aligns with a recent Sass documentation change.
Original PR description
Variables will only allow a single !global or !default flag. Duplicate flags never had any additional effect, this just ensures that stylesheets are more consistent. Reference: https://sass-lang.com/documentation/breaking-changes/duplicate-var-flags/
This update resolves an issue in Odoo's Web Studio where incorrectly configured related fields could cause errors and warnings. The change ensures that related fields are only created when linked to searchable fields, preventing these technical problems and improving stability for business users. This resolves a previous vulnerability.
Original PR description
Before this commit studio allowed to make a related field with a non-searchable field (ie standard computed fields) in the the chain. This triggered a warning at creation (at fields.py:resolve_depends) and errors when using in a business setting. After this commit, the filter to build the relational field is modified to take into account this. opw-5436158 Forward-Port-Of: odoo/enterprise#105668 Forward-Port-Of: odoo/enterprise#105607
This update resolves a problem where the demo call tour wasn't functioning correctly with the standard demo data. The code was adjusted to ensure the correct contact and activity were selected during the tour, and the tour file was moved to the appropriate location for improved functionality. This ensures a smoother experience for users running the demo.
Original PR description
Make sure we select correct contact/activity when with demo data. Also move the tour to correct file. Forward-Port-Of: odoo/enterprise#105609
This update fixes an issue where applicant stage changes weren't correctly displayed in the recruitment reports demo data. The fix ensures that stage change messages appear with the correct 'Stage changed' label and uses the accurate 'Qualification' stage name, improving the clarity of applicant communication history.
Original PR description
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't…
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't show "Stage changed" label 4. Review mail.tracking.value records for applicant stage changes 5. Observe incorrect stage name "Initial Qualification" instead of "Qualification" Bug cause: mail.message records for applicant stage changes were missing the subtype_id field, which defaults to an incorrect subtype (mt_note instead of mt_applicant_stage_changed). This caused the messages to be treated as internal notes rather than stage change notifications. Additionally, mail.tracking.value records used "Initial Qualification" as the old_value_char or new_value_char, which doesn't match the actual stage name defined in hr_recruitment module. The correct stage name is simply "Qualification" (ref: hr_recruitment.stage_job1). Solution: - Add subtype_id field with reference to hr_recruitment.mt_applicant_stage_changed to all mail.message records that track applicant stage transitions - This ensures stage change events are properly identified and displayed in chatter with the correct "Stage changed" label - Update old_value_char and new_value_char fields in mail.tracking.value records to use the correct stage name "Qualification" instead of "Initial Qualification" - Ensures consistency with actual stage names and proper display in applicant chatter history Affected records: 20 mail.message records in hr_recruitment_reports_demo.xml Task Id:5454691 Forward-Port-Of: odoo/enterprise#105278
This update corrects a problem in the testing process for payroll documents. The original setup incorrectly assumed contract end dates were always false, leading to test failures. The fix ensures contract end dates are automatically set to two years from the contract start date, aligning with standard payroll practices.
Original PR description
### Cause: Apparently the contract ends automatically after a period if `contract_date_end == False` ### Solution: Set `contract_end_date` to ` Date.today() + relativedelta(years=2)` like in `hr_payroll/tests/common.py` runbot-237945 runbot-237894 Forward-Port-Of: odoo/enterprise#104627
This update fixes a problem that occurred when installing new chart of accounts. Previously, creating a new payroll database with a specific chart (ZA) would trigger an error. Now, the system correctly handles deleting and replacing old records during chart of account installations, ensuring smoother payroll database setup.
Original PR description
When installing a chart of account, previous records are deleted to be replaced by the one of the installed chart. Since odoo/odoo@4400130eb32, we need to explicitly check for force_delete flag. Before this commit, creating a new payroll database with the ZA chart of account was raising this constraint. opw-5879978 Forward-Port-Of: odoo/enterprise#105633
This update resolves an issue where outdated sign requests were incorrectly sending notifications to the wrong users due to missing email information. The fix ensures that sign requests are only sent to users with matching email addresses, improving the accuracy and reliability of the sign request process. This prevents unnecessary notifications and streamlines document signing.
Original PR description
This commits fix the problem where the `signer_email` field of old sign items don't have a value defined then showed up as "next documents to be signed" for other users, even when the email doesn't match. task-5487349 Forward-Port-Of: odoo/enterprise#104755
This update resolves a technical issue that could cause errors when generating Peruvian VAT (PE) documents. The fix ensures that the system handles cases where a required text field is missing, preventing a traceback and improving the reliability of the l10n_pe_edi module. This ensures accurate VAT reporting for our Peruvian customers.
Original PR description
Forward-Port-Of: odoo/enterprise#105610 Forward-Port-Of: odoo/enterprise#105462
This update addresses a technical adjustment to the checksum associated with the EU IoT Scale certification module. The underlying code for the scale component was modified to resolve a bug, necessitating a corresponding update to the checksum to maintain data integrity. This ensures accurate reporting and compliance.
Original PR description
Checksum needs to be updated as the code of the scale changed for a bugfix Cummunity PR: https://github.com/odoo/odoo/pull/245048 Forward-Port-Of: odoo/enterprise#105328
This update resolves a technical issue preventing the correct generation of events related to timesheets. The problem stemmed from an outdated categorization method, which has now been corrected. This ensures accurate tracking and reporting of timesheet activity.
Original PR description
Fake events generation was broken since we categorized events by category instead of watcher in https://github.com/odoo/enterprise/pull/105263. Also something else that we shall not mention Forward-Port-Of: odoo/enterprise#105724
A small correction was made to the names of reports used in the Spanish tax reporting module (l10n_es_reports). This change was a result of a recent system update and ensures the reports function correctly. The updated names are now consistent and accurate.
Original PR description
Problem --------- During the FWP moving the dictionnary definition from in-class to standalone, the naming of the wizards was wrongly updated. Solution --------- Change the naming from `l10n_es_reports_2025` to `l10n_es_reports`. error-237536 Forward-Port-Of: odoo/enterprise#105537
This update ensures accurate payslip data by adding a necessary 'sudo' call to access employee records. Previously, users lacked the correct permissions to update their own payroll information, leading to errors. This change corrects a technical issue and improves data reliability.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743 Forward-Port-Of: odoo/enterprise#105287
This update corrects a bug where the website generation process wasn't correctly setting a key value. The fix ensures that the website creation process is always enabled, preventing issues with new website setups. This improves the reliability of the website generation feature.
Original PR description
Missing the 'import_website' value, and since /startwebsite always creates a website it should always be True. Forward-Port-Of: odoo/enterprise#104894
Features or functions removed from Odoo
This update removes the 'New' button from the DIMONA Declaration List view in the odoo/enterprise module. This change simplifies the user interface and streamlines the process of creating DIMONA declarations, aligning with best practices for user experience. It addresses a minor UI inconsistency.
Original PR description
. Remove the New button on DIMONA Declaration List view task-5471873
This pull request removes a broken widget that was previously used for scanning product quantities during receiving. The recommended approach now utilizes the dedicated Barcode app, streamlining the process and eliminating a source of potential errors. This change improves efficiency and simplifies inventory management.
Original PR description
This widget has been broken for some time and can be removed. It was probably used when receiving products, allowing the operator to scan a product and its quantity, and to send a barcode command to move to the next line. In any case, the new recommended approach is to use the Barcode app.
Code cleanup and technical improvements
This update enhances the tracking tests within Odoo's enterprise modules, primarily by simplifying the checks for message content and adding new tests for appointment creation. The changes streamline test maintenance and ensure consistent tracking across various modules, improving the reliability of our email tracking functionality.
Original PR description
Use higher level helper for message content check, including tracking values. That way all checks are globally hidden in tools and it is easier to update / adapt tests if somehow modeling of tracking values change (yay). Add tests for creation, which currently generates no tracking message. Remove some duplicated / useless test or test parts when possible. Batch-ize some tests, just to cover tracking when creating or updating records in batch. Update a bit duration mixin tests, trying to make them easier to update if model has to change (yay). Task-5503121 Prepares Task-3645865
This update refactors stock tests to exclusively use local data, improving test stability and reducing reliance on external systems. This change simplifies testing and ensures consistent results, leading to more reliable stock management processes within Odoo.
This update refactors the WhatsApp channel model and removes a previous patch related to thread management. This change streamlines the handling of data within WhatsApp channels, improving the overall system's efficiency and organization. It's a technical update focused on internal improvements to the WhatsApp functionality.
Original PR description
This commit move the fields to discuss channel model and remove thread_model_patch.
This update removes the use of 'Cache view of fields' within several Odoo reports. This change is part of a broader effort to streamline Odoo's codebase and improve performance. While the reports continue to function as before, this refactoring prepares for future updates and optimizations.
Original PR description
https://github.com/odoo/odoo/pull/246069
This update reorganizes the structure of portal chatter code to better align with how it's used across Odoo. The changes clarify which parts of the chatter system are for website-only functionality versus those shared with project sharing, improving code organization and maintainability. This ensures smoother performance and future updates.
Original PR description
When the portal chatter conversion began, code was split into `core` and `frontend` folders for chatter in portal. `core` was intended for shared logic between website and project sharing while `frontend` was reserved for website only usage. With this commit, the boot service which is responsible for lazy loading the portal chatter in frontend is now located in the `frontend` folder. Those that are `portal specific` or common between `portal` and `project sharing` are located in the `portal` and `portal_project` folders respectively. Accordingly, `web_portal` subfolder has been renamed to `web_portal_project` to reflect the actual usage. The folder tree structure will look like this: In portal: ``` src/ |-- chatter/ | |-- frontend/ | |-- portal/ | |-- portal_project/ ``` In mail: ``` src/ |-- chatter/ | |-- web/ | |-- web_portal_project/ ``` [Comunity PR](https://github.com/odoo/odoo/pull/206284)
8 changes
New functionality added to Odoo
This update adds the necessary data to support Taiwan's VAT tax reporting requirements within Odoo. It includes the `account.return.type` model, enabling accurate reporting for businesses operating in Taiwan. This enhancement ensures compliance with local tax regulations.
Original PR description
This commit adds the necessary data records for the `account.return.type` model to support Taiwan VAT tax return. [Task-3371895](https://www.odoo.com/odoo/project.task/3371895)
Resolved issues and error corrections
This update resolves a test failure related to how contract end dates are handled in the Enterprise payroll module. The fix ensures that contract end dates are correctly calculated, preventing potential issues with automatic contract terminations. This improves the reliability of payroll calculations.
Original PR description
### Cause: Apparently the contract ends automatically after a period if `contract_date_end == False` ### Solution: Set `contract_end_date` to ` Date.today() + relativedelta(years=2)` like in `hr_payroll/tests/common.py` runbot-237945 runbot-237894 Forward-Port-Of: odoo/enterprise#104627
The 'Unnamed' breadcrumb issue in the Documents section, triggered when navigating from the systray, has been resolved. This ensures the correct folder name is always displayed, providing a consistent and accurate user experience for accessing documents.
Original PR description
When navigating to Documents through the activity menu (systray), the breadcrumb displays "Unnamed" instead of showing the proper folder name. Steps to reproduce: 1. Click the activity menu icon (clock) in the systray 2. Click on "Documents" in the activity dropdown 3. Observe the breadcrumb shows "Unnamed" The issue occurs because when navigating from the systray, the folder section's activeValueId is undefined. This causes getSelectedFolderAndParents() to call folderSection.values.get(undefined), which returns undefined instead of the default folder. Without a valid folder object, the breadcrumb computation has no context and falls back to displaying "Unnamed". The fix ensures that when activeValueId is undefined, we explicitly pass false to values.get(), which correctly retrieves the root/default folder. opw-5473442
This update resolves an issue in Odoo's Web Studio where it could incorrectly create related fields linked to non-searchable data. This prevented warnings and errors, particularly in business settings. The change ensures that related fields are built correctly, regardless of the field's searchability, improving stability and reliability.
Original PR description
Before this commit studio allowed to make a related field with a non-searchable field (ie standard computed fields) in the the chain. This triggered a warning at creation (at fields.py:resolve_depends) and errors when using in a business setting. After this commit, the filter to build the relational field is modified to take into account this. opw-5436158 Forward-Port-Of: odoo/enterprise#105668 Forward-Port-Of: odoo/enterprise#105607
This update fixes a technical issue that previously caused errors when adding transcription snippets to new records. The change ensures proper record identification and saving, preventing exceptions and improving the stability of the AI transcription feature. It also resolves a localized testing issue.
Original PR description
This PR fixes an issues where an exception would be thrown when inserting a transcription snippet on an unsaved record. It does so by removing the resId, resModel props and only retrieving them when actually needed (when opening the full composer to send the summary). Also whennever opening the full composer, we force a save on the record to ensure proper resId. The PR also adapts `voice_transcription_plugin.test.js` to add the locale to the date that is inserted when starting a transcription, avoiding local test fails. task-5788331
This update corrects a technical issue preventing accurate payslip updates by ensuring the necessary permissions are granted during data access. Specifically, a sudo call is now used to read slip IDs, resolving a previous error and improving payroll processing reliability. This ensures employees' payroll information is correctly updated.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743 Forward-Port-Of: odoo/enterprise#105287
This update ensures that sign templates are automatically named with the correct document name, regardless of the user's language setting. Previously, templates created in non-English languages would default to 'New Template' due to a comparison issue. This fix guarantees accurate template naming for all users.
Original PR description
## Steps to reproduce: 1. Upload a new PDF document to be signed. 2. Select it in the Documents app to sign it. 3. Check the name of the sign template created. ## Issue: When creating signature templates in languages other than English, the template name would stay as "New Template" instead of updating to the actual document name. This happened because the code was comparing the template name against a translated version of "New Template", but the template was initially created with the English default value. Since "New Template" ≠ "Nueva Plantilla" (Spanish), the comparison failed and the name never got updated. The fix ensures we always compare against the original English default value, so the template name gets properly updated to match the document name regardless of the user's language. Related commit: 4254542 opw-4980747 Forward-Port-Of: odoo/enterprise#92682
Code cleanup and technical improvements
This update streamlines the testing process for the Ar-EDI module by automatically verifying data against JSON files. Previously, tests required external modes, but now they run more reliably and easily adaptable with simple test tag adjustments. This improves the overall stability and maintainability of the Ar-EDI module.
Original PR description
This commit refactors the whole `l10n_ar_edi` test suite to use the new helpers, and made it possible for the test to (finally) be run without external mode. Now, when running these new tests, the test framework will by default assert the request data with their associated JSON file. When a change is made, new overwrites for the test files can be easily changed by just adding the `SAVE_JSON` test tag on the command to run the tests. task-4891206 Forward-Port-Of: odoo/enterprise#104886 Forward-Port-Of: odoo/enterprise#103370
10 changes
Resolved issues and error corrections
This change corrects a user experience issue where non-manager users would receive an error message when opening validated time off records. The fix prevents unnecessary updates to a field, ensuring the system functions correctly for all users. This improves usability and avoids frustrating errors.
Original PR description
Steps to reproduce: ------------------- 1. Install `l10n_in` and `l10n_in_hr_holidays` 2. Switch to an Indian company 3. Create a user and related employee without Time Off rights 4. Log in with the…
Steps to reproduce: ------------------- 1. Install `l10n_in` and `l10n_in_hr_holidays` 2. Switch to an Indian company 3. Create a user and related employee without Time Off rights 4. Log in with the new user and create a past time off 5. Approve the time off as an time off manager/admin 6. Open the validated time off record as the employee Issue: ------ Opening a validated time off raises the following UserError: ```python You must have manager rights to modify/validate a time off that already begun. ``` Cause: ------ The `_get_durations` method in `l10n_in_hr_holidays` was updating the `l10n_in_contains_sandwich_leaves` field every time it was executed. When a user opened a validated time off record, this triggered a `write()` operation. Since non-manager users are not allowed to write on already started validated leaves, this caused a [UserError](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/hr_holidays/models/hr_leave.py#L793-L798) The field `l10n_in_contains_sandwich_leaves` does not need to be updated when `l10n_in_is_sandwich_leave` is False. See [[1]](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L156-L157) & [[2]](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L62) And this [part of the code](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L160-L173) is responsible to update `l10n_in_contains_sandwich_leaves` value. **NOTE:** Opening future validated time off records as a non-manager user triggers `AccessError` as it is not allowed to update the validated time off record. Solution: --------- Ensure that `l10n_in_contains_sandwich_leaves` is updated only when `indian_leaves` is applicable. opw-5373055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue that prevented the stock orderpoint system from correctly filtering records based on the current item. The fix ensures that the system accurately restricts records to the current recordset, improving data accuracy and efficiency. This change was made to resolve a silent error impacting orderpoint management.
Original PR description
Description of the issue/feature this PR addresses:
This PR fixes an incorrect domain construction when restricting records to the current recordset.
The existing code attempted to combine domains using expression.AND() but did not apply the result, and referenced an invalid domain field.
Current behavior before PR:
- expression.AND() was called without assigning its return value, so the combined domain was never applied.
- The domain condition used ('ids', 'in', self.ids), which is not a valid searchable field.
- As a result, the intended filtering by the current recordset was silently ignored.
Desired behavior after PR is merged:
- The domain is correctly rebuilt and assigned using expression.AND().
- The filter uses the valid field instead of ids
- Records are properly restricted to the current recordset
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a problem preventing the l10n_be_hr_payroll_fleet module from installing correctly when automatic module installation is skipped. The fix ensures the necessary dependencies are included, preventing a data creation error during demo data setup. This ensures the module functions as intended.
Original PR description
Steps to reproduce: 1. Install l10n_be_hr_payroll_fleet with --skip-auto-install and demo data. 2. Traceback when creating demo data because driver_employee_id is missing on the model fleet.vehicle Cause: The module depends on fleet instead of hr_fleet so hr_fleet is only auto installed. Thus, when skipping auto install, the field driver_employee_id doesn't exist. Fix: Change the dependency from fleet to hr_fleet to force the module to be installed. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/237909 Task: 5875410 Forward-Port-Of: odoo/enterprise#105459
This update resolves a visual bug where columns in mass emails weren't rendering correctly when sent. The issue stemmed from a conflict between the email's styling and the Odoo website's CSS. The fix ensures consistent column alignment in received emails by standardizing color formatting.
Original PR description
**Steps to reproduce:** - Install Mass Mailing and Website apps - Create a new mailing - Add Columns block with different content size - In "Vert. Alignment" field > Select the "Stretch to Equal Height" option - Columns are properly aligned in Odoo - Save the record and send test mail - The columns are not aligned anymore in the received mail **Issue:** Inline styling breaks in mail engines due to `website.scss` file. The `color-mix` css function is used and cast as a `color()` functional notation in the columns `border-color`. The inline styling is then removed by the mail engine (with all siblings attributes) as it is not compatible with this notation. (e.g. `border-color: color(srgb 0.129412 0.145098 0.160784 / 0.15);`) The color normalization step doesn't take this into account as it only checks for rgb patterns. **Fix:** Overwrite the css with the color notation by a default value for mailing. opw-5225248
This update corrects a visual issue where the 'Sign and Pay' button remained enabled when the customer's name field was blank. The fix ensures the button is disabled when no name is entered, improving the user experience and preventing accidental order creation. This resolves a minor usability problem.
Original PR description
**Steps to produce:** - Install `sale_management` module. - `Create a SO > Click on Preview > Sign and Pay`. - Remove all text from the Full Name`. **Issue:** - The `Accept & Sign` button remains…
**Steps to produce:** - Install `sale_management` module. - `Create a SO > Click on Preview > Sign and Pay`. - Remove all text from the Full Name`. **Issue:** - The `Accept & Sign` button remains enabled even when the Full Name field is empty. **Root cause:** - At [1], When the `drawCurrentName` method is called, it retrieves text using `getCleanedName`. This method returns an empty string when no name is provided - Despite this, the code still generates an image and passes it to `printImage`, which keeps the button enabled. **Solution:** - If the cleaned name is empty or contains only spaces, do not generate image. - Instead, immediately clear the signature pad so the button remains disabled. [1]https://github.com/odoo/odoo/blob/9dedf75810bd6b7a92fe5bd279bf6bae98834750/addons/web/static/src/core/signature/name_and_signature.js#L103-L109 **Before:** <img width="400" height="400" alt="before" src="https://github.com/user-attachments/assets/5ebdf852-4cba-4e1d-9ae4-7373e4b8b91d" /> **After:** <img width="400" height="400" alt="after" src="https://github.com/user-attachments/assets/9280aa66-4f22-40d6-8a22-326cec24378d" /> **opw-5361890** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where event registration emails were incorrectly canceling invitations for contacts on an exclusion list. The change bypasses the filtering process for blacklisted emails, ensuring all registered attendees receive their invitations. This improves the reliability of event registration communications.
Original PR description
**Steps to reproduce:** - Install Events & Contacts apps - Open Contacts - Create a contact "BLACKLIST", email: `blacklist@example.com` - Create a contact "GOOD", email: `good@example.com` - Open Settings > Technical > Discuss > Email Blacklist - Create a record with email: `blacklist@example.com` - Open Events - Create an event - Go to the event attendees - Create attendees for both contacts - Open Settings > Technical > Email > Emails - Both email are listed but the blacklisted one is cancelled **Issue:** The composer created in `EventMailScheduler._send_mail` is using `_process_mail_values_state` to find the list of blacklisted records and applies it to filter the mail recipients, which prevents the event mailing from being processed correctly. **Fix:** `use_exclusion_list` is set to `false` on the composer to bypass its exclusion process. opw-5046491
This update fixes an issue where certain records didn't display correctly by default. The change ensures that other views are enabled when opening records, providing a smoother and more consistent user experience. This resolves a technical glitch that impacted how records were initially presented.
Original PR description
Records of some models may not want to be shown in their form view by default. See related ENT PR for documents. We re-export to avoid patching order issues. In particular, this makes sure that if we are in the webclient, the chat window is opened before executing the "real" open. Task-5386466
This update prevents documents from automatically opening in their form view when accessed through various channels like direct URLs, systray notifications, or the Discuss app. This change improves the user experience by giving users more control over how they access documents, addressing a previously uncovered access pattern.
Original PR description
Users do not want to access the form view of the document by default. This PR solves three cases for accessing documents.document records that were not covered before: * From the basic path pattern `odoo/x/documents.document/<id>` * From a systray notification "Open Form View" * when we are not yet in Documents * when we already are in Documents * From the Discuss app, on the record's thread Tests for most of these are included. Additionally, make sure the document is selected on accessing from `_get_access_action`. Task-5386466
This update ensures accurate payroll slip transmission for Swiss users by adding a necessary security layer (sudo) when accessing payroll data. Previously, users lacked the correct permissions to read their own payroll information, leading to errors. This fix resolves a technical issue identified by automated testing.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743 Forward-Port-Of: odoo/enterprise#105287
A test within the sale_pdf_quote_builder module was failing due to how it handled PDF files. This update replaces the test's invalid PDF data with a real, encrypted PDF, resolving the warnings and ensuring the test now passes. This improves the stability of the nightly builds.
Original PR description
The `test_wrong_pdf` test fails on runbot in the `Nightly build` when executed under `Distro Builds > Testing distro PureTrixie without requirements for config Parallel testing`. **Steps to…
The `test_wrong_pdf` test fails on runbot in the `Nightly build` when executed under `Distro Builds > Testing distro PureTrixie without requirements for config Parallel testing`. **Steps to reproduce:** - Install `sale_pdf_quote_builder` module. - Run `test_wrong_pdf` (Make sure `PyPDF==5.4.0` is installed). - Observe `PyPDF` warnings in the logs. **Warnings:** ``` WARNING server pypdf._reader:435 invalid pdf header: b'test' WARNING server pypdf._reader:435 EOF marker not found WARNING server pypdf._reader:435 EOF marker not found ``` **Root cause:** Odoo officially supports the PyPDF version defined in requirements.txt [1]. The test passes with `PyPDF2`, but `PyPDF` is stricter and emits warnings when parsing arbitrary byte content. Because the test uses raw bytes instead of a structurally valid (but unsupported or encrypted) PDF, PyPDF logs warnings. **Fix:** This commit updates the test to use a real encrypted PDF instead of raw bytes, similar to [2]. This commit fixes test failures caused by [3]. **Note:** Refer to [4] for generating the encrypted file. [1]: https://github.com/odoo/odoo/blob/a6af7df429f9cd3bfb60347e9b30cc48fb5bfaff/requirements.txt#L63-L65 [2]: https://github.com/odoo/odoo/blob/0499dbd8944b4002883afab5d3ed76d8e55dab9c/addons/mail/tests/discuss/test_discuss_attachment_controller.py#L63-L75 [3]: https://github.com/odoo/odoo/pull/230712 [4]: https://colab.research.google.com/drive/1UfWSKDluObEkKxCg6eX-nHoe04_FGrEq#scrollTo=A5hO11Eh1qvV runbot-238399
5 changes
Enhancements to existing features
This update optimizes the Excel export for the general ledger, reducing the file size and improving loading times. This change enhances the user experience by making large ledger reports faster to generate and download. The update focuses on streamlining data output without impacting the report's core functionality.
Resolved issues and error corrections
This update corrects a technical issue related to accessing payslip information within the Odoo Enterprise system. Specifically, a necessary security measure (sudo access) was added to ensure accurate data retrieval, preventing potential access problems when users update their own payroll records. This resolves a previous error and improves data reliability.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743
This update ensures that the employee's current location is consistently included in views, resolving an issue that previously caused incomplete data when creating many-to-many relationships in Studio. This fix improves data accuracy and reliability for employee location information, particularly within the HR module.
Original PR description
Before this commit, the feature at commit odoo/odoo@b3be3af61cc08d0dea84969425d24957f215b26f worked by chance, because in most cases ALL fields where returned in the get views, since most of the time the search view is asked for as well, hence yielding all fields in the model There were issues when triggering get_views from another place, namely studio when creating a many2many. After this commit, we make sure the current day location field's description is sent opw-5484321 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-pr
This update corrects an issue where the 'Today' filter in the Frontdesk module wasn't accurately displaying visitors due to timezone discrepancies. The fix converts all date/time comparisons to UTC, ensuring correct filtering regardless of the user's local timezone. This improves the reliability of visitor searches.
Original PR description
Steps to reproduce -------------------------- 1. Install Frontdesk 2. Go to Frontdesk → Visitors 3. Create a visitor with a check-in time before today 05:30 (local timezone: Asia/Kolkata) 4. Check visitors Issue: -------- The created record is not displayed because "today" filter used the user's local date to build a datetime range but failed to convert those boundaries to UTC before querying the database, leading to incorrect filtering in non-UTC time zones. Solution ------------- Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-5385995
This update fixes a minor issue where payment links were incorrectly displayed for expired subscriptions. Specifically, the 'Pay Now' anchor was only added when the advance payment section was visible, even if products within the subscription had been archived. This ensures a cleaner and more accurate user experience for subscription payments.
Original PR description
When the subscription is expired and has to be paid, only use an anchor for `Pay Now` if the advance payment section is displayed (it could be hidden for ex. if any of the product has been archived)