Wednesday, May 13, 2026
33 changes · saas-19.2
Resolved issues and error corrections
This update resolves an issue where the DIAN (Colombia) information wasn't appearing on invoice PDFs in version 19.2. The fix simply reordered the layout of the PDF to ensure the required data was correctly rendered. This ensures accurate reporting for Colombian businesses using the Enterprise module.
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
This update resolves an issue where child partners in the Spanish localization were incorrectly flagged as companies. The fix ensures that child partners retain their correct status based on their individual commercial entity information, preventing misidentification as companies. This ensures accurate reporting and compliance within the Spanish tax system.
Original PR description
Step to reproduce: - install contacts and l10n_es and switch to ES company - create a partner, with valid vat ex. A12345674 - create a child partner from the form view Observation: - with debug mode,…
Step to reproduce: - install contacts and l10n_es and switch to ES company - create a partner, with valid vat ex. A12345674 - create a child partner from the form view Observation: - with debug mode, check that both records have `is_company` = True - child partner should not be considered as a company Cause: - After commit [1] `is_company` is a computed field, which can be overridden by other localization - in commit [2] for spain localizaton, `is_company` is true for all partner with valid CIF vat. - when we create a child partner, its value is synced with its parent at `_fields_sync` method with chain of methods finally leading to `vat` at `_synced_commercial_fields` - hence we propagate such commercial fields from parent to child - as now child also have same CIF vat, its is_comany = True [1] https://github.com/odoo/odoo/commit/f2965048f60fe6c815b3e50fa714c97a93dfb5d3 [2] https://github.com/odoo/odoo/commit/2d8013ccc858898fed52deac6eb11a8b5bb57351 Fix: - we now consider a partner as a company only when they own their commercial entity opw-6063786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users couldn't delete attachments from vendor bills after confirmation. The fix restricts a recent feature change to only 'comment' message types, addressing a technical limitation that prevented attachment deletion for notifications. This ensures users can properly manage attachments within the system.
Original PR description
Step to reproduce: - install purchase - create a RFQ, confirm it. a PO will be created - click on "upload bill" , upload a documnet, you will be sent for vendor bill - confirm the bill - try to…
Step to reproduce: - install purchase - create a RFQ, confirm it. a PO will be created - click on "upload bill" , upload a documnet, you will be sent for vendor bill - confirm the bill - try to delete the attachment from "paper-clip" icon Observation: - Error message: ```Only messages type comment can have their content updated ``` Cause: - commit [1] introduced a feature which adds "edited" tag in message body if attachment is removed, but that is only applicable for message with type == 'comment' https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/mail/models/mail_thread.py#L521-L531 - As this attachment is attached to record at time of creation, its type is "notification", and hence we are not able to delete this [1] https://github.com/odoo/odoo/commit/7c8971f2e2870fee19f55f971f3b8c8e553959c3 Fix: - we now limit the feature introduced by commit [1] only for message type "comment" opw-6055206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where the tour worksheet wasn't consistently saving due to a timing issue. The fix adds a brief delay to ensure the worksheet is fully loaded before saving, preventing data loss. This improves the reliability of the tour process.
Original PR description
Currently, the test tour loads too quickly, so the worksheet is not saved properly. The issue happens because the worksheet is not yet visible on the portal view side. Therefore, i added an extra step to wait for the HTML field to load, giving enough time for the worksheet to be fully loaded. runbot error-242479 Forward-Port-Of: odoo/enterprise#116918
This update simplifies a confusing error message related to multiple GST registrations within an organization. Previously, users received a technical error that led to support requests. Now, the system clearly prompts users to verify the GST username matches the associated GST number, reducing support burden and improving user experience.
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 initially named 'New' instead of following the standard 'BATCH/<TYPE>/000NN' naming convention. The fix ensures that all new batches are correctly named, improving data consistency and reporting accuracy within the Delivery Orders feature. This resolves a minor operational issue.
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 website builder's tab design. Specifically, it ensures that translation states are correctly displayed on tab descriptions, resolving a previously identified issue. The change improves the overall user experience and consistency of the 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 resolves an issue where invoice subsections remained visible even after the 'Hide Composition' feature was enabled. The fix adjusted the underlying invoice report settings to ensure consistent display across 'Invoices' and 'Quotations', preventing unwanted subtotals and tax information. This improves invoice clarity and accuracy for users.
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 fixes a display issue where the number of ECOs listed on a Bill of Materials (BoM) was incorrect. The fix ensures that only ECOs directly associated with the current BoM version are counted, resolving a misleading display. This improves the accuracy of BoM information for users.
Original PR description
Steps to Reproduce (Fresh Database): -------------------------------------- 1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules 2. Create a product > New -- Name: "Test Product" > Save 3.…
Steps to Reproduce (Fresh Database):
--------------------------------------
1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules
2. Create a product > New -- Name: "Test Product" > Save
3. Create BoM v1
- Go to Manufacturing > Products > Bills of Materials > New --Product: Test Product
- Add component: any
4. Create and apply ECO 1 on BoM v1
- Go to PLM > ECOs > New-- Product: Test Product | Apply on: Bill of Materials
- BoM: Test Product (v1) > Confirm > Apply Changes
- This creates BoM v2 (previous_bom_id = BoM v1)
5. Create and apply ECO 2 on BoM v2
- Same as step 4 but select BoM v2
- This creates BoM v3 (previous_bom_id = BoM v2)
6. Create a separate unrelated BoM for the same product
- Go to Manufacturing > Bills of Materials > New
- Product: Test Product | Component: "Component B" > Save
7. Create ECO 3 on the separate BoM
- Go to PLM > ECOs > New - Product: Test Product | Apply on: Bill of Materials
- BoM: select the separate BoM from step 6 > Confirm
Observed Bug:
-------------
- Open BoM v3 > ECO(s) stat button shows count = 2
- Click the button > opens 3 records (ECO 3 incorrectly included)
Explain:-
----------
The ECO stat button on the BoM form was showing a mismatched count vs
the actual records opened when clicking it. This happened because
[button_mrp_eco](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L56) was using all keys from [_get_previous_boms](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L67)() as the
domain, which includes BoMs from unrelated lineages of the same product
template, while [_compute_eco_data](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L20) only counts ECOs belonging to the
current BoM's version lineage.
Fixed by filtering the domain to only include BoM IDs whose lineage set
contains the current BoM ID, making the opened records consistent with
the displayed count.
Before Fix
<img width="1901" height="875" alt="image" src="https://github.com/user-attachments/assets/3208aed5-ebd3-47a3-a457-a7d61b7743cb" />
```
In [24]: labo = self.env['mrp.bom'].browse(710)
In [25]: previous_boms_mapping = labo._get_previous_boms()
In [26]: Test = ['&', ('bom_id', 'in', list(previous_boms_mapping.keys())), ('type', '=', 'bom')]
In [27]: Test
Out[27]:
['&',
('bom_id',
'in',
[710,
1991,
2049,
1913,
1840,
1823,
1676,
1759,
1794,
1651,
1604,
1544,
1537,
1527,
1506,
1460,
1265,
1259,
1196,
1221,
1223,
1060,
1029,
960,
858,
850,
791,
739,
723,
698]),
('type', '=', 'bom')]
```
With My Fix
<img width="1824" height="947" alt="image" src="https://github.com/user-attachments/assets/0d68fdbc-7e42-4ce4-a326-2fb030ba1d06" />
```
In [15]: labo = self.env['mrp.bom'].browse(710)
In [16]: previous_boms_mapping = labo._get_previous_boms()
In [17]: previous_boms_mapping
Out[17]:
{710: {710},
1991: set(),
2049: set(),
1913: set(),
1840: set(),
1823: set(),
1676: set(),
1759: set(),
1794: set(),
1651: set(),
1604: set(),
1544: set(),
1537: set(),
1527: set(),
1506: set(),
1460: set(),
1265: set(),
1259: set(),
1196: set(),
1221: set(),
1223: set(),
1060: set(),
1029: set(),
960: set(),
858: set(),
850: set(),
791: set(),
739: set(),
723: set(),
698: {710}}
In [18]: relevant_bom_ids = [
...: bom_id
...: for bom_id, current_bom_set in previous_boms_mapping.items()
...: if labo.id in current_bom_set
...: ]
In [19]: relevant_bom_ids
Out[19]: [710, 698]
```
Task-6065020
Forward-Port-Of: odoo/enterprise#114039This update corrects a previous oversight by adding the 'l10n_pl_bank_verification' module to the Weblate translation file. This ensures that all user-facing text within the Odoo system is accurately translated for Polish bank verification processes, improving localization and user experience.
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 bug that prevented the system from correctly identifying project documents when the designated folder was empty. The fix ensures the system functions reliably regardless of whether a folder is associated with a project, improving document retrieval accuracy.
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 corrects a display issue in the survey time limit field, previously showing 'h' by default. The change ensures the time limit is consistently shown in minutes, aligning with how survey durations are defined, improving the user experience.
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
This update fixes an issue where the Table of Contents in the website's navigation bar wasn't displaying the correct translated text after styling headings. The fix ensures that translated headings are consistently shown in the navbar, regardless of inline styling, improving the user experience across multiple languages.
Original PR description
Steps to reproduce: =================== 1. Enable a second language on the website 2. Add a Table of Content snippet to a page 3. Apply bold (or any inline style) to one of the headings, save 4.…
Steps to reproduce: =================== 1. Enable a second language on the website 2. Add a Table of Content snippet to a page 3. Apply bold (or any inline style) to one of the headings, save 4. Switch to the second language in translation mode 5. Translate the styled heading and save => The TOC navbar entry keeps showing the source text on reload. => Expected: navbar shows the translated heading text, unstyled. Cause: ====== When a TOC heading carries inline markup, the server emits the heading and the navbar entry as two independent translation terms with different `data-oe-translation-source-sha` values, even though their textContent matches. A translation written under the heading's sha therefore never reaches the navbar's slot. `handleToC` was meant to bridge that by aliasing the navbar span's sha to the heading's during translation-mode setup, but two issues prevented it from working in saas-18.4+: - The TOC navbar lives under `.o_not_editable`, so its translation spans were excluded from `findOEditable` and `handleToC` never ran on them. The class `o_translation_without_style` was never added, and the sha was never aliased. Solution: ========= - `prepareTranslation` iterates TOC navbar translation spans explicitly, so `handleToC` reaches them despite `findOEditable` skipping `.o_not_editable`. - `handleToC` always tags the navbar span with `o_translation_without_style` when a matching heading exists. - An `after_replication_handlers` hook flags every replicated unstyled-translation target as `.o_dirty`, so the replicated translation is included in the save. opw-5950228 Forward-Port-Of: odoo/odoo#263547 Forward-Port-Of: odoo/odoo#260378
This update resolves an issue preventing accurate translation exports from the Web Studio interactive editor. A specific code formatting problem (using backslashes and newlines) was causing incorrect code extraction. The fix removes this problematic formatting, ensuring translations can now be properly exported and applied.
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 grid that was appearing incorrectly when Odoo is set to display content in Right-to-Left (RTL) languages. The changes adjust the layout elements to ensure a proper display for users in RTL environments, improving the overall user experience. This ensures all customers can easily browse and purchase products regardless of their language settings.
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 problem that could cause the restaurant table management system to freeze due to an infinite loop when merging tables. The fix ensures that table relationships are correctly handled, preventing this error and improving system stability. This change focuses on internal system improvements.
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 potential problem where multiple sign automation actions could silently override roles. The change adds a check within the automation process to ensure no conflicting roles are used, preventing incorrect permissions and maintaining data integrity. A new test has been implemented to verify this fix.
Original PR description
Before this commit, creating multiple server actions for the Sign app in a single transaction (e.g., when saving an Automation Rule with multiple nested actions) bypassed the `_check_sign_template_conflicts` constraint. Because the constraint only queried the database for existing links, it failed to detect conflicts within the in-memory batch, allowing the save to succeed and causing silent role overrides. This commit introduces an intra-batch check to the constraint. By tracking requested roles in memory during the loop, the constraint now correctly raises a ValidationError if multiple actions in the same transaction attempt to automate the exact same template roles. A test has been added to ensure batch creations are properly validated. Task: 6128909 Forward-Port-Of: odoo/enterprise#115062
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 and overall appearance.
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 file boxes, even after deleting their content, wouldn't be fully removed from the To-Do creation interface. The fix allows deletion of non-editable file boxes when they are fully selected and their parent is editable, improving the user experience and ensuring content is accurately removed.
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
A recent test was failing due to inconsistencies in how account reports were loaded during automated testing. This update ensures the test accurately reflects the system's behavior by generating the necessary account reports within the test itself. This resolves a runbot error and maintains consistent test results.
Original PR description
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report,…
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report, specifically, the account report corresponding to the audit report's company (see: odoo/enterprise#101377). In version 19.1, a test was added to validate account report options. However, this test assumed that embedded account reports would always load the global account report (i.e., `account_reports.balance_sheet`). When tests run on runbot, demo data is not loaded. In that context, no report variants exist in the database, so the system falls back to the global account report, causing the test to pass. In environments where demo data is loaded, a report variant does exist, and the system correctly selects it instead of the global report. As a result, the test assertions are no longer valid and fail, leading to runbot errors. To address the issue, we will generate the account reports within the `setup` method of the test. This ensures that the assertions remain consistent, regardless of whether demo data is present. runbot-error-id~242235 Forward-Port-Of: odoo/enterprise#112486
A technical error in the Odoo system's expense reporting feature has been resolved. The issue occurred when searching for customers within expense records, specifically related to the 'costumer to reinvoice' field. This fix ensures the system functions correctly and prevents errors during searches.
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 was incorrectly displayed in the Gantt view when no Sale Order Lines were present. The fix ensures the button only appears when there are actual sales opportunities to plan, streamlining the user experience and preventing unnecessary form openings. This improves efficiency and clarity for users.
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 resolves an issue where the cursor position was incorrectly placed after images after a deletion. Specifically, when deleting an image block, the cursor would end up positioned within the image itself. This change ensures the cursor remains before the image after a deletion, improving user workflow and data entry accuracy.
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
A bug in the sale stock test was causing it to pass incorrectly. The test was being executed with the wrong user, leading to inaccurate access rights checks. This fix ensures the test uses the correct user, guaranteeing reliable test results and preventing potential issues in the live system.
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 that all sales order deliveries, including inter-company transactions, are accessible to 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 a previous issue where the closing popup for bank payments didn't accurately display the number of payments made. Now, the popup correctly shows the total count of payments associated with a bank method, reducing user confusion and improving the accuracy of transaction information. This resolves a minor usability concern.
Original PR description
Before this commit, in the closing popup if a bank payment method had more than one payment, it would not show the count of payments, which could lead to confusion for the user. opw-6198656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent test in the Odoo MRP module failed because the user account lacked the necessary permissions to view lot tracking information. This change explicitly grants the required group (`stock.group_production_lot`) within the test environment, ensuring the test now passes consistently. This resolves a minor issue impacting test stability.
Original PR description
The test uses the stock move line detailed operations form and expects the `lot_id` field to be present in the view. Without demo data, the current user may not belong to the `stock.group_production_lot` group, causing the field to be absent from the rendered form view and the test to fail. Causing: `AssertionError: 'lot_id' was not found in the view` in line: https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/mrp/tests/test_consume_component.py#L477 Grant the lot tracking group explicitly in the test setup. runbot-243588 Forward-Port-Of: odoo/odoo#263759
This update corrects a technical issue within the HR module that could have caused incorrect version calculations related to employee contracts. The fix ensures accurate tracking of contract periods, preventing potential reporting discrepancies. This improves the reliability of HR data.
This update fixes a naming issue with quarterly returns. Previously, returns were labeled with 'Q1', 'Q2', etc., regardless of the company's fiscal year. Now, returns are named with the 'From Month Year - To Month Year' format, providing clearer and more accurate reporting for businesses with non-calendar fiscal years.
Original PR description
Currently, if the company fiscal year doesnot align with calender year, i.e Fiscal year end is not december and any month in between like India (March 31), while creating quarterly returns, the return name has Q1 for Jan - Mar, Q2 for Apr - Jun, and so on, which is not aligned with the fiscal year quarters. This commit fixes that issue by naming it like "From Month Year - To Month Year" for quarterly returns. task-6124692
This update resolves an issue where reports would fail when the fiscal year's end date was set to February 29th. The fix ensures that the system correctly handles leap year fiscal years, consistently calculating the start date as March 1st regardless of the end date.
Original PR description
**Steps to Reproduce:** 1. Install the Accounting module. 2. Go to Settings and set the fiscal year's last day to 29 February. 3. Accounting > Reporting > open any report. **Error:** `ValueError - day is out of range for month` **Cause:** At [1], a fixed year (2025) is used to compute the fiscal year end. However, 2025 is not a leap year, so creating a date with February 29 raises an error. **Fix:** Ensure that when the fiscal year’s last day is Feb 29, a leap year (2024) is used for the computation. For all other dates, the year remains unchanged (2025). As a result; - If the last day is February **28** (non-leap year) -> `fy_start` becomes **March 1** - If the last day is February **29** (leap year) -> `fy_start` also becomes **March 1** [1] - https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/account_reports/models/account_report.py#L820 sentry-7438598965
This update ensures that PDF attachments sent through the portal chatter are now correctly displayed as previews. Previously, the system was missing key data needed to generate these previews. This fix improves the user experience by allowing users to quickly view attached documents within the portal.
Original PR description
Before this commit, previews of pdf attachments (introduced in [1]) would not be displayed in portal chatters. This happens due to `_portal_message_format` not returning the data necessary to display pdf previews (i.e. `has_thumbnail` and `thumbnail_access_token`). This commit fixes the issue by returning said data. [1] https://github.com/odoo/odoo/pull/221006 task-6204747 Forward-Port-Of: odoo/odoo#263481
This update resolves a technical issue that could cause a traceback when a tour had no defined steps. The fix simply prevents the tour from starting if there are no actions to perform, ensuring a smoother user experience. The previous workaround has been removed, and the underlying cause (related to a database option) has also been addressed.
Original PR description
This commit is a backport of the PR odoo/262537 which prevents a traceback when a tour has no steps and thus no actions. We just do not start the tour if it has no steps. The reason why it was at first targeting saas-19.3 is because the `option.fromDB` was removed in this version. And on previous versions, it was really rare for this option to be true which prevented the traceback from being seen by users. On top of that, I revert the onHold property which was added to solve the same issue. But we keep the best solution which is to not start the tour if it has no steps. --- Backport of : https://github.com/odoo/odoo/pull/262537 Remove option.fromDB: https://github.com/odoo/odoo/pull/253523/changes#diff-992f9ec16e1b54e31fb4bbb37d3c0c099738282ad66ef33ea2239b15010351f7L166 Revert onHold: https://github.com/odoo/odoo/pull/255094 Forward-Port-Of: odoo/odoo#264156 Forward-Port-Of: odoo/odoo#263781
This update resolves a visual bug where the Project/Task dropdown in the Timesheets Assistant was hidden behind the sticky 'Total' footer. The fix adjusts the layout to ensure the dropdown is 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