Daily updates from Odoo
Thursday, April 16, 2026
37 changes · saas-19.2
Resolved issues and error corrections
This update resolves an issue where the Sales/Purchase Tax Report was incorrectly displaying doubled VAT amounts for invoices using 'Imported VAT' taxes. The fix replaces a problematic calculation method to accurately sum VAT amounts, ensuring financial reports are reliable. This improves the accuracy of VAT reporting for Vietnamese businesses.
Original PR description
The Sales/Purchase Tax Report showed doubled untaxed amounts and VAT amounts for bills using import VAT group taxes (e.g. "Imported VAT 10%"). The root cause: accessing `tag_t.balance_negate` in the SQL queries triggered a LEFT JOIN on `account_report_expression` (via `_compute_sql_balance_negate`). The Form 01/GTGT report references import VAT tags in two expressions (the parent line and the "including imported" sub-line), so this JOIN produced two rows per account move line, causing GROUP BY to double the SUM. Fix: replace `balance_negate` with a `balance_sign` option (-1 for sales, +1 for purchase) set in each handler's initializer to avoid the problematic JOIN. task-6083697
This update fixes an issue where invoice periods were incorrectly calculated when subscriptions started on the 1st of a month and 'Align to Period Start' was enabled. The fix ensures invoices accurately reflect the subscription's billing cycle, displaying the correct month and date range. This improves invoice accuracy and reduces potential billing discrepancies.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align…
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align to Period Start. 3. Create a new Subscription: * Select the configured monthly plan. * Add any subscription product. * In the Other Info tab, set a Start Date in the past on the 1st day of a month (e.g., 01/11/2025). 4. Confirm the subscription. 5. Create a draft invoice. Observation: ----------------------------------- In the invoice line, you see the message: `61 days 11/01/2025 to 12/31/2025` It should be: `1 Month 11/01/2025 to 11/30/2025` Issue: ----------------------------------- https://github.com/odoo/enterprise/blob/a5a76de5f25483afa5432ed333c48d78832f128c/sale_subscription/models/sale_order_line.py#L376-L378 In `_get_invoice_line_parameters`, the computation attempts to find the next 1st day of the month However, `new_period_stop` already includes the billing period. When `new_period_stop` is in the past, an extra month is added through `new_period_stop + relativedelta(months=1)`, resulting in an incorrect period range Solution: ----------------------------------- Use `new_period_start` as the anchor point for period computation. Ensure the billing period ends on the last day of the starting month when Align to Period Start is enabled For upsell orders, the fix is NOT applied because for upsells, `new_period_stop` is already set to the parent subscription's `next_invoice_date`, which represents the correct billing boundary. opw-5920036 Forward-Port-Of: odoo/enterprise#107407
This update ensures that users on MacOS can correctly post and edit messages in Odoo Chatter using the CMD-Enter key shortcut. Previously, the system displayed the outdated CTRL-Enter hint. This change improves the user experience for MacOS users and aligns the shortcut with the composer's functionality.
Original PR description
Recent commit changed the shortcut in MacOS for posting and editing message to CMD-Enter, instead of CTRL-Enter [1]. The hint was changed in the composer to post message, but the hint when editing message was still showing "CTRL-Enter" instead of "CMD-Enter", which this commit fixes. [1]: https://github.com/odoo/odoo/pull/248862 Task-6124496 Before / After <img width="904" height="116" alt="Screenshot 2026-04-15 at 14 04 34" src="https://github.com/user-attachments/assets/a7ad0450-f110-45b1-82c8-d6d251625ca1" /> <img width="894" height="119" alt="Screenshot 2026-04-15 at 14 03 53" src="https://github.com/user-attachments/assets/770b13b9-d882-4ea8-9fe3-f4b334de78ba" />
This update corrects a technical issue preventing Odoo from correctly identifying Swedish bank accounts. The fix adds a necessary decorator to the method used by the bank account widget, ensuring proper communication with banks. This resolves a potential error that could have impacted users in Sweden.
Original PR description
The override of `retrieve_account_type` was missing `@api.model`. (the same as Argentinian and Australian overrides) Since this method is called through RPC from the bank account widget, Odoo expected a model method signature. Without the decorator, the call could fail with a missing `acc_number` argument. Add the missing decorator so Swedish account number detection works properly. opw-6002770
This update fixes an error in how Odoo calculates the available capacity for appointments booked through Google Reserve. Previously, the system reserved the full party size for each resource, leading to overbooking. The fix ensures accurate capacity allocation, preventing double-booking and improving appointment scheduling efficiency.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016 Forward-Port-Of: odoo/enterprise#113908 Forward-Port-Of: odoo/enterprise#113805
This update ensures that the date range used to fetch transactions from iap is always accurate. Previously, incorrect dates could be used, leading to missing transactions. This change now uses the latest statement or statement line date, guaranteeing complete and reliable transaction retrieval.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update fixes a problem where the REAGYP compensation amount wasn't being correctly included in the deductible quota submitted to the Spanish tax authority (AEAT). The change ensures that all relevant tax deductions are accurately reported, improving compliance with Spanish regulations. A related test was updated to reflect the new calculation.
Original PR description
Currently, the deducible amount for REAGYP is not passing through to the AEAT. This happens because the REAGYP compensation amount (ImporteCompensacionREAGYP) was missing from the total deductible quota calculation in the SII JSON payload. To fix this, we add 'sujeto_agricultura' to the list that cheks if the tax value for l10n_es is in the list task-6072773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259232 Forward-Port-Of: odoo/odoo#256586
This update fixes an issue where recruitment officers couldn't view job tracker information. The change ensures officers have direct access to this feature through their designated role, simplifying the recruitment process and eliminating the need for additional employee permissions. This improves efficiency and streamlines workflows for the recruitment team.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install the `hr_recruitment` module 2. Create a new user and configure the following access rights: * Employees: No * Recruitment:…
Steps to reproduce:
----------------------------------------
1. Install the `hr_recruitment` module
2. Create a new user and configure the following access rights:
* Employees: No
* Recruitment: Officer Manage all applicants
3. Create new job position > Set created user in Recruiter
4. Log in with the created user
5. Go to Recruitment > Click on the Configure button of that job position
Observation:
----------------------------------------
The Trackers page is not visible on the job position form for the recruitment officer user.
If the user is additionally granted the Employees → Officer: Manage all employees group, the Trackers page becomes visible. The access to the recruitment Trackers should not depend on the Employee 'Officer: Manage all employees' access right.
Issue:
----------------------------------------
The visibility of the Trackers page depends on the Employees → Officer: Manage all employees group instead of the recruitment officer access rights
Solution:
----------------------------------------
Grant access to the Trackers page using the Recruitment Officer group so recruitment officers can access it without requiring the employee officer privileges
opw-5969416
Forward-Port-Of: odoo/odoo#252209This update fixes an issue where changing tax groups could cause errors due to account updates. The change prevents unnecessary account updates during tax group modifications, ensuring data consistency and preventing potential constraints. This improves stability and reduces the risk of errors when managing tax groups.
Original PR description
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g.…
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either. E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68). So here, we skip the update of relations to accounts on tax groups, if the account already exists. Forward-Port-Of: odoo/odoo#259160
This update fixes an issue where the event ticket download button wasn't appearing for orders processed with online payments. The fix ensures that necessary data is always set, regardless of the payment method, allowing users to download their tickets seamlessly after completing the purchase. This improves the customer experience for online event ticket sales.
Original PR description
**Steps to reproduce:** - Set up an event, go put it's state to Annonced - Set up any online payment method (Demo also triggers the bug) - Go to a PoS that sells the event tickets - Purchase one and…
**Steps to reproduce:** - Set up an event, go put it's state to Annonced - Set up any online payment method (Demo also triggers the bug) - Go to a PoS that sells the event tickets - Purchase one and pay with the online payment method - Once on the ticket screen, the button to download the event tickets is not displayed **Why the fix:** The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration. The problem is that with an online payment method, once we enter the **read_pos_data** method that sets the values for the frontend, the order is still in draft, so we just return without doing anything. We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment. In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed. A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed. opw-5438432 Forward-Port-Of: odoo/odoo#258986 Forward-Port-Of: odoo/odoo#249306
This update resolves a technical issue that prevented demo mode from functioning correctly after the addition of Peppol and Nemhandel response data. The fix ensures demo flows run smoothly by adapting the mock data, preventing errors and improving the demo experience.
Original PR description
With the recent addition of responses in Peppol and Nemhandel, we forgot to adapt the mocking data for demo flows, which resulted in tracebacks in demo mode. Forward-Port-Of: odoo/odoo#258655
This update corrects a bug in the Helpdesk module where priority filters weren't working correctly. A recent change caused the priority filter to become nested, leading to all tickets being displayed instead of just those with high or urgent priority. This fix ensures priority filters function as intended, improving ticket organization and prioritization.
Original PR description
Steps to reproduce: - Install Helpdesk. - Click on the High/Urgent priority filter. Issue: - All tickets are shown instead of only filtered priority tickets. cause: - Priority filter became nested after changes in pr https://github.com/odoo/enterprise/pull/105481 Fix: - Adjust the filter handling to correctly apply the nested priority filter domain. task-6089715
This update resolves a bug that caused the Time Off dashboard to crash when a new company or localization was created with no existing time off records. The fix prevents the system from attempting to fetch data when no data is available, avoiding a critical error.
Original PR description
Steps to reproduce: 1. Create a new company or install a localization (resulting in 0 time off records). 2. Open the Time Off overview (defaults to the Dashboard Gantt view). -> OwlError: Cannot…
Steps to reproduce: 1. Create a new company or install a localization (resulting in 0 time off records). 2. Open the Time Off overview (defaults to the Dashboard Gantt view). -> OwlError: Cannot destructure property 'type' of 'fields[fieldName]' as it is undefined. Cause: Following the recent work entries refactoring, the JS function `_fetchUserFavoritesWorkEntries` was added to the base `HrHolidaysGanttModel` to fetch data from the `hr.leave` model. When the Dashboard (`hr.leave.report.calendar`) has 0 records, the frontend `SampleServer` is activated to generate fake background data. It builds its schema based on the Dashboard view. When the JS unconditionally fires the cross-model RPC call to `hr.leave` (grouping by `work_entry_type_id`), the `SampleServer` intercepts it. Because it doesn't have `work_entry_type_id` in its Dashboard schema, it fails to evaluate the field type and crashes the Owl lifecycle. Solution: Restrict the `_fetchUserFavoritesWorkEntries` call in `_fetchData` so it only runs when not using sample data (`!this.useSampleModel`). This prevents the `SampleServer` from intercepting unsupported cross-model queries to `hr.leave` when loading empty views on fresh databases. task-5969290
This update fixes an issue where the Envia delivery integration incorrectly processed zip codes in Colombia. By using Envia's geocoding service, the system now accurately transmits the required municipality codes, ensuring correct delivery addresses and improving the reliability of shipments within Colombia. This resolves a previous data processing error.
Original PR description
For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code. When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`. Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally. opw-6083181 Forward-Port-Of: odoo/enterprise#112838
This update resolves an issue preventing users from generating session reports in the CO company setting. The fix addresses a technical error related to accessing sale details, ensuring the report generation process now functions correctly. This improves the usability of the point-of-sale system for CO businesses.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update resolves a bug where the state of a date field in forms was incorrectly being reset after saving. Typing a date into the field and saving would sometimes revert to a previous value. The fix ensures the date field's state is correctly updated immediately after the datepicker is closed, preventing data inconsistencies.
Original PR description
Step to reproduce: - Go on view form with a date field - Set the date with the input by typing the date with day and month (mm/dd or dd/mm), then press enter - Save the record - Redo the second step by with a different date - Save the record The assignation of the state.value done when closing the datepicker is useless and can put old a value in the state. The datepicker hasn't finished to update of the record that the assignation put back the old value of the record back in the state. The reason why it happens only after a save is still unknown. task-6095467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258111
This update fixes an issue where the 'My department' filter in holiday reporting was incorrectly showing employees with past versions of their department assignments. The change now only considers current department assignments, ensuring accurate holiday reporting for all employees. This improves the reliability of time-off data.
Original PR description
Reproduce the issue: - Create an employee linked to a user with department A - Create a second employee with 2 versions: - a past one with department A - a current one with department B - create a leave for both employees - go to Time Off > Overview, keep the group by employee and select the filter "My department" - both employee appear Before this commit, the search on "member_of_department" was looking for all versions with a similar department (same or child of) regardless of the version validity. This commit limits that search to current versions only task-6076014 Forward-Port-Of: odoo/odoo#256388
This update fixes a problem where combo prices were incorrectly doubling when multiple items were added to a sale. The change ensures that free items and parent unit prices are accurately recalculated during pricelist updates, resulting in correct pricing for combo orders. This improves the reliability of point-of-sale transactions.
Original PR description
Fix combo prices doubling when quantity > 1 during pricelist changes. Correctly scale free items in 'getFreeAndExtraChildLines' and ensure parent unit prices are updated in 'setPricelist'. task-id: 5971935 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250666
This update resolves an issue where the system was incorrectly calculating payroll neutralization in Switzerland. The fix ensures accurate reporting of neutralized amounts, which is crucial for compliance with Swiss tax regulations. This change improves the reliability of payroll data for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#113961
This update resolves an issue preventing accurate filtering of partner commission data within reports. The fix ensures that reports now correctly display commission information based on specified criteria, improving the reliability of sales and financial reporting. This change enhances data accuracy for business users.
This update corrects a technical issue within the phone dashboard's data configuration. The previous revision ID was incorrect, preventing the dashboard from functioning properly. This fix ensures the dashboard accurately reflects the latest phone system information.
Original PR description
`revisionId` should be `START_REVISION`. Commit f56e6431ea1e2f66610a833bd3d76107171a6e61 updates phone dashboard but with a wrong revisionId. Task: 0
This update resolves a technical problem preventing the Worldline feature from working correctly when used with virtual IoT. The system was incorrectly searching for necessary files, and this change ensures those files are properly created, allowing the Worldline functionality to operate as intended.
Original PR description
This PR fixes the paths for worldline when used with virtual iot. Currently we are looking for the .dll libraries in "ctep" folder but it's never created. opw-6102627
This update resolves an issue where appraisers without full access to the appraisal module couldn't add other appraisers. The fix utilizes record IDs for comparison, ensuring accurate determination of appraisal management rights. This improves usability for all users involved in the appraisal process.
Original PR description
When you are an appraiser but don't have access rights on appraisal module. You should be able to add other appraiser to the apprasial. This depends on the field 'is_manager', which is computed and triggered by the modification of appraisers. In the compute of this field we are comparing the m2m employee records and the employee_ids of the current user. This doesn't work in the context of an onchange because we have 'New' records with the origin_id, so we need to use the records ids for comparison which always works.
This update fixes a minor issue where users couldn't fully expand options for social media sharing links. The change allows users to unfold options for both the original shared item and any parent items, providing a more complete and user-friendly experience when sharing content.
Original PR description
Commit 10e87773afb92c67ee126460bb899b358869345e added the possibility to unfold the options of an ancestor of the target (in addition to the target's options). This commit adds that behavior to unfold the `s_share` snippet's options when the user clicks on one of the icon inside. task-5999383
This update fixes an issue where action buttons in email notifications (like 'View Quotation') were not consistently translated for recipients in different languages. The change ensures the correct language context is used when preparing email content, resulting in fully translated buttons for all users.
Original PR description
When sending a quotation or sales order via email to a follower, the action button in the notification (e.g., "View Quotation") was appearing partially translated in the recipient's language. The issue came from the document description being explicitly evaluated using the sender's language context usually English) during the email composition phase, so it could not be correctly re-translated by the mail engine when rendering the final layout for a recipient using a different language. This commit allows the language context to be dynamic when preparing the document description for the email composer, ensuring the action button is fully and accurately translated. --- opw-5976084 Forward-Port-Of: odoo/odoo#257349 Forward-Port-Of: odoo/odoo#256077
A visual bug causing grey overlays on published course cards with descriptions has been resolved. This change ensures that published courses with buttons or other elements in their descriptions no longer display the overlay. The fix corrects a selector issue that incorrectly targeted all course cards.
Original PR description
Steps to reproduce: ================= 1. Go to eLearning > Courses and create a published course 2. In the Description tab, add a button with a link and save 3. Go to /slides on the website 4. The…
Steps to reproduce: ================= 1. Go to eLearning > Courses and create a published course 2. In the Description tab, add a button with a link and save 3. Go to /slides on the website 4. The course card appears with a grey overlay (0.5 opacity) => Published course cards with a button in the description show a grey overlay => Only unpublished course cards should have the grey overlay Cause: ====== In [1], the opacity for unpublished courses was moved from `.o_wslides_course_unpublished` to its container using a `:has()` selector. However, the selector `div:has(> .card + .card-body, ...)` was too broad: it matched any container whose `.card` child had a sibling `.card-body`, regardless of whether the course was unpublished. When a course description contains a button (or any block-level element), the browser renders the button outside the `.card` element. This creates the structure `div > .card + .card-body` that the selector matches, applying a 0.5 opacity grey overlay to fully published courses. Solution: ======== The fix restricts the first selector arm to only match when `.o_wslides_course_unpublished` is the sibling, ensuring published courses with buttons in their descriptions are not affected. [1]: https://github.com/odoo/odoo/pull/249969 opw-5900287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258700
This update ensures the 'send by Peppol' option in the accounting system is only available for companies that are actually registered on the Peppol network. Previously, it was incorrectly enabled, leading to potential confusion. This change improves accuracy and aligns the system with registration requirements.
Original PR description
Previously, the send wizard would automatically enable the send "by Peppol" option whenever Peppol was available for the company's country. This behavior was misleading, as it didn't check whether the company was actually registered on Peppol. This commit ensures the option is only enabled for companies that are registered on Peppol. task-6044073 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258731 Forward-Port-Of: odoo/odoo#254671
This update fixes an issue where the web interface could incorrectly access data due to cached information after a user update. The change ensures that data accessed through the web interface always respects current user permissions, preventing potential access errors and improving data consistency. This enhances the reliability of user-related features.
Original PR description
**Description of the issue/feature this PR addresses**: web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record…
**Description of the issue/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).
**Example**:
- **Context**:
- Two companies exist: Company A and Company B.
- Two users exist: User A and User B.
- User A can only access Company A (company_ids=[A], company_id=A).
- User B is linked to both companies (company_ids=[A, B], company_id=A).
- The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
- User A edits User B and saves the form.
- **Steps**:
- User A performs a web_read to load User B: company_ids contains only Company A.
- User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.
**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.
**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.
Forward-Port-Of: odoo/odoo#257517
Forward-Port-Of: odoo/odoo#250904This update corrects a bug in Odoo's stock accounting calculations (AVCO) that occurred when products lacked stock movements. The fix prevents a system error, ensuring the accurate processing of inventory data. This improves overall system stability and reliability.
Original PR description
PR [247625](https://github.com/odoo/odoo/pull/247625) improved performance of the AVCO computation with `_run_average_batch()`. However, it's currently possible that the method returns an empty dictionary if a product does not have any stock move associated with it. It then raises a traceback in `_run_avco()` because we expect the dictionary to always hold the product id keys. Ticket: opw-5951133 Forward-Port-Of: odoo/odoo#249735
This update fixes a discrepancy in the 'To Pay' dashboard by ensuring it now accurately reflects all outstanding payments, including receipts, in addition to invoices and refunds. Previously, the dashboard metrics didn't match the details visible in the action view, leading to potential confusion for users. This change ensures a more reliable view of outstanding payments.
Original PR description
- The "To Pay" section in the purchase/sales dashboard was only considering invoices(`in_invoice` and out_invoice) and refunds(`in_refund` and `out_refund`) when computing the number and amounts to pay. - However, the corresponding action view includes receipts (`in_receipt` and `out_receipt`), leading to an inconsistency where the dashboard count and amount did not match the records shown after clicking. - This commit updates the dashboard query to also include receipts, ensuring consistency between the displayed metrics of the coreesponding purchase/sales dashboard and the action view. Related PR: https://github.com/odoo/enterprise/pull/111142 taskID-6040828 Forward-Port-Of: odoo/odoo#259245 Forward-Port-Of: odoo/odoo#254295
This update fixes an issue where Backspace within a blockquote would unexpectedly remove the blockquote content. Now, Backspace correctly removes inner content, allows list creation inside blockquotes, and resolves issues with trailing line breaks after tables. This enhances the usability of the HTML editor for creating and editing rich text content.
Original PR description
Description of the issue this PR addresses: - Pressing Backspace inside a blockquote that has visible content but no text content removes the blockquote instead of the content. The content (image or table) gets moved outside of the blockquote. - Trailing BR was kept after tables because tables are marked as unsplittable blocks. This left unnecessary BR nodes after tables in blockquote. - Lists could not be created inside a `blockquote`. Desired behavior after PR is merged: - Backspace removes the inner content first when blockquote contains nodes. - Trailing BR is removed when placed table inside blockquote. Cursor can still be placed at the edge of the table without requiring a BR anchor. - Lists can be created directly inside a blockquote. task-5864080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259132 Forward-Port-Of: odoo/odoo#245011
This update resolves a problem where Odoo invoices sent via Peppol were being rejected due to incorrect tax calculations. The fix ensures that the TaxableAmount is consistently calculated across all tax categories, including those with discounts and fractional prices, aligning with Peppol's requirements.
Original PR description
Steps to reproduce: 1. Create an invoice with a 0% tax (Exempt from VAT, category E) 2. Add two lines with 20% discount and fractional prices: - qty=4, price_unit=39.615 and qty=4 with…
Steps to reproduce: 1. Create an invoice with a 0% tax (Exempt from VAT, category E) 2. Add two lines with 20% discount and fractional prices: - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84 3. Send via Peppol 4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc. When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection. Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally. opw-6093243 Forward-Port-Of: odoo/odoo#258909
This update resolves an issue where the font size displayed in the toolbar for nested lists wasn't correctly reflecting the parent list's custom font size. The fix ensures that sub-items always use the intended default font size, improving consistency and usability of the HTML editor.
Original PR description
Problem: When using nested lists where a parent list item has a custom font size, the child list does not display the default font size in the toolbar. Cause: `getFontSizeDisplayValue` does not treat `.o_default_font_size` as a boundary element. It continues searching up the DOM and may retrieve a font size from a parent element outside the intended default font size scope. Solution: Stop the font-size lookup when reaching `.o_default_font_size`, since this class defines the default font size boundary. Steps to reproduce: - Go to a "To do" note. - Insert a bullet list with sub-items. - Select the top list item and set its font size to 72. - Select a sub-item. - Observe the toolbar does not show the default font size. task-6105581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258027
This update corrects a bug where scrap items weren't properly removed when discarding insufficient quantities in the inventory adjustments process. The fix ensures that scrap moves are only unlinked during the specific 'scrap' action, preventing unintended data changes. This improves data accuracy and stability within the inventory management system.
Original PR description
**Steps to Reproduce:** - Install Inventory with demo data. - Inventory > Operations > Adjustments > Scrap. - Create a new scrap with product 'Large Cabinet' and quantity 1000. - Click Confirm > (In the warning wizard) Click Discard> Click Confirm. **Error:** `ValueError - Expected singleton: stock.move()` Before 19.2; Since https://github.com/odoo/odoo/commit/c361c3778ef4755b4760039a4fd8f9ed88294b64, in the Shop Floor flow (`button_scrap`), the scrap is created first, and discarding an insufficient warning will unlink the scrap order. However, when using the scrap form view (via adjustments), the scrap was not unlinked on discard. Later https://github.com/odoo/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba, the condition was removed during refactoring, causing the scrap move is to be unlinked in all flows. Fix: This commit adds a context key to ensure that the scrap move is only unlinked in the `action_scrap` flow. sentry-7336640883
This update corrects a problem where product images weren't consistently being removed from the website. The change ensures the image is fully loaded in the browser before the removal button is clicked, preventing display issues. This improves the user experience for product browsing.
Original PR description
With this commit, we fix tours: - website_sale.remove_main_product_image_with_variant - website_sale.add_and_remove_main_product_image_no_variant where we want to remove the product image. This fix add a step to ensure the image is in DOM before clicking on the remove button. error-runbot-id~237766 Forward-Port-Of: odoo/odoo#259121 Forward-Port-Of: odoo/odoo#244544
This update corrects a bug where the builder range input's value increased by only 1 when adjusting with the number input. The fix ensures the builder range's specified 'step' value is correctly applied, providing accurate control over builder range settings. This improves the overall usability and precision of the builder tool.
Original PR description
The props "withNumberInput" for builder range added a number input next to the slider, to fine tune the value. However, the min / max / step props were not given. Therefore if the user pressed arrow up in the number input, the value would increase by 1, instead of the value of step given to the builder range input. This commit fixes the issue by giving the correct props to the builder number input. Forward-Port-Of: odoo/odoo#247198
This update resolves a visual glitch on the Odoo shop page where product images would overlap with popup content when popups were positioned with 'sticky' styling. The fix prevents popups from being placed within elements with 'sticky' positioning, ensuring proper display and a consistent user experience.
Original PR description
If an popup is dropped within an element with the property "position" set to "sticky", there would visual issues with the modal. For example, if the user drop a popup below the filters in the /shop page, the images of the product would appear over the popup content when the popup is opened. Since there shouldn't be cases where "position" is setted to sticky without having the specific class, this commit fixes the issue by adding the selector ".position-sticky" as a forbidden ancestor for popups. task-5411329 Forward-Port-Of: odoo/odoo#240545