Wednesday, May 13, 2026
42 changes · saas-19.3
New functionality added to Odoo
This update adds comprehensive test cases for the France fiscal report generation process. These tests cover adding and removing report lines, extracting data, and exporting the report in XML format – ensuring accurate and compliant report creation for French businesses. This improves the reliability and quality of the France localization feature.
Original PR description
Created test cases for adding and removing lines from a report, extracting the data, and exporting the report as xml for the france localization fiscal report task-6131210
Enhancements to existing features
This update improves the handling of invoices from CBC Belgium, a key customer. It now automatically extracts the vehicle license plate number (`LCPL-NO`) from these invoices, ensuring accurate record-keeping. This enhancement streamlines invoice processing and compliance with CBC Belgium's requirements.
Original PR description
Used on invoices from CBC Belgium Forward-Port-Of: odoo/odoo#263878
Resolved issues and error corrections
This update resolves a technical error that prevented users from generating balance sheet comparisons correctly. The fix ensures that date types are consistently handled, allowing the 'Comparison' smart button to function as expected. This improves the reliability of balance sheet reporting.
Original PR description
Step to reproduce - Install the accountant module. - create a fiscal year (for 01/01/26 to 30/06/26) from setting and enable it - Navigate to Accounting > Report > Balance Sheet - Click the…
Step to reproduce
- Install the accountant module.
- create a fiscal year (for 01/01/26 to 30/06/26) from setting and enable it
- Navigate to Accounting > Report > Balance Sheet
- Click the `Comparison` smart button and set `Previous Period` to `2 periods`.
Observation:
- we face a traceback
``` File "/home/odoo/odoo/codebase/enterprise/saas-19.2/account_reports/models/account_report.py", line 5739, in _get_annotations
period_date_from = self._adjust_date_for_joined_comparison(options, period_date_from)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/codebase/enterprise/saas-19.2/account_reports/models/account_report.py", line 5695, in _adjust_date_for_joined_comparison
return min(period_date_from, comparison_date_from)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'datetime.date' and 'str'
```
Cause:
- `_get_period_dates` return string in case we have date which falls in
`custom_range_match`, when `get_report_information` is called, while
`period_date_from` is of type date
- hence there is mismatch between types
Fix:
- `_get_period_dates` is supposed to return date object always, hence fixed the
return type in case we have match for custom range
opw-6185629
Forward-Port-Of: odoo/enterprise#116350This update simplifies a confusing error message related to multiple GST registrations within an organization. The previous message led to wasted support time and incorrect reports. Now, users are prompted to verify their GST username matches their GST number, providing a clearer solution.
Original PR description
Users operating with multiple GST registrations (GST-wise branches/companies) could encounter a misleading error when the GST username belonged to a different GST number within the same organization. Previously, the system raised an error directly received from the server: [AUTH4041] Invalid Parameter state-cd in request header This message was confusing and led to unnecessary support tickets and false reports, as the issue was actually a mismatch between GST username and number. The error message has been updated to be more explicit and user-friendly: Please confirm that <gst_username> is associated with <gst_number>. Additionally, refactored duplicated logic by extracting the common code into a single helper function and reusing it across all occurrences. task-6041510 Forward-Port-Of: odoo/enterprise#111115
This update fixes an issue where newly created stock batches were incorrectly named 'New' instead of following the standard 'BATCH/<TYPE>/000NN' naming convention. The change ensures that all new batches are correctly named, improving data consistency and reporting accuracy within the Delivery Orders feature. This resolves a bug impacting batch identification.
Original PR description
Steps to reproduce 1. Open the Barcode app > Operations > Delivery Orders. 2. Switch to the "Batches" tab. 3. Create a new one. Issue The created batch keeps the placeholder name "New" instead of…
Steps to reproduce
1. Open the Barcode app > Operations > Delivery Orders.
2. Switch to the "Batches" tab.
3. Create a new one.
Issue
The created batch keeps the placeholder name "New" instead of being
renamed to `BATCH/<TYPE>/000NN`.
The barcode kanban "New" button calls `open_new_batch_picking`, which
runs `Batch.create({})` while the action context carries
`default_picking_type_id` set by `stock.picking.type._get_action` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock/models/stock_picking.py#L432.
Since `vals` itself doesn't carry `picking_type_id`, the lookup in
`stock.picking.batch.create()` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock_picking_batch/models/stock_picking_batch.py#L181
returns an empty recordset, so the sequence-based rename branch is
skipped and the name stays at the field default `'New'`. The
subsequent `super().create` then applies the context default, so the
batch is correctly linked to a picking type but with the wrong name.
opw-6168320
Forward-Port-Of: odoo/enterprise#115809This update fixes a visual inconsistency in the appearance of website tabs when translating content. Specifically, it ensures that the translation state is correctly displayed for tab descriptions. This resolves a previously known issue, improving the overall user experience and consistency of the Odoo website.
Original PR description
Span elements which have a style that causes them to be displayed as "block" do not have the background color given by the translation span (this is a ["known" issue]) To show the translation state on those nodes, this commit uses the resource `force_background_translation_state_selectors` for the following: - `.o_nav_tabs_description`, the description of tabs in `s_tabs_images` Introduction of `force_background_translation_state_selectors`: cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 ["known" issue]: https://github.com/odoo/odoo/commit/9addf9617830885532c27abb0ad5fa915e9f8f62 task-5892636 Forward-Port-Of: odoo/odoo#263620
This update fixes an issue where subsections remained visible on invoices even after the 'Hide Composition' option was selected. The underlying code was updated to ensure subtotals and unit prices are correctly hidden when this feature is enabled, aligning invoice presentation with 'Hide Prices'.
Original PR description
### Steps to reproduce: - Download 'Sales' app and create a product - Create an invoice with a section and a subsection - Set `Hide Composition` on the section - Add a product line under the subsection - Confirm and preview the invoice report > The subsection is still visible _Same issue occurs when activating 'Hide Prices'_ ### Cause of Issue: The `report_invoice.xml` file didn't include the right conditions to display the subtotals and unit prices in case of 'Hide Composition'/'Hide Prices'. Also, taxes were returned in `account_move_line` when they shouldn't be visible in case of 'Hide Prices'. ### Fix: Altered the conditions for sections and subsections, so that the information showing in 'Quotations' and 'Invoices' are consistent. opw-6069334 Forward-Port-Of: odoo/odoo#263944 Forward-Port-Of: odoo/odoo#258628
This update corrects a previous oversight by adding the 'l10n_pl_bank_verification' module to the weblate.json file. This ensures that the new bank verification functionality is correctly translated and available within the Odoo application for Polish users.
Original PR description
[FIX] Add l10n_pl_bank_verification to weblate.json In a previous PR, we added the new module 'l10n_pl_bank_verification' but didn't added it in weblate.json. This PR fix it See odoo/odoo#262518 Forward-Port-Of: odoo/odoo#263758
This update resolves a technical error that prevented the system from correctly identifying project documents when a project lacked a designated folder. The fix ensures the system handles projects with and without associated document folders smoothly, improving data accuracy and preventing potential errors during document retrieval.
Original PR description
The `_compute_documents()` method was expecting that the `documents_folder_id` field was always set.
However, the field is not required and can be empty.
This is not an issue if the compute is called on a single record, but when called on a recordset with :
- A project with related folder with at least one document
- A project with `documents_folder_id` empty The compute will fail because it calls `startswith()` with a parameter that is `False`.
```python
File "/home/odoo/src/enterprise/19.0/documents_project/models/project_project.py", line 50, in <lambda>
document_ids = documents.filtered(lambda doc: doc.parent_path.startswith(project.documents_folder_id.parent_path))
TypeError: startswith first arg must be str or a tuple of str, not bool
```
Solution:
Check for project-related documents only if the dedicated folder is set.
Forward-Port-Of: odoo/enterprise#117066This update resolves an issue preventing accurate translation exports from the Web Studio interactive editor. A specific formatting error in the code templates was causing incorrect data extraction, leading to translation failures. The fix removes this problematic formatting to ensure correct export and translation of code.
Original PR description
It seems that the Babel Javascript tokenizer is not able to correctly parse a template string starting with a backslash and a newline. This caused it to extract pieces of code coming after it. The code excerpts would be exported in the POT file, but not applied to the JS code of course. The original message was not exported though, so it was not possible to translate it. This commit rewrites the template string to not use a backslash and a newline. This way the string is properly extracted and the code after it is not. Change was introduced by this commit[^1]. [^1]: https://github.com/odoo/enterprise/commit/56a2d9c4c2cc655af0469038d4c483581ac78864 Forward-Port-Of: odoo/enterprise#116927
This update fixes a layout issue on the shop page for users who view the website in RTL (Right-to-Left) language settings. The previous layout was broken due to incorrect spacing, and this change ensures the shop grid displays correctly for all users. This improves the overall user experience for a wider range of customers.
Original PR description
Prior to this commit, the shop grid layout was broken in RTL due to misplaced left borders and padding. This commit adjusts those elements for RTL, fixing the layout. task-5933289 | Before | After | |--------|--------| | <img width="1406" height="869" alt="Screenshot 2026-05-04 at 10 37 56" src="https://github.com/user-attachments/assets/81f057cc-89d3-44f6-a723-9b439b88290d" /> | <img width="1392" height="877" alt="Screenshot 2026-05-04 at 10 36 53" src="https://github.com/user-attachments/assets/ded4eb4a-c82d-4114-ade6-5455f341a8f5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262483
This update fixes a technical issue where linking restaurant tables could cause an infinite loop, potentially disrupting table management. The fix ensures correct table positioning calculations, particularly when tables are merged, preventing errors and maintaining data integrity. This improves the reliability of the restaurant table functionality.
Original PR description
Before this commit, it could happen that we try to link a restaurant table to another that was already its parent (for example by merging them while offline, we couldn't know that they were in a prent-child relation). This would lead to an infinite loop when trying to get the position of the table since it was computed based on the parent position so when a table is its own grand-parent, we get an active infinite loop. We solve the problem by going through the backend to merge tables. Task-id: 6183779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262642 Forward-Port-Of: odoo/odoo#262509
This update fixes a visual flicker in the timesheet timer field when saving data. By rounding the timer value on the server-side and validating record data before saving, the flicker is eliminated, ensuring a smoother and more reliable user experience. Additionally, the delete button visibility was adjusted to prevent a related flicker issue.
Original PR description
before: The timer value is rounded to the record, then the saving attempt is made. This makes the timer flicker to the rounded value for a split second if the saving operation failed (ex. missing data) after: The record is updated with the rounded value if the saving operation is valid. We check the record validity before saving or updating the record. --- task-6120567 Forward-Port-Of: odoo/enterprise#114502
This update adds sample accounting data specifically for the Italian localization (l10n_it). This allows our team to easily test and demonstrate the Italian version of Odoo, ensuring accurate reporting and compliance with Italian accounting standards. The data includes key elements like invoices, bank accounts, and EDI information.
Original PR description
Purpose: Load a pre-configured set of Italian accounting sample data to facilitate localization testing and demonstrations. Specifications: This commit introduces comprehensive sample data for the Italian localization, configuring the following: * Partners * Bank Accounts * Invoices & Bills * Dynamic Dates: All generated moves use a relative date format to ensure testing data remains relevant and doesn't expire on runbot. * EDI Data: Populates necessary e-invoicing fields (`l10n_it_codice_fiscale`, `l10n_it_pa_index`) for the created partners. task-6103257 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263881 Forward-Port-Of: odoo/odoo#262711
This update fixes an issue where file boxes, even after deleting their content, wouldn't be fully removed from the To-Do creation screen. The fix allows deleting non-editable file boxes when they are fully selected and their parent is editable, ensuring a cleaner user experience.
Original PR description
Problem: When adding a file box, selecting all content, and deleting, the file box is not removed. Cause: `o_file_box` is non-editable, so `canBeDeleted` returns `false` for this node, preventing its deletion. Solution: Allow deletion of non-editable nodes when they are fully selected and their parent is editable. Steps to reproduce: - Go to To-Do → Create New. - Upload a file. - Type some text next to the file. - Select all content (Ctrl + A or with the mouse). - Press Backspace/Delete multiple times. - Observe that the file box is not removed. task-6185206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263008
This update corrects inaccuracies in the data used for payroll calculations in Belgium (l10n_be_hr_payroll_prisma). Specifically, it addresses missing codes related to leave types (LEAVE280, LEAVE115, LEAVE231) to ensure accurate reporting and compliance. This improves the reliability of payroll processing.
Original PR description
Issue: ---------------------------------------- Some prisma codes are wrong. Solution: ---------------------------------------- Change the data files. There are some subtilities that were not implemented: - LEAVE280: 0304 (if less than a year) and 0345 (if more) - LEAVE115: 0820 (Work accident) and 0830 (Occupational Disease) opw-6090081 Forward-Port-Of: odoo/enterprise#116808 Forward-Port-Of: odoo/enterprise#112949
This update resolves a crash that could occur when attempting to unassign items from a stock reception report if the associated source document (like an order) was empty. The fix prevents the system from trying to remove references to non-existent documents, making the report more reliable for all users. This change ensures a smoother user experience and prevents unexpected errors.
Original PR description
#### Issue: Clicking `Unassign` from the stock reception report could raise a traceback when the outgoing move source document was empty. ``ValueError: Expected singleton: mrp.production()`` Please…
#### Issue: Clicking `Unassign` from the stock reception report could raise a traceback when the outgoing move source document was empty. ``ValueError: Expected singleton: mrp.production()`` Please note that this is not expected in standard Odoo, where reception report moves should normally be linked to a source document, such as an MO, SO, or picking. This case seems specific to the client database and may be due to a customization, but handling it makes the reception report more robust. #### Cause: The reception report built report lines from `source = (move._get_source_document(),)` and checked `if not source`. Since the tuple itself is truthy, moves whose `_get_source_document()` returned an empty recordset were not filtered out. For example if `out_move._get_source_document()` returns `mrp.production()`, then `source = (mrp.production(),)` is still truthy, so the report keeps the line even though the source document is empty. later `action_unassign()` called `_remove_reference()` on that empty source document, which crashed on `ensure_one()`. #### Fix: Added a helper function that skips moves where `_get_source_document()` is empty. Also skip reference synchronization in `_action_assign()` and `_action_unassign()` when the source document is empty just for more protection. opw-6174870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263700 Forward-Port-Of: odoo/odoo#263366
This update resolves an issue where the DIAN (Colombia) information wasn't appearing on invoice PDFs in version 19.3. The fix reordered a section within the invoice XML to ensure all required data, including the DIAN code, is correctly rendered. This ensures accurate reporting for Colombian businesses.
Original PR description
**STEP TO REPRODUCE** 1. Setup DIAN. 2. Create an invoice. 3. Send it to dian. 4. Notice the cufe doesn't appear on the pdf. This fix moves the CUFE div before the informations div. Before the fix, it was placed at the top of the xml which appears to not render starting from 19.2. opw-6182706 Forward-Port-Of: odoo/enterprise#116245
A technical bug in the expense reporting feature has been resolved. The issue occurred when searching for customers within expenses, specifically related to the 'costumer to reinvoice' field. This fix ensures accurate search results and prevents a traceback error, improving the usability of the expense reporting process.
Original PR description
**PROBLEM** & operator must be used with 2 Domain. https://github.com/odoo/odoo/pull/206894 forget to convert the right side part to a domain, leading to a traceback. 1. Install sale and expense_sale. 2. Set the Sales/Sales permission to "User: Own Documents only". 3. Create an expense of type communication. 4. On the field "costumer to reinvoice", start typing to search. 5. A traceback will occur. opw-612755 Forward-Port-Of: odoo/odoo#263861
This update fixes a minor issue where the 'Plan' button appeared on the Gantt view even when no Sales Order Lines were available to plan. The fix ensures the button only appears when there's a valid SOL to work with, streamlining the user experience and preventing unnecessary form openings.
Original PR description
Steps to reproduce: === - Go to Planning → Gantt view. - Click on an empty cell where no Sale Order Line (SOL) exists. - Observe that the Plan button appears in the multi-selection toolbar. Issue: === The Plan button is shown even when there are no SOL to plan, and clicking it opens the planning form dialogue, which should not happen in this scenario. Cause: === The visibility of the Plan button relies solely on whether `onPlan` is defined. There is no built-in validation to check whether any SOL actually exists for the selected cell before exposing the 'onPlan' action. Fix: === Introduce a new reactive prop `hasAvailableSOL` and compute it before `onPlan` is used. The Plan button is now shown only when an SOL actually exists. task- 5163638 Forward-Port-Of: odoo/enterprise#99517
This update fixes an issue where flexible employees were incorrectly shown as unavailable in the Project Gantt chart. The change ensures that flexible employees without scheduled leaves are accurately displayed, aligning with the expected behavior of showing only approved leaves and holidays. This improves the accuracy of project timelines.
Original PR description
Steps to Reproduce --- - Assign a flexible working schedule to an employee (no leaves) - Open Project > Tasks > Gantt view grouped by Assignee - The employee's weekends and off-hours are grayed out…
Steps to Reproduce --- - Assign a flexible working schedule to an employee (no leaves) - Open Project > Tasks > Gantt view grouped by Assignee - The employee's weekends and off-hours are grayed out Current Behavior --- Flex employees with no approved leaves in the viewed date range have incorrect grayed-out days in the Project Gantt view. Expected Behavior --- Flex employees should have no grayed-out days except approved leaves and public holidays. Issue --- When a flex employee has no leaves in the viewed period, `_get_unavailable_intervals()` returns an empty dict for that resource. `_gantt_unavailability()` then falls back to `company_leaves`, producing incorrect gray intervals. The same case is already handled in `planning` (ref PR), but `project_enterprise` was not covered. Fix --- Add a guard in `_gantt_unavailability()` to return no unavailabilities for flexible resources absent from `leaves_mapping`. Related : https://github.com/odoo/odoo/commit/5f1cd39944134ffa2c30c331f8a5daca56446d78 task - 5063071 Forward-Port-Of: odoo/enterprise#116847 Forward-Port-Of: odoo/enterprise#113247
This update fixes an issue where public holidays in different companies were incorrectly impacting employee time tracking reports. The fix ensures that only company-related public holidays are considered when generating these reports, preventing inaccurate planned hour calculations. This improves the accuracy of time tracking data.
Original PR description
## Steps to reproduce: - Install project_timesheet_forecast module - Create a public holiday in one company - In another company create a planning slot for an employee that overlaps with the holiday - Go to Timesheets/Planning analysis report - Notice the report is not showing planned hours for the employee on the day of the public holiday ## Cause: When filtering the resource_calendar_leaves we don't check for the company so any public holiday in any company will be taken into account even if it doesn't affect the employee ## Fix: Exclude holidays that has different company than the planning slot opw-5027070 Forward-Port-Of: odoo/enterprise#117015 Forward-Port-Of: odoo/enterprise#116263
This update resolves an issue where users could unintentionally create links within inline code or code blocks while using the Ctrl+K shortcut in the HTML editor. The change ensures that selections within code blocks are treated correctly, preventing the automatic generation of links. This improves the stability and usability of the HTML editor for all users.
Original PR description
Description of the issue this PR addresses: This commit ensures that links are not created when the selection is inside inline code or a code block, even when using the Ctrl+K shortcut. task-5489870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262778 Forward-Port-Of: odoo/odoo#262397
This update ensures that the Studio XML editor only translates views for the currently selected website, preventing unintended translations across all websites. The change corrects a previous behavior where the default website's language was used, improving the user experience and ensuring accurate website localization. This fix is designed to maintain compatibility with existing customizations.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. While in debug mode, enter Studio and navigate to a view that has translation terms (ex. Sale Order Form view), then open the XML editor. opw-5136124 Foward Port of https://github.com/odoo/odoo/pull/237000
This update corrects an issue where the Studio XML editor incorrectly used translations from the first website in the database, regardless of the user's selected language. The fix ensures that translations are only applied to views within the Website module's HTML/CSS editor, improving the user experience and preventing unintended translation conflicts. This change maintains compatibility with existing customizations.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. While in debug mode, enter Studio and navigate to a view that has translation terms (ex. Sale Order Form view), then open the XML editor. opw-5136124 Foward Port of https://github.com/odoo/enterprise/pull/110418
A bug in the sale stock test was causing it to pass incorrectly due to a caching issue. This update ensures the test uses the correct, restricted user, triggering the intended access rights checks. This improves the reliability of our test suite.
Original PR description
When running the test, `button_validate()` was called twice in succession. - Once explicitly - Once through `process_cancel_backorder()` The first time it is called though, it's not through the restricted user that we want to test, allowing some access rights checks to run smoothly. The second time it's called with the restricted user, the cache still contains some data that should be no longer accessible, allowing the test to run even though it shouldn't. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264057
This update resolves an issue where regular stock users were unable to view sales orders, leading to access errors. The fix ensures all sales order deliveries, including inter-company transactions, can be properly accessed by standard users, improving operational efficiency.
Original PR description
When running `button_validate`, a regular stock user won't be able to access the related SO to check whether the partner is another company or not. This will raise access errors for all regular SO deliveries, regardless of being inter-company or not. Forward-Port-Of: odoo/enterprise#117047
This update fixes an issue where PDF Manager action names appeared awkwardly due to a styling class. The change removes this class, resulting in cleaner and more professional-looking action names within the PDF Manager interface. This improves the user experience.
Original PR description
Previously, pdf_manager actions used class "text-uppercase". Action names looked awkward. In this commit, we remove the class and properly display action names. task-6159317 Forward-Port-Of: odoo/enterprise#117000 Forward-Port-Of: odoo/enterprise#116382
This update fixes an issue where replying to notes using the HTML composer resulted in incorrect formatting and lost content. The change ensures proper spacing and formatting preservation when replying, leading to a more reliable and user-friendly note response experience.
Original PR description
Before this PR, Replying to a note with the HTML composer enabled had several issues. - The mention added did not include a trailing space. - If the composer already contained formatted content, reply action discarded all formatting because the content was overwritten using composerText, which is not formatting-aware. - the composer sometimes showed extra spacing between lines because the base container used a `<p>` tag instead of a `<div>`. This PR fixes these issues by - inserting the mention directly into composerHtml with an editable trailing space instead of mutating composerText. This preserves existing formatting, and correctly adds spacing after mentions. - The base container always use a `<div>`, preventing unwanted line spacing task-[5454785](https://www.odoo.com/odoo/project/1519/tasks/5454785) Forward-Port-Of: odoo/odoo#263901 Forward-Port-Of: odoo/odoo#242748
This update fixes a previous issue where calls in inactive channels weren't showing up in the sidebar, confusing users. Now, when a call starts, the channel's 'last interest' date is updated, making calls more visible and improving the user experience. This ensures calls are easily found and reduces confusion.
Original PR description
Starting a call in an inactive channel could leave it hidden from the sidebar when the channel had no recent messages, which was confusing for users. To make call initiation more visible, update the channel's last interest date when the first participant joins the call, similar to call notification messages. Subsequent participants joining the same call do not update it again. task-6185134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263793
This update fixes a frustrating issue where clicking 'Discard' in the Sign Template would cause the page to flicker and reload. Now, the discard process happens directly within the existing iframe, providing a smoother and more reliable experience for users. This improves usability and reduces confusion.
Original PR description
Before this commit, clicking Discard in Sign Template reloaded the action/PDF iframe, which caused flicker. The discard flow was also more complex than needed and field normalization was noisy. After this commit, discard now happens in place: we fetch fresh sign items/radio sets, reset fields inside the existing iframe, and keep the page mounted with no reload. task-6121560 Forward-Port-Of: odoo/enterprise#114892 Forward-Port-Of: odoo/enterprise#113853
This update enhances the logging of technical errors within the l10n_sa_edi module, which handles Saudi Arabia's VAT requirements. Previously, these errors were hidden to avoid confusing users, but now they are logged with a specific prefix for easier troubleshooting by our support and development teams. This improves our ability to quickly diagnose and resolve issues related to VAT processing.
Original PR description
Log suppressed technical validation failures in server logs with a stable ZATCA_ERROR prefix while keeping user-facing errors unchanged. task-6110313 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261536
This update corrects a technical issue preventing the proper processing of end-of-service payslips when action_date is set. The fix ensures that departure registration actions can be executed correctly, resolving a test failure identified by Odoo's automated testing system. This improves the reliability of payroll processing for Jordanian users.
Original PR description
Setting action_date allows to execute departure.action_register on the same day. runbot error: https://runbot.odoo.com/odoo/runbot.build.error/242533 task: 6187007
This update removes outdated references to stock-related data within tests for the l10n_fr_pos_cert, pos_loyalty, and pos_self_order modules. Following a recent refactor of the POS module, these tests were no longer relevant, ensuring greater stability and accuracy of the testing process. This change ensures the POS modules function correctly.
Original PR description
*= l10n_fr_pos_cert,pos_loyalty, pos_self_order Issue: ====== - Some tests were still using stock-related fields and groups that were previously part of `pos`, but were moved to a new module `pos_stock` after the refactor. Fix: ===== - Remove references to these fields from the tests, as stock-related logic is now handled in `pos_stock` module. Task-6183114 Error-242928,243017,243059 Related Enterprise: https://github.com/odoo/enterprise/pull/116185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes outdated test references related to stock management within the l10n_mx_edi_pos and l10n_pe_edi_pos modules. Following a recent refactor of the POS stock functionality, these tests have been updated to align with the new module structure, ensuring accurate test results.
Original PR description
Issue: ====== - Some tests were still using stock-related fields and groups that were previously part of `pos`, but were moved to a new module `pos_stock` after the refactor. Fix: ===== - Remove references to these fields from the tests, as stock-related logic is now handled in `pos_stock` module. Task-6183114 Error-242928,243017,243059 Related Community PR: https://github.com/odoo/odoo/pull/262719
A technical issue was causing a traceback in the Department Hierarchy view when departments had managers assigned. This fix addresses a problem with how the system handles date information, preventing the error and ensuring the view functions correctly. This improves the user experience for managing department structures.
Original PR description
## Issue When opening the *Hierarchy* view of Employees > Departments, if at least one department has a manager set, a traceback appears before the view. ## Steps to reproduce 1. Install *Employees*…
## Issue
When opening the *Hierarchy* view of Employees > Departments, if at least one department has a manager set, a traceback appears before the view.
## Steps to reproduce
1. Install *Employees* (`hr`)
2. In Employees > Departments, add a manager to a department
3. Open the *Hierarchy* view
4. **A traceback appears:**
```
Caused by: TypeError: Cannot read properties of undefined (reading 'toMillis')
at get uniqueId (http://localhost:8192/web/assets/cbd2032/web.assets_web.min.js:21370:74)
at Many2OneAvatarEmployeeField.template (eval at compile (http://localhost:8192/web/assets/cbd2032/web.assets_web.min.js:1387:421), <anonymous>:25:122)
...
```
## Cause
The traceback is yielded from the `get uniqueId` getter from the `Many2OneAvatarEmployeeField` component:
https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/hr/static/src/views/fields/many2one_avatar_employee_field/many2one_avatar_employee_field.js#L38-L40
where `write_date` is undefined. This getter was added by https://github.com/odoo/odoo/commit/3732ca85b03bea9eabfb05cc306ce0bf5bac88d4, which handled the case of undefined `write_date` for the related Kanban component:
https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/hr/static/src/views/fields/many2one_avatar_employee_field/kanban_many2one_avatar_employee_field.js#L49-L52
A similar solution is applied in this problematic getter.
opw-6128837
Forward-Port-Of: odoo/odoo#260069This update resolves an issue where the cursor would incorrectly appear after an image block after deleting content. The fix prevents the HTML editor from misinterpreting self-closing elements, ensuring the cursor remains before the image as intended. This improves the user experience when editing content with images.
Original PR description
After a deletion, if the selection would end up on an image and the image is considered as a block, the selection is set inside it. Upon collapse, this leads to having the selection after the image. This commit avoids this by preventing `normalizeEnterBlock` from taking self closing elements into account. Steps to reproduce: - Go to website - Drop a `s_text_image` snippet - Select the image - Press the left cursor key to put the cursor before the image - Type a letter - Press backspace - Type a letter => The second letter was put after the image task-5436148 Forward-Port-Of: odoo/odoo#263543
This update restores a key in Odoo's response messages to maintain compatibility with older versions. Removing this key simplified the system, but for continued support of Odoo 19.3, we've reintroduced it. This ensures seamless operation for existing integrations.
Original PR description
In odoo/odoo#243554, we removed the `owner` key in response messages to simplify (use only `session_id`). For backward compatibility, we need to keep the key. We'll be able to remove it completely when v19.0 will be deprecated.
This update ensures that when a restaurant order is split, the previously selected preset is automatically applied to the new order portion. Previously, a new 'Select a Preset' modal would appear unnecessarily. This change improves the user experience and consistency within the restaurant POS system.
Original PR description
In the restaurant pos when splitting an order, the 'Select a Preset' modal would show up even if a preset was already selected for the original order. This fix automatically copies the exiting preset on the split order as well Task-[6171972](https://www.odoo.com/odoo/project/1737/tasks/6171972) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update clarifies the display of archived users in the avatar card by hiding the 'offline' status. Previously, this status was misleading, as archived users are no longer active. This change improves user experience and aligns the display with the users' inactive state.
Original PR description
*: test_discuss_full Previously, archived users were displayed as 'offline' in the avatar card, which could be misleading since they are no longer active participants. This PR ensures that the status is hidden for archived users, avoiding confusion and aligning the behavior with their inactive state. task-4797343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where survey time limits were incorrectly displayed with 'h' (hours) instead of 'm' (minutes). The change ensures that survey time limits are shown in the correct unit, improving the user experience and accuracy of survey settings. This resolves a technical detail related to a recent update to the survey module.
Original PR description
In the `time_limit` field, `h` was displayed by default next to the limit because as recently here https://github.com/odoo/odoo/commit/4751bbed988d8ee5233d70c4852ecbd5a03b228a we introduced the unit option for the `float_time` widget and by default that unit will fallback to hour so that's why `h` was displayed there. This PR addresses the issue and passed the minute as a unit as we were using the minutes for the survey time limit. Task-6132365 Forward-Port-Of: odoo/odoo#260557
This update resolves an issue where the Project/Task dropdown menu in the Timesheets Assistant was hidden behind the sticky 'Total' footer. The fix adjusts the menu's layering to ensure it's always visible when the edit form is open, improving user experience.
Original PR description
**Steps to reproduce:** - Open Timesheets > Assistant menu. - Click a row near the bottom of the "My Timesheets" section to open the edit form. - Open the Project or Task dropdown menu. **Issue:** The dropdown menu is hidden underneath the sticky "Total" footer. This happens because both the edit form and the footer share the same stacking context priority. **Fix:** Update .o_activitywatch_sync_timesheet_edition_form to manage its own stacking context. It now defaults to z-index: 1 to ensure standard scrolling behavior, but jumps to z-index: 3 on hover or focus-within. This ensures that when a user interacts with the form, its dropdowns correctly float above the sticky footer. task-6105369 Forward-Port-Of: odoo/enterprise#113377