Daily updates from Odoo
Thursday, April 16, 2026
160 changes
28 changes
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#25090416 changes
Resolved issues and error corrections
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 dates. This prevents invoicing discrepancies and improves financial reporting.
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 corrects a flaw in how Odoo calculates the available capacity for appointments booked through Google Reserve. Previously, the system reserved the entire party size, leading to potential overbooking. The fix ensures accurate capacity allocation, preventing scheduling conflicts and improving the booking experience for users.
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 transaction dates pulled from iap are always within the correct 'lock date' range. Previously, transactions could be retrieved with dates before the lock date, which was an error. Now, the system uses the maximum of the lock date and the last statement date to guarantee accurate data 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 an issue where the Envia integration for Colombia was incorrectly formatting zip codes. By using Envia's geocoding service, the system now accurately transmits the required municipality codes, ensuring correct delivery processing. This resolves a previous error that caused incorrect zip code formatting and potential delivery problems.
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 corrects a visual issue where clickable scorecards in the spreadsheet module were displaying a default arrow cursor instead of a pointer on hover. Now, scorecards that function as buttons in the dashboard view correctly show a pointer cursor when hovered over, improving user experience and clarity. This resolves a minor usability problem.
Original PR description
## Description of the issue/feature this PR addresses: Current behavior before PR: - The scorecard case was missed when replacing hasOdooMenu with hasOdooLink. - Clickable scorecards were showing the default arrow cursor instead of a pointer on hover. Desired behavior after PR is merged: - Scorecards now correctly use hasOdooLink to determine if they are clickable. - The pointer cursor is displayed on hover when the scorecard acts as a button in dashboard view. Task: [6116584](https://www.odoo.com/odoo/2328/tasks/6116584) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the calculation of neutralized payroll amounts was inaccurate in the Swiss HR Payroll module. The fix ensures that payroll deductions are correctly processed, leading to more precise financial reporting and compliance with Swiss tax regulations. This improves the reliability of payroll data.
This update resolves an issue preventing users from generating session reports in the CO company setting. The fix addresses a technical problem with accessing sale details, ensuring the report generation process now functions correctly. This improves the usability of the POS system for CO companies.
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. Specifically, closing the date picker would sometimes revert the date back to an older value. This issue has been fixed to ensure accurate date tracking and prevent 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 Arabic text on invoices was incorrectly formatted in the generated PDF. The change ensures parentheses surrounding Arabic characters are positioned correctly, improving readability for invoices in English. This resolves a display problem for international invoices.
Original PR description
**Problem:** When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in…
**Problem:** When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in the wrong position in the generated PDF. **Steps to reproduce:** 1. Create a product named: لوحة توزيع كهربائية 100 أمبير (شنايدر ) 2. Create an invoice with that product 3. Print the invoice PDF in English 4. Observe the brackets are misplaced in the description column **Current behavior:** Parentheses appear detached from the Arabic word they enclose, floating at the wrong end of the text. **Expected behavior:** Parentheses correctly wrap the enclosed Arabic text. **Cause of the issue:** Odoo's report CSS sets `direction: ltr` on elements that are ancestors of the line description span. When CSS `direction: ltr` targets the same element as `dir="auto"`, wkhtmltopdf's WebKit engine lets the CSS rule win, keeping the paragraph base direction as LTR. The Unicode BiDi algorithm then resolves parentheses (neutral characters) using LTR as the base direction, misplacing them. **Fix:** Placing `dir="auto"` directly on the `<span>` that renders the line description — rather than the parent `<td>` — avoids the CSS override. wkhtmltopdf then detects the first strong character (Arabic) and uses RTL as the base direction for that span, allowing the BiDi algorithm to correctly position the brackets. opw-5884712 Forward-Port-Of: odoo/odoo#258521 Forward-Port-Of: odoo/odoo#251190
This update fixes a performance issue in the website's gradient picker. Previously, dragging the angle knob triggered excessive updates, causing lag. The fix now delays SCSS generation until the drag is complete, resulting in a smoother and faster editing experience.
Original PR description
Cause: ====== Because the debounce function is called with await, the execution of `debouncedSCSSColorsCusto` pauses for every mousemove event. This prevents subsequent calls from overlapping,…
Cause: ====== Because the debounce function is called with await, the execution of `debouncedSCSSColorsCusto` pauses for every mousemove event. This prevents subsequent calls from overlapping, meaning the debounce logic never triggers to cancel previous timers. This results in the heavy SCSS generation running sequentially for every single mouse movement, causing performance lag. In other words, the await forced the browser to handle one request at a time, completely finishing it before accepting the next one. Solution: ========== In the gradient picker, only update the visual CSS gradient preview during drag and defer the `onGradientChange` callback to mouseup to avoid triggering heavy operations (e.g. SCSS generation) on every mousemove. Steps to reproduce: =================== 1. Go to website & edit mode. 2. Click on Header block. 3. Click on background color preview & select Gradient & Custom. 4. Click and drag the Angle knob. => The website preview triggers excessive updates dragging the knob opw-5411628 Forward-Port-Of: odoo/odoo#241764
This update resolves an issue where published course cards with buttons in their descriptions were displaying a grey overlay. The fix accurately targets only unpublished courses, ensuring a consistent and correct visual presentation of all course cards on the website. This improves the user experience and visual consistency.
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 resolves an issue where double-clicking on a message action menu in Odoo kept displaying the same menu. Now, a second right-click on the message will trigger the browser's standard context menu, providing users with more flexibility and control over actions. This improves usability and caters to user workflows.
Original PR description
Before this commit, when message actions are displayed from right-click, triggering a right-click on the message again would keep displaying the message actions. Right-click on message to show the actions is useful in many cases, but sometimes the user wants to trigger the browser context menu. Currently browser context menu is shown on links and when there are some text selection, but there might be some other potential cases where seeing the browser context menu is desirable. In practice users could trigger it through SHIFT + right-click but they are not necessarily aware of it. This commit let double right-click on same message open the browser context menu, so that if users really want to have the browser context menu then doing it twice will show it. Before  After 
This update ensures that table assignments are consistently synchronized across all devices within a POS session. Previously, a waiter marking a table as occupied on one device wouldn't reflect that status on other devices. The fix also improves synchronization by treating table-based orders as 'pending', ensuring immediate updates.
Original PR description
When a waiter selects a table without adding any items and returns to the floor screen, the table appears as occupied (green) on their device but not on other devices in the same POS session. Steps to reproduce: ------------------- * Open POS session on device A * Open same POS session on device B * On device A: click a table, don't add items, go back to floor * On device B: observe the table does not appear as occupied > Observation: Empty table assignments were not being synced to the server, so other devices couldn't detect the table occupancy. Why the fix: ------------ Also treat orders with a table_id as pending so they sync immediately when a table is opened. The backend already supports this: pos.order can be created with just table_id, and pos_restaurant._get_open_order looks orders up by table_id for table-based sync. opw-5236119 Forward-Port-Of: odoo/odoo#241321
This update fixes a limitation where users couldn't edit images on product pages after replacing them. The change ensures that image editing options are displayed correctly only when the image is newly uploaded, preventing confusion and improving the user experience for updating product visuals. This ensures consistent functionality across the eCommerce platform.
Original PR description
## Context On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it. ## Issue When uploading a new picture, users can only…
## Context On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it. ## Issue When uploading a new picture, users can only replace the image or reorder it, but they cannot reshape it, crop it, or edit its size. ## Steps to reproduce 1. Install the *eCommerce* (`website_sale`) app. 2. Create a product and set a picture for it. 3. Go to that product's page in the Website app and open the website editor. 4. Click on the picture and replace it. 5. **The options to transform the picture are not displayed.** ## Cause The transformation options are disabled due to the following static `exclude` variable in `ImageToolOption`: https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/html_builder/static/src/plugins/image/image_tool_option.js#L16 ## Solution We should prevent the transformation options from being displayed **only** when the image is external. In such cases, certain options from the `ImageToolOption` (such as the `ImageTransformOption` or the `ImageShapeOption`) cannot be applied. This is confirmed by the message displayed when trying to crop an external image: https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/web_editor/static/src/js/wysiwyg/widgets/image_crop.js#L164-L173 We can determine whether an image is external by looking at its `data-attachment-id` property. If it is present, the image was recently uploaded to Odoo. On top of updating the `exclude` variable, we need to filter out the options that cannot be used on images from the eCommerce. These options are: - Description - Tooltip - Transform (*"Transform the picture"*) - Size ## Tests The test checks that the behavior matches the one from previous versions: the options to edit an image are not displayed before replacing the image, but are displayed after. Both the test `image field should not be editable, but the image can be replaced` (shown below) and the new test from this PR fail if the modified `exclude` variable allow to edit the image before replacing it. https://github.com/odoo/odoo/blob/dea5a1d28a1935c2b4d87c3c6e8c07cd874c7d6b/addons/html_builder/static/tests/image_field.test.js#L7-L16 ## Options displayed | | Before this commit | After this commit | Previous versions | |---|---|---|---| | **Before replacing the image** | Media, Re-order | Media, Re-order | Media, Re-order | **After replacing the image** | Media, Re-order | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality opw-5251864 Forward-Port-Of: odoo/odoo#247539 Forward-Port-Of: odoo/odoo#241071
This update ensures the Peppol sending option in the account system is only available for companies that are actually registered on the Peppol network. Previously, it automatically enabled this option, which was misleading and inaccurate. This change improves data accuracy and ensures compliance.
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 ensures that payments registered in the future are not processed according to Mexican government regulations (CFDI). The system now filters out future payments, removing the 'Update Payments' button when only future payments are present, ensuring compliance and avoiding potential errors.
Original PR description
To sign a payment registered in the future is not allowed by the government. See http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Guia_llenado_pagos.pdf Steps: - Create a PDD invoice (the due date should be at least 1 month later than the invoice date) - Send it to CFDI - Register a payment in the future -> We have the 'Update payments' button that appear on the invoice view, if you clik on it the payment will be signed With this commit, we filter out the payments with a future date, that way we don't have the 'Update Payments' button if there are only future payments, or the future payments won't be taken into account when clicking on the button. opw-5934753 Forward-Port-Of: odoo/enterprise#113945 Forward-Port-Of: odoo/enterprise#112320
7 changes
Resolved issues and error corrections
This update resolves a technical problem within the AI composer patch that was causing crashes. The fix ensures the focus event is correctly passed to the base handler, maintaining stability and preventing errors when the AI composer is used. This improves the overall reliability of the AI composer functionality.
Original PR description
**Purpose of this PR:** The AI composer patch overrides `Composer.onFocusin()` but did not forward the focus event to the base handler. This used to be harmless while the base mail composer focus handler did not use the event. Since odoo/odoo#258974, the mail composer now uses the event to stop `focusin` propagation, so dropping it makes the base handler crash when AI composer focus is triggered. This commit fixes the AI composer patch by forwarding the focus event to the base handler, preserving the expected handler contract. Related: odoo/odoo#258974 Task-5954657 Forward-Port-Of: odoo/enterprise#113763
This update ensures that transaction data pulled from iap uses the correct date range. Previously, incorrect date ranges could occur, leading to inaccurate reporting. This fix now uses the latest statement or statement line date, guaranteeing accurate data 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 resolves an issue preventing users from generating session reports in the CO company setting. The fix corrects a technical error related to accessing sale details, ensuring the report generation process now functions correctly. This improves the usability of the POS system for CO company users.
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 an issue where the checkout process became unresponsive when using Avatax with Brazilian tax identification. The previous code was unnecessarily calling external tax APIs, leading to errors that blocked the confirmation step. This fix removes the unnecessary API call, improving checkout stability and performance.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#113861 Forward-Port-Of: odoo/enterprise#112515
This update ensures that payments registered in the future are not processed according to Mexican tax regulations (CFDI). The system now filters out future payments, removing the 'Update Payments' button when only future payments are present, preventing incorrect tax signing and maintaining compliance.
Original PR description
To sign a payment registered in the future is not allowed by the government. See http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Guia_llenado_pagos.pdf Steps: - Create a PDD invoice (the due date should be at least 1 month later than the invoice date) - Send it to CFDI - Register a payment in the future -> We have the 'Update payments' button that appear on the invoice view, if you clik on it the payment will be signed With this commit, we filter out the payments with a future date, that way we don't have the 'Update Payments' button if there are only future payments, or the future payments won't be taken into account when clicking on the button. opw-5934753 Forward-Port-Of: odoo/enterprise#113945 Forward-Port-Of: odoo/enterprise#112320
This update fixes a potential issue where the year for payroll reports was defaulting to the current year, causing test failures. The change ensures the correct year is always referenced, preventing future errors and maintaining accurate reporting. This improves the reliability of payroll calculations.
Original PR description
Making sure we set the reference year when exporting the sd_worx report as if not stated it will call the current year and this will cause the test failing in future builds runbot-242148 Forward-Port-Of: odoo/enterprise#112325
This update resolves an issue where POS users with limited access rights were unable to fully close their Fiskaly VAT resolution sessions, requiring administrator privileges. The fix simplifies the process by removing unnecessary checks for API credentials, ensuring a smoother user experience for POS users handling Fiskaly transactions. This improves the reliability of the POS system for German customers using Fiskaly.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960 Forward-Port-Of: odoo/enterprise#112618
18 changes
Resolved issues and error corrections
This update resolves an issue 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 a Peppol document would repeatedly be created when a user removed their journal configuration. The fix ensures that acknowledgements are correctly sent to IAP, preventing unnecessary document duplication and improving the reliability of Peppol document processing. This ensures accurate data exchange and avoids potential delays.
Original PR description
When a user removes its journal on its Peppol configuration, when receiving one, a new document would be created but the acknowledgement would never be sent to IAP. Everytime the user tries to retrieve new documents, the same document would then be created again. Forward-Port-Of: odoo/odoo#259330
This update resolves an issue where a new Peppol document was incorrectly created and repeatedly generated when a user removed their journal configuration. The fix ensures that acknowledgements are properly sent to IAP, preventing duplicate document creation and improving the reliability of the Peppol integration.
Original PR description
When a user removes its journal on its Peppol configuration, when receiving one, a new document would be created but the acknowledgement would never be sent to IAP. Everytime the user tries to retrieve new documents, the same document would then be created again. Forward-Port-Of: odoo/enterprise#113922
This update resolves an error that occurred when users tried to access ticket links after an attendee was removed from an event. The fix prevents a technical error (IndexError) by gracefully handling empty attendee lists, ensuring ticket links always work correctly.
Original PR description
Currently, an error occurs when accessing the ticket link after the related attendee has been deleted. **Steps to Reproduce:** - Install the **Events** module. - Create a new event. - Create an attendee with a valid email ID. - Make sure the email is sent successfully. - Delete the attendee for the event. - From the received email, try to click on the **"View Tickets"** link. **Error:** `IndexError - tuple index out of range` **Cause:** The controller filters registrations using the provided `registration_ids`, but when the attendee is deleted, the resulting recordset becomes empty. It raises an error when trying to access the first element of an empty recordset. **Fix:** This commit handles empty recordsets by returning early when no registrations are found. sentry-7357927405
This update fixes an issue where transaction date ranges were sometimes inaccurate when importing data from Codabox. The change ensures that the date range used for importing transactions is always the latest available date – either the Codabox lock date or the last statement date – preventing data discrepancies.
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 simplifies the process of reloading your chart of accounts. Previously, a confusing error message prompted users to update the localization app. Now, a clear warning directs users directly to the relevant apps, making the process easier and more intuitive.
Original PR description
Previously, when new taxes with new tax tags were introduced, reloading the chart of accounts would raise a generic UserError suggesting to update the localization app. This could be confusing for users, as it did not indicate which app needed to be updated. With this commit, the UserError is replaced by a RedirectWarning that guides users directly to the Apps menu with the relevant localization modules, making the resolution clearer and more user-friendly. Forward-Port-Of: odoo/odoo#259398 Forward-Port-Of: odoo/odoo#257515
This update fixes an issue where tax group changes could cause errors due to account updates not being synchronized. The change ensures that account relationships within tax groups are only updated when necessary, preventing constraint violations and improving system stability. This primarily impacts how tax groups are managed and related to accounts.
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 resolves a technical issue that prevented demo flows from running correctly when new Peppol and Nemhandel response data was added. The team corrected a missing key in the demo utility files, ensuring demo mode now functions without errors. This improves the reliability of our demo environment.
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 fixes an issue where floors were incorrectly displayed in the restaurant's point-of-sale system. Previously, floors were loaded through indirect processes, leading to inaccurate floor selections. Now, the system correctly uses the configured floor IDs for each POS configuration, ensuring accurate floor selection for restaurant orders.
Original PR description
Floors loaded indirectly (e.g. via recursive loading of paid orders) could appear in the floor selector even if they belonged to a different PoS config. The selector was iterating over the full in-memory model store instead of the floors explicitly assigned to the current config. opw-6025172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258178 Forward-Port-Of: odoo/odoo#257113
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 POS system for CO companies.
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 removes a confusing tooltip from the calendar popover for boolean fields. The tooltip was displaying unnecessary HTML content, creating a poor user experience. This change simplifies the calendar interface and improves usability.
Original PR description
Before this commit, the tooltip of a boolean field in calendar popover shows html content when the user hovers the boolean field. This commit removes the tooltip of boolean field in calendar popover since the information inside that tooltip is not really useful for the user. Issue found during the development of task-5994205 Forward-Port-Of: odoo/odoo#259069 Forward-Port-Of: odoo/odoo#259011
This update resolves an issue where images on the website weren't displaying correctly on deeper pages. The fix adds missing forward slashes to image source URLs, ensuring the browser correctly interprets them. This ensures all website images, including those on product pages, display properly.
Original PR description
This commit fixes two missing leading slashes in the "src" attribute of two "img" tags in `s_cta_mockups`. The browser resolves links differently based on leading slashes. Before this commit, the lack of leading slahses caused the snippet to not display properly on deeper pages (for example, "/shop/product-name"). task-6103616 Forward-Port-Of: odoo/odoo#258879
This update resolves an issue where the Avatax integration in the express checkout process was causing the confirmation button to become unresponsive. The fix removes unnecessary external API calls related to tax calculations, streamlining the checkout flow and improving stability. This change addresses a bug related to error handling during tax calculations.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/odoo#259229 Forward-Port-Of: odoo/odoo#256692
This update resolves an issue where the checkout process became unresponsive when using the Avatax module with the Brazilian localization. The previous code was unnecessarily calling external tax APIs, leading to errors and preventing users from completing their purchases. This fix removes the unnecessary API calls, restoring the checkout functionality.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#113861 Forward-Port-Of: odoo/enterprise#112515
This update resolves a technical error that prevented users from selecting a store when the store's address information (city or street) was incomplete. The fix ensures the system correctly handles missing address details, improving the reliability of the Click & Collect feature. This prevents errors and ensures a smoother shopping experience for customers.
Original PR description
Issue: --- An owl error is raised in select store if the store's company location lacks city or street. Steps to reproduce: 1- Enable Click and Collect. 2- In pickup locations, set a company with an address with empty street or city. 3- Go to the shop. 4- Enable debug mode. 5- Select store. An owl error is raised due to not city and street not being string. opw-6050137 Forward-Port-Of: odoo/odoo#259164
This update addresses a regulatory requirement in Mexico (CFDI) that prohibits signing payments registered in the future. The code now filters out future payments, removing the 'Update Payments' button when only future payments are present. This ensures compliance and avoids potential issues with government regulations.
Original PR description
To sign a payment registered in the future is not allowed by the government. See http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Guia_llenado_pagos.pdf Steps: - Create a PDD invoice (the due date should be at least 1 month later than the invoice date) - Send it to CFDI - Register a payment in the future -> We have the 'Update payments' button that appear on the invoice view, if you clik on it the payment will be signed With this commit, we filter out the payments with a future date, that way we don't have the 'Update Payments' button if there are only future payments, or the future payments won't be taken into account when clicking on the button. opw-5934753 Forward-Port-Of: odoo/enterprise#113945 Forward-Port-Of: odoo/enterprise#112320
This update fixes a potential issue where the SD Worx payroll report was defaulting to the current year, leading to test failures. The change ensures the correct year is always referenced, preventing future problems and ensuring accurate reporting. This improves the reliability of payroll data.
Original PR description
Making sure we set the reference year when exporting the sd_worx report as if not stated it will call the current year and this will cause the test failing in future builds runbot-242148 Forward-Port-Of: odoo/enterprise#112325
This update resolves a visual inconsistency where styling applied to images (like rounded corners or shadows) was incorrectly carried over when users replaced images with icons in the To-do app. Now, the system automatically removes these styling classes, ensuring icons appear with their intended, clean design. This improves the overall user experience and consistency of the application.
Original PR description
### Steps to Reproduce: - Go to the To-do app and create a new task. - Upload an image. - Apply shape styling to the image (e.g., rounded, shadow, img-thumbnail). - Replace the image with an icon. ### Description of the issue/feature this PR addresses: - When an image had shape applied (such as rounded, rounded-circle, shadow, or img-thumbnail) and was replaced with an icon, those classes were carried over to the icon. ### Desired behavior after PR is merged: - Since these classes are specific to image shape styling, they are now removed when an image is replaced with an icon. task-6007631 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258060
5 changes
Resolved issues and error corrections
This update resolves an issue where barcode quantities were displayed with slight rounding errors due to how JavaScript handles decimal numbers. The fix ensures accurate quantity representation in the barcode interface, preventing discrepancies in inventory tracking. This improves data reliability for warehouse operations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to Settings and enable: * Storage Locations (Warehouse). * Batch, Wave & Cluster Transfers. * Create a Product and set its on-hand quantity to…
**Steps to reproduce:**
* Install `stock` module.
* Go to Settings and enable:
* Storage Locations (Warehouse).
* Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
* Set Type of Operation to Internal Transfer.
* In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
* Select the newly created Operation Type.
* Add the created Product with quantity 4.4.
* Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
* Select the same Operation Type.
* Add the same Product with quantity 48.8.
* Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
* Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.
**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).
**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:
https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205
- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.
**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats
- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.
---
opw-5932329
Forward-Port-Of: odoo/enterprise#110241This update resolves a recurring problem where a new Peppol document was incorrectly created when a user removed their journal configuration. Previously, acknowledgements weren't sent, leading to duplicate document creation. This fix ensures proper acknowledgement transmission, streamlining Peppol document processing.
Original PR description
When a user removes its journal on its Peppol configuration, when receiving one, a new document would be created but the acknowledgement would never be sent to IAP. Everytime the user tries to retrieve new documents, the same document would then be created again. Forward-Port-Of: odoo/enterprise#113922
This update resolves an issue preventing users from generating session reports within the CO company's point-of-sale system. The fix ensures that sale details are correctly retrieved, allowing users to accurately track sales data. This improves the reliability of the CO company's financial reporting.
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 fixes a potential issue where the year for payroll reports was defaulting to the current year, causing test failures. The change ensures the correct year is always referenced, preventing future problems and maintaining accurate reporting. This improves the reliability of payroll calculations.
Original PR description
Making sure we set the reference year when exporting the sd_worx report as if not stated it will call the current year and this will cause the test failing in future builds runbot-242148 Forward-Port-Of: odoo/enterprise#112325
This update ensures that the date range used to fetch transactions from iap is always accurate. Previously, incorrect date ranges could occur, but this fix now uses the latest statement or statement line date, guaranteeing correct transaction retrieval. This improves the reliability of IAP data.
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
15 changes
Resolved issues and error corrections
This pull request corrects a minor typo in the Odoo Enterprise settings related to company information for several payroll localizations (BE, IN, LT, LU, MA). The change ensures consistent and accurate wording within the application, improving the user experience. This fix addresses a visual inconsistency that could have caused confusion.
Original PR description
To reproduce the issue: 1. Install either BE,IN,LT,LU,MA payroll localization 2. Open settings view 3. "Offical Company Information" Should be "Official Company Information"
This update ensures the 'Load Order' button remains hidden across all screen sizes for Grab/GoFood orders. Previously, resizing the window would briefly show this button, which was replaced with 'Set Food Ready' to prevent manual order changes. This change improves the user experience and data integrity for these orders.
Original PR description
For Grab/GoFood orders, the "Load Order" button is replaced by "Set Food Ready" to prevent manual edits. Previously, resizing or minimizing the window caused the hidden "Load Order" button to reappear due to responsive layout overrides (e.g., mobile view CSS classes). This commit updates the visibility logic to ensure the button remains strictly hidden across all screen sizes for external delivery orders. opw-6044176 Forward-Port-Of: odoo/enterprise#111222
This update fixes an issue where appointment bookings were incorrectly reserving full party sizes for resources. The change ensures that resources are accurately allocated, preventing overbooking and improving the scheduling process. A new test has been added to verify the fix.
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 transaction dates used to fetch data from iap are always within the correct 'lock date' range. Previously, dates could be inaccurate, leading to potential data discrepancies. This fix guarantees the most reliable and accurate retrieval of financial information.
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 resolves an issue where the 'Time Off Type' dropdown was empty when creating time off entries via the Gantt view. The fix ensures the dropdown correctly displays available time off types by properly filtering the database search. This improves the usability of the time off management feature.
Original PR description
**Steps to Reproduce:**
1. Open Time Off App->Management->Time Off->Gantt View
2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set".
3. Open the "Time Off Type" dropdown.
Result: The dropdown is completely empty.
**Bug Cause:**
The Gantt multi-create popover skips `_loadNewRecord`, meaning `work_entry_type_filter_domain` never computes and evaluates to an empty list. This hardcodes `('id', 'in', [])` into the search, forcing the database to return 0 records.
**Solution:**
Remove the broken computed `('id', 'in', [])` domain from the `work_entry_type_id` field in `hr_leave_gantt_multi_create_view`. Add the `context="{'gantt_multi_create_company_filter': True}"` flag to the field to trigger the country-filtering logic implemented in the `_search` method.
**Task:** 6109569This update corrects a technical issue impacting Envia delivery in Colombia. Previously, the system incorrectly formatted zip codes, leading to inaccurate data sent to Envia. Now, the system uses Envia's geocoding to ensure correct data formatting, improving delivery reliability and reducing potential delays.
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 the generation of the session report in the CO company setting. The fix addresses a technical problem with accessing sale details, ensuring users can now successfully generate and utilize this important report. This improves the functionality of the point-of-sale system.
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 an issue where the system was incorrectly retrieving neutralization data for payroll calculations in Switzerland. The fix ensures accurate payroll processing by correcting the way the system fetches this critical information. This improves the reliability of financial reporting related to employee compensation.
Original PR description
Forward-Port-Of: odoo/enterprise#113961
This update resolves a test failure in the WhatsApp module related to how archived user IM statuses are handled. The test case was incorrectly designed, failing because the partner wasn't linked to a user. The fix ensures the test accurately reflects the system's behavior by properly linking the partner to a user.
Original PR description
Purpose of this PR: compute_im_status returns false when main_user_id is not set. The testcase was failing because the partner was not linked to a user. Updated the testcase by linking the partner to a user to match the expected behavior. task-4797343
This update ensures that waiting payslips (draft payslips with calculated amounts) are automatically recalculated whenever employee information or payroll settings are modified. This guarantees that the payslip data remains accurate and reflects the latest changes, improving payroll reporting reliability. This change addresses a potential discrepancy between the payslip and the underlying data.
Original PR description
This commit makes waiting payslips recomputes whenever inputs are changed to make sure the sheet is up to date with inputs -waiting payslip: a payslip in draft with computed lines Task#5439146
This update resolves a potential issue where timesheet rules could cause access errors due to mismatched company restrictions on linked projects. By adding a company ID to the timesheet rule, we ensure that projects linked to the rule adhere to the same company, preventing these access problems and improving user experience.
Original PR description
This commit's purpose is to prevent potential access rigths error with aw.rule. Currently it is possible to set a project/task that is restricted to a specific company to an aw.rule. This can lead to a user using that aw.rule having access rights error because he does not have access to that project. To fix this issue, we add a company_id to the aw.rule model and ensure that the project/task linked to it follow the same company as the aw.rule it is set on task-6116548
This update fixes a bug where changes to embedding settings caused sources to incorrectly show as 'processing'. The fix ensures that updates are properly processed and sources are updated correctly, preventing delays and inaccurate status displays. This improves the reliability of the AI embedding feature.
Original PR description
### Issue: In ai.agent, any update to any field causes the sources to be shown as processing. ### Fix In `ai.agent.write()`, the provider change detection was comparing the provider object directly against the stored provider name string. Also, `_cron_generate_embedding` returned early when no missing embeddings were found, skipping the `_update_sources_status` call and leaving sources stuck in processing status. task-id-6121579
This update corrects a technical issue that was preventing users from properly accessing returns reports. The change ensures that the reporting module functions correctly after a recent update to the main account kanban view. This resolves a traceback error and maintains the reliability of the returns reporting process.
Original PR description
After a recent IMP in account return kanban view in #113292 , the overall styling of kanban view was improved, but the inherited view in this module was unchanged which caused traceback. This commit fixes that issue.
This update addresses a crash that occurred when users cleared the 'Today' date filter or selected 'All time' in the global filters. The fix ensures the system remains stable and prevents unexpected errors, improving the user experience. This resolves a technical issue impacting spreadsheet edition functionality.
Original PR description
traceback when deleting the current value of a date filter Task: [6019061](https://www.odoo.com/odoo/2328/tasks/6019061)
This update enhances the Sign module's user experience by streamlining request workflows and addressing key usability issues. Specifically, users can now cancel sent signature requests and receive prompts to update contact information, while a critical bug causing issues with the 'Thank You' dialog has been resolved.
Original PR description
This commit introduces several UX improvements, workflow adjustments, and bug fixes to the Sign module to streamline the user experience. Specific changes: - Views & UI: - Add a related model filter to the sign templates search view. - Clean up the sign request pivot view by removing irrelevant measures. - Request Management: - Allow the original request sender to cancel a sent signature request. - Stop automatically saving the certificate of completion into the Documents app. - Integrate the missing-email popover into the Send Sign Request wizard to prompt users to update contacts on the fly. - Bug Fixes: - [FIX] Resolve the dismiss bug in the Thank You dialog by properly hooking the ESC key/background click into the global dialog environment.
7 changes
Resolved issues and error corrections
This update resolves an issue where lunchtime shifts were incorrectly calculated when an employee's time zone differed from the calendar time zone. The fix ensures accurate lunch time tracking and corrects the reset of work entries when time zone discrepancies exist, improving the reliability of employee time data.
Original PR description
- Correct lunch time shift if employee tz differs from calendar tz - Correct reset of WE if employee tz differs from calendar tz Task: 6072325
This update resolves a critical issue in the payroll processing for Mexico that could cause the system to crash when no bank account information was available for an employee. The change ensures the system handles missing data gracefully, preventing errors and maintaining accurate payroll calculations. This improves stability and data integrity.
Original PR description
Accessing the employee bank accounts using index [0] raised an IndexError when no accounts were defined. Additionally, computing the CLABE flag using len() caused a TypeError when the account number was missing. This change uses a safe recordset slice to avoid accessing empty records and guards the length check to only evaluate when a value is present. It prevents crashes while keeping the original behavior unchanged and avoids sending invalid empty values in the CFDI.
This update ensures that transaction dates pulled from Codabox are always within the correct timeframe. Previously, incorrect date ranges could occur, but this fix now uses the latest statement or statement line date, guaranteeing accurate reporting. This improves the reliability of financial data.
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 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. This change ensures accurate capacity allocation, preventing scheduling conflicts and improving appointment management.
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 resolves an issue preventing the generation of session reports in the CO company setting. Previously, generating the report would result in an error. The fix corrects a data access problem, allowing users to successfully generate and review their POS session reports.
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 an issue where the 'Create a Payslip' button was unresponsive when no payslips existed in the W2 report. The fix corrects a technical error in the system's code that prevented the button from functioning properly. This ensures users can consistently generate W2 reports.
Original PR description
1.Install l10n_us_hr_payroll 2 Navigate to Payroll>Reporting>W2 Report. 3.Open/Create W2 form and try to add payslip by clicking "Add a line". 4."Create a payslip" button appears if their are no valid payslips. 5.Click it, it won't work! Root cause: - `onAdd` bind was missing in the controller - Renderer applied an additional `.bind(...)`, breaking the callback Fix: - Pass a dedicated `createNewPayslip` action from controller - Remove double binding in renderer - Forward callback directly to helper component task-[5928770](https://www.odoo.com/odoo/project/1251/tasks/5928770) Forward-Port-Of: odoo/enterprise#111735
This update resolves a bug preventing portal users from uploading files correctly on mobile devices. The issue stemmed from a change in the user interface component, causing file selection to fail. The fix ensures proper file uploads for mobile users.
Original PR description
**Steps to reproduce:** - Install Documents app - As admin, share a folder to a portal user with editor access - Log as portal user on mobile view - Try to upload a new file from the control panel -…
**Steps to reproduce:** - Install Documents app - As admin, share a folder to a portal user with editor access - Log as portal user on mobile view - Try to upload a new file from the control panel - File dialog appears, but selected file is not saved **Issue:** Seems like changing the boostraps dropdown to the owl component created this issue. It is caused by Upload button trying to use the `<input>` of its parent dropdown. When the dialog opens, the current dropdown and its parent are removed (with the surrounding overlay) due to the default closingMode. `onSelected="() => this.uploadFileInputRef.el.click()"` Also the page has multiple time the same `<input>` element due to the duplication of the actions for the bottom drawer. **Fix:** Put the `<input>` element in a place where it won't be duplicated on mobile when creating the overlay with the upload interactions. This ensures we always use the same `<input>` element for the dropdown, so that files are properly added even if the dropdown is removed. We could also change the closingMode to `closest` or `none` and manually close the remaining dropdown(s) on file upload. dropdown component: https://github.com/odoo/enterprise/commit/06802d3d6cc5141842adba74f7c9f1970feeb263 similar issue for non-portal user: https://github.com/odoo/odoo/commit/8a871a120b75f7c09c70dbf07530239244dbb5d6 opw-6042353
2 changes
Resolved issues and error corrections
This update ensures that raw component moves in manufacturing orders consume the correct quantities of materials. Previously, the system incorrectly added all available stock to the production, even when manually adjusting quantities on the move line. This fix now prioritizes the quantities specified on the move line, ensuring accurate material consumption and reducing potential overstocking issues.
Original PR description
Commit https://github.com/odoo-dev/odoo/commit/63e44737fe469ab56b8e8e96c1ad47205ead1094 force `picked` to `True` when editing the stock move line in mrp module. The issue is, having Manufacturing installed, writing on any stock move (even in a picking) will go throughout this code and mark the move as picked. This commit adds a contrains to only update raw component moves. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where the 'sd_worx' report incorrectly used the current year, leading to test failures. The change ensures the correct year is always referenced, preventing future errors and maintaining accurate payroll reporting. This improves the reliability of the report data.
Original PR description
Making sure we set the reference year when exporting the sd_worx report as if not stated it will call the current year and this will cause the test failing in future builds runbot-242148 Forward-Port-Of: odoo/enterprise#112325
2 changes
Resolved issues and error corrections
This update resolves a test failure related to the calculation of holiday pay for Belgian employees. The fix removes tracking from a specific field, ensuring it's only computed when needed and preventing incorrect initial values from being set. This ensures accurate holiday pay calculations moving forward.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445
This update corrects and streamlines translations for the account asset and reports modules in French (fr_BE, fr_CA, and nl_BE). Outdated or incorrect translation overrides have been removed, ensuring consistent and accurate language across Odoo. This improves the user experience for French-speaking customers.
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458