Navigate
Branch
Monday, December 2, 2024
81 changes
11 changes
Miscellaneous changes
When uploading invoices in EFFF format taxes were not applied even though the XML file correctly defined them. The issue came from not taking the `<cbc:Percent>` tag into account when outside of `{*}TaxCategory` tag. This commit adds support both structures by checking for the `<cbc:Percent>` tag within `<cac:TaxSubtotal>` and outside of it. task-4348339 Forward-Port-Of: odoo/odoo#188859 Forward-Port-Of: odoo/odoo#188062
Original PR description
When uploading invoices in EFFF format taxes were not applied even though the XML file correctly defined them.
The issue came from not taking the `<cbc:Percent>` tag into account when outside of `{*}TaxCategory` tag.
This commit adds support both structures by
checking for the `<cbc:Percent>`
tag within `<cac:TaxSubtotal>` and outside of it.
task-4348339
Forward-Port-Of: odoo/odoo#188859
Forward-Port-Of: odoo/odoo#188062Description of the issue this PR addresses: Current behavior before PR: When pasting content containing `<div>` elements with inline child nodes, the `<div>` tags were unwrapped, causing all inline content within multiple `<div>` elements to merge into a single line. Desired behavior after PR is merged: `<div>` elements are now converted to `<p>` tags. This preserves the block structure and ensures inline content within each `<div>` remains in original format. task-4309745 ---
Original PR description
Description of the issue this PR addresses: Current behavior before PR: When pasting content containing `<div>` elements with inline child nodes, the `<div>` tags were unwrapped, causing all inline content within multiple `<div>` elements to merge into a single line. Desired behavior after PR is merged: `<div>` elements are now converted to `<p>` tags. This preserves the block structure and ensures inline content within each `<div>` remains in original format. task-4309745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186862
Improve access related tests for mail.message and their sub models. Currently tests are dependent on discuss.channel model, and not always written in a clear way. Understanding the purpose of each test is not crystal clear. We now use a test model with simple rules, defined in test_mail addon. It allows to simulate models with * public access; * portal access; * internal access; * admin access; using ACLs and ir.rules. Tests are rewritten to be more concise and precise an
Original PR description
Improve access related tests for mail.message and their sub models. Currently tests are dependent on discuss.channel model, and not always written in a clear way. Understanding the purpose of each test is not crystal clear. We now use a test model with simple rules, defined in test_mail addon. It allows to simulate models with * public access; * portal access; * internal access; * admin access; using ACLs and ir.rules. Tests are rewritten to be more concise and precise and use new models. This is done in stable to keep coherency in tests codebase. It also eases writing bugfixes as tests won't have to be modified during forward port process. Finally it allows to backport improvements or fixes in later versions if it applies to previous versions. Task-4320561 Forward-Port-Of: odoo/odoo#189120 Forward-Port-Of: odoo/odoo#186394
Improvements for PR https://github.com/odoo/odoo/pull/130806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189238
Original PR description
Improvements for PR https://github.com/odoo/odoo/pull/130806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189238
The file viewer tries to show the document from the url obtained from the defaultSource function in file_model.js. This function builds the url using urlRoute. Before the fix, the urlRoute is the url from the attachment. This causes the PDF viewer to fail because it has a same-origin policy. This fix avoids to use the url to the one from the attachment's url directly so that the viewer can show the document correctly with the computed urlRoute. The attachment url does not need to be use
Original PR description
The file viewer tries to show the document from the url obtained from the defaultSource function in file_model.js. This function builds the url using urlRoute. Before the fix, the urlRoute is the url from the attachment. This causes the PDF viewer to fail because it has a same-origin policy. This fix avoids to use the url to the one from the attachment's url directly so that the viewer can show the document correctly with the computed urlRoute. The attachment url does not need to be used at all, as the odoo server will properly direct. Forward-Port-Of: odoo/odoo#187970
When generating the mail alias for a journal, we check whether the name of the company is already in it, and add it if it's not. The problem is before this commit, we didn't sanitize the name of the company to do that check, so a company name with spaces or accents would never be detected as part of the alias, and could end up being in it twice. This caused issues in the Winbooks import of one customer, who ended up with duplicate aliases because of that, since the journal code was not proper
Original PR description
When generating the mail alias for a journal, we check whether the name of the company is already in it, and add it if it's not. The problem is before this commit, we didn't sanitize the name of the company to do that check, so a company name with spaces or accents would never be detected as part of the alias, and could end up being in it twice. This caused issues in the Winbooks import of one customer, who ended up with duplicate aliases because of that, since the journal code was not properly added to the generated alias while it should, and a duplicate of the company name was put instead. opw-4196597 Forward-Port-Of: odoo/odoo#189149
In this commit, we fix this tour that failed each hour at minute 31 when the tour is runned at this time. The goal is to check the message text content and not the hour it was sent. runbot-error-id~108435 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189266
Original PR description
In this commit, we fix this tour that failed each hour at minute 31 when the tour is runned at this time. The goal is to check the message text content and not the hour it was sent. runbot-error-id~108435 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189266
Previously, it was still possible to access a project with an access_token even if that project is no longer in privacy="portal". This was not consistant with the front-end that disable the access to the portal share wizard when privacy is set to anything else than 'portal'. This change remove the token when the privacy is changed at the time of the write() This change is done in the project module because it depends on "portal", and not the other way around. This change can also be
Original PR description
Previously, it was still possible to access a project with an access_token even if that project is no longer in privacy="portal". This was not consistant with the front-end that disable the access to the portal share wizard when privacy is set to anything else than 'portal'. This change remove the token when the privacy is changed at the time of the write() This change is done in the project module because it depends on "portal", and not the other way around. This change can also be used as an invalidation mecanism in case of a token leak. Changing the privacy to 'private' then to 'portal' will allow for an invalidation of the previous token and the creation of new one. opw-4104804 task-4354145 Closes #176177 Forward-Port-Of: odoo/odoo#189218 Forward-Port-Of: odoo/odoo#188264
**Steps to reproduce the bug:** - Create a storable product: - "Finished Product" with the following BoM: - Component: 1 unit of "C1" - Byproducts: - 1 unit of "By-product 1" - 1 unit of "By-product 2" - Create a manufacturing order to produce 5 units of the finished product. - Confirm the MO. - Set the quantity produced to 5 units. - Set the quantity of byproducts to: - By-product 1: 4 units - By-product 2: 3 units - Validate the MO. - Print
Original PR description
**Steps to reproduce the bug:**
- Create a storable product:
- "Finished Product" with the following BoM:
- Component: 1 unit of "C1"
- Byproducts:
- 1 unit of "By-product 1"
- 1 unit of "By-product 2"
- Create a manufacturing order to produce 5 units of the finished product.
- Confirm the MO.
- Set the quantity produced to 5 units.
- Set the quantity of byproducts to:
- By-product 1: 4 units
- By-product 2: 3 units
- Validate the MO.
- Print the cost analysis.
**Problem:**
The reported quantity does not show the actual quantity produced but
instead shows the "to produce" quantity.
opw-4312292
Forward-Port-Of: odoo/odoo#188854Before this commit, when sending a message in full composer to explicit recipients and message contains mentions, the resulting recipients of the message were only mentioned users. Steps to reproduce: - Open a form view with suggested recipient (e.g. any contacts with demo data) - Click "Send message" then full composer button ("expand" button) - Type `@Marc Demo` mention in the full composer text area - Click on "Send" => The new message shows envelope with only "Marc Demo" in the rec
Original PR description
Before this commit, when sending a message in full composer to explicit recipients and message contains mentions, the resulting recipients of the message were only mentioned users. Steps to…
Before this commit, when sending a message in full composer to explicit recipients and message contains mentions, the resulting recipients of the message were only mentioned users.
Steps to reproduce:
- Open a form view with suggested recipient (e.g. any contacts with demo data)
- Click "Send message" then full composer button ("expand" button)
- Type `@Marc Demo` mention in the full composer text area
- Click on "Send"
=> The new message shows envelope with only "Marc Demo" in the recipients, instead of "Marc Demo" and the suggested recipient.
This happens because when making a mention, the code to enrich the `partner_ids` of `mail.compose.message` was basically setting its content with mentions, without taking into account whether there were some explicit values with other means than with `@mention`.
This commit fixes the issue by adding mentions with the current value of `partner_ids`, so that mentions and explicit recipients are the resulting recipients of message as expected
Task-4366608
Forward-Port-Of: odoo/odoo#189187Originally, the inventory adjustment view will attempt to merge quants eventhough this merging is done in the scheduler. In this PR we allow a way to skip the function _quant_tasks which performs merging. This is done through a system parameter. Merging quants has been seen to cause deadlocks in cases where multiple users are visiting the same view at the same time. Skipping this process will make sure to only merge quants through the scheduler. This will speedup opening the quants views and
Original PR description
Originally, the inventory adjustment view will attempt to merge quants eventhough this merging is done in the scheduler. In this PR we allow a way to skip the function _quant_tasks which performs merging. This is done through a system parameter. Merging quants has been seen to cause deadlocks in cases where multiple users are visiting the same view at the same time. Skipping this process will make sure to only merge quants through the scheduler. This will speedup opening the quants views and could also be helpful in debugging. opw-4226821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189053
8 changes
Enhancements to existing features
Luxembourg payroll now calculates meal voucher contributions more accurately, deducting only the employee contribution when applicable and supporting cases where that contribution is treated as taxable benefit in kind. It also handles vouchers above the allowed daily limit so excess amounts are included correctly for tax and social contribution purposes.
Original PR description
An employee contributes €2.8 per day towards meal vouchers. The total of €2.8 multiplied by the number of workdays is either subtracted from the employee's net salary or added to their gross salary…
An employee contributes €2.8 per day towards meal vouchers. The total of €2.8 multiplied by the number of workdays is either subtracted from the employee's net salary or added to their gross salary as a benefit in kind (BIK). This amount is then considered part of the taxable and contributory base. Currently, only the 'Subtracted from net' scenario is implemented. Additionally, if the daily meal voucher value exceeds the maximum limit (e.g., €15 for 2024), the difference between the daily voucher amount and this maximum should also be treated as BIK, similar to the case where the employee's meal voucher contribution is added to the gross salary. This commit: 1. Fixes a bug in the 'Subtracted from net' case, where the full meal voucher amount was incorrectly deducted from the employee's net salary, instead of only the employee's contribution. 2. Adds handling for the case where €2.8 times the number of workdays is added to the gross salary. 3. Implements handling for situations where the daily meal voucher amount exceeds the set maximum. 4. Makes minor adjustments to the meal vouchers section in the contract view. task-4310359
The Luxembourg payroll localization removes duplicate work entry setup data to simplify maintenance and avoid redundant configuration. It also drops an unused wage supplement entry type, reducing clutter without changing normal payroll workflows.
Original PR description
Removed duplicate file for work entry type data in Luxembourg localization task-4212665
Businesses can now use FEC import and export capabilities in any country when the relevant module is installed, instead of being limited to French companies. This makes the accounting data exchange workflow more flexible for international deployments that need the same format.
Original PR description
*: reports, fec_import The FEC import/export feature could be useful for other countries and should be allowed even if the country is not French as long as the module is installed. task-4181556
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#74971
Original PR description
Forward-Port-Of: odoo/enterprise#74971
…ayslip form Steps: • Install the payroll app. • Install l10n_au_hr_payroll module. • Open payslip and remove the employee from the form and click outside to apply changes. • It will cause the traceback error. Cause of the issue: • After removing the employee name corresponding contract will become empty. • The issue is due to empty record set of contract. Fix: • Added a check to ensure contract is present. task-4341523 Forward-Port-Of: odoo/enterprise#74238
Original PR description
…ayslip form Steps: • Install the payroll app. • Install l10n_au_hr_payroll module. • Open payslip and remove the employee from the form and click outside to apply changes. • It will cause the traceback error. Cause of the issue: • After removing the employee name corresponding contract will become empty. • The issue is due to empty record set of contract. Fix: • Added a check to ensure contract is present. task-4341523 Forward-Port-Of: odoo/enterprise#74238
**Steps to reproduce:** - Install Accounting - Activate "Budget Management" in Accounting settings - Create an analytic account: * Plan: [any] - Create a Budget: * Budget Type: Expense * Period: [the current month] * A budget line with the created analytic account and any budgeted amount - Open the budget - Create a bill: * Vendor: [any] * Bill Date: [a date in the current month] * An invoice line with the analytic account - Confirm the bill - Check the Budget R
Original PR description
**Steps to reproduce:** - Install Accounting - Activate "Budget Management" in Accounting settings - Create an analytic account: * Plan: [any] - Create a Budget: * Budget Type: Expense * Period: [the…
**Steps to reproduce:**
- Install Accounting
- Activate "Budget Management" in Accounting settings
- Create an analytic account:
* Plan: [any]
- Create a Budget:
* Budget Type: Expense
* Period: [the current month]
* A budget line with the created analytic account and any
budgeted amount
- Open the budget
- Create a bill:
* Vendor: [any]
* Bill Date: [a date in the current month]
* An invoice line with the analytic account
- Confirm the bill
- Check the Budget Report
=> The committed and achieved amounts of the budget is correctly set to the amount of the bill
- Create a credit note
- Check the Budget Report again
**Issue:**
The amount is unchanged.
The credit note is not taken into account.
**Cause:**
The computation is only taking into account the analytic lines with a negative amount for an expense budget and those with a
positive amount for a revenue budget, which is not correct.
In this case, the credit note has positive amount and therefore it is excluded from the expense budget.
**Solution:**
1) An expense budget should take into account all the analytic lines in an expense account and a revenue budget should do the same with all the analytic lines in an income account.
2) Analytic lines with an account that is not an income or an expense one should be ignored.
3) Analytic lines without an account should be taken into account for an expense-type budget if:
- the category is not "other" (the default category)
- the category is "other" and the amount is negative
4) Analytic lines without an account should be taken into account for a revenue-type budget if the category is "other" and the amount is positive.
opw-4214599
Forward-Port-Of: odoo/enterprise#74235With the current links generated for the hashtags in Linkedin, there's a few corner cases that are not being handled by Linkedin side as we expect it to (ex #FLD), so from 18.0 onwards we should follow the same formatting Linkedin is using nowadays. Previous link: https://www.linkedin.com/feed/hashtag/FLD2024 Link after the change: https://www.linkedin.com/feed/hashtag/?keywords=FLD2024 In the previous links you can see the differences between them. opw-4326960 Forward-Port-Of: odoo/
Original PR description
With the current links generated for the hashtags in Linkedin, there's a few corner cases that are not being handled by Linkedin side as we expect it to (ex #FLD), so from 18.0 onwards we should follow the same formatting Linkedin is using nowadays. Previous link: https://www.linkedin.com/feed/hashtag/FLD2024 Link after the change: https://www.linkedin.com/feed/hashtag/?keywords=FLD2024 In the previous links you can see the differences between them. opw-4326960 Forward-Port-Of: odoo/enterprise#74611
[link to broken tests](https://runbot.odoo.com/web#id=68972&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) since [this pr](https://github.com/odoo/enterprise/pull/62136), a lot of things changed in swiss payroll localization. One of the changes was introduction of new module, l10n_ch_hr_payroll_elm. This affected one of the assertQueryCount tests checking compute_sheet function, which is also overwriten in said module. Therefore, we need to increase the query count acc
Original PR description
[link to broken tests](https://runbot.odoo.com/web#id=68972&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) since [this pr](https://github.com/odoo/enterprise/pull/62136), a lot of things changed in swiss payroll localization. One of the changes was introduction of new module, l10n_ch_hr_payroll_elm. This affected one of the assertQueryCount tests checking compute_sheet function, which is also overwriten in said module. Therefore, we need to increase the query count accordingly. Flamegraph of function _get_base_local_dict before above mentioned pr:  Flamegraph of same function after the pr:  Forward-Port-Of: odoo/enterprise#73831
52 changes
New functionality added to Odoo
Kenya payroll now supports the move from NHIF to SHIF contributions, applying the correct calculation based on the payslip date. Reporting has also been updated so businesses can generate the appropriate NHIF or SHIF reports for the transition period.
Original PR description
Problem ---------- Since 1st October, the SHIF replace the NHIF, the only difference is the computation of the amount. All payslip before and on the 9 October use the NHIF and all new payslip from the 9 October use the SHIF Objective ---------- Adapt the salary rules to compute the good rule. Adapt the NHIF Report to make NHIF or SHIF reports. Solution ---------- Create new SHIF rule parameter with a min amount and rate computation. Create a new report wizard to manage the 2 different rules NHIF and SHIF task-4294419
Enhancements to existing features
Live chat visitors will now see the “operator has joined” update as a clear notification instead of inside the chat message bubble. This makes the conversation easier to follow and improves the customer support chat experience.
Original PR description
\* website_livechat Before this commit, when an operator joined a live chat conversation, the message 'operator has joined' was added as a comment inside the message bubble. With this commit, that message is now displayed as a notification. task-4354211
Automated actions can now read incoming request headers and use secure digest checks when handling webhooks. This makes it easier for businesses to connect Odoo with third-party services while validating that requests are legitimate.
Original PR description
Before this commit, the code had no access to any request's headers nor could we use HMAC/Hashlib functions to authenticate and verify incoming webhook. This was a limitation in the basic flows that the feature is supposed to support. After this commit, we pass in the context a key "headers" that contains a copy of the request headers. We're also given the possibility to authenticate third-party requests by comparing digest. ### (Useless) context about this PR: This PR is based on kebeclibre's PR (commit 2d345a5) when request payload where added. It's also my first PR on an open-source project and I'm new to Python/programming, my apologise in advance if I did a mistake. I'm open to any feedback, many thanks! --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds an option for Odoo's test environment to help detect inconsistent behavior when automated tours look for page elements. It supports more reliable testing and helps catch issues before they affect users.
Original PR description
We add an environment variable so that we can run a bundle with a configuration where we check for non-deterministic behaviors to find DOM elements in tours. 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
Sales settings now include a dedicated section for the Shopee connector. This makes it easier for users to find and configure Shopee-related options when managing sales integrations.
Original PR description
* Add setting section for Shopee task-3623720 Enterprise PR: https://github.com/odoo/enterprise/pull/71610 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The appraisal app now includes four additional demo templates to help users better understand how appraisal forms can be structured. This makes it easier for teams to explore examples and set up effective employee review processes.
Original PR description
4 news appraisals templates have been added to improve their understanding for users. task-4206744
Resolved issues and error corrections
The To-Do app chatter panel now stays within its intended area when activities contain long descriptions. This prevents the page layout from stretching unexpectedly, making the interface easier and more reliable to use.
Original PR description
Steps to Reproduce: - Open the To-Do app and click on the chatter icon. - Create an activity with a long description. - As the description increases, the chatter expands beyond its intended area. Issue: - The chatter did not have a fixed length, causing it to expand with long descriptions . After PR: - The chatter section now maintains a consistent fixed size. task-4256985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When tasks or applicants are created by email, stage update messages now include the original sender instead of incorrectly excluding them as the message author. This ensures customers, portal users, or applicants receive expected status notifications after their email creates a record.
Original PR description
The issue occurs when an email is sent to create a `project.task`. If the sender of the email is an existing user, this user is later set as the author of any outgoing emails related to that task. Since the system is configured to skip sending emails to the author, no email is delivered to the sender in this scenario. Reproduce --- - -i project,contacts - add `example.com` to domains in the settings - create new project with an alias: `project@example.com` - Have a stage with some "Email Template" set - send email creating project tasks as a portal user - BUG: email about stage update is NOT sent (even tho task appeared in stage) opw-3941928
The screen sharing icon in Odoo Discuss now turns green when screen sharing is active. This makes it easier for users to quickly confirm that their screen is being shared during a call.
Original PR description
Current behavior before PR: The screen share icon did not reflect any change when screen sharing was active Desired behavior after PR is merged: The screen share icon now turns green to indicate that screen sharing is active --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale product options are now easier to select because the option text works together with the radio button. This improves accessibility and makes configuration smoother for cashiers and other users.
Original PR description
Description of the issue/feature this PR addresses: Ensures proper association between `<span> `elements and corresponding `<input>` elements by making the `<span> `act as a label for better accessibility and user experience. Current behavior before PR: The `<span>` displaying the attribute name is not linked to the corresponding `<input>` radio button. Users must click the radio button itself to select an option. Desired behavior after PR is merged: The `<span> `acts as a clickable label for the corresponding `<input>` radio button, allowing users to click either the text or the radio button to select an option. This improves accessibility and enhances the user experience. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the Jordan e-invoicing process by removing an unnecessary repeated processing step. It does not change how invoices are sent, but makes the code easier to understand and maintain, reducing the chance of future mistakes.
Original PR description
The method _l10n_jo_edi_send always expects a single invoice. Therefore, the loop over the recordset makes no sense, and is misleading to whoever reads the code. task-3895493 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops embedded action data from carrying over when users open a normal action from an embedded one. It prevents the wrong action bar from appearing and avoids crashes caused by using records from the wrong business object.
Original PR description
Before this commit, when executing a regular action from an embedded one, the context wasn't cleared, so all the embedded action feature related keys were propagated to the regular action. As a consequence, the embedded actions bar was displayed on that action as well. Clicking on an item most certainly led to a crash, because a wrong active id (referring to anothe res_model) would be used. For instance 1) Go to Project 2) Open "AGR - S00080 - Sales Order" 3) Add Sales order embedded action 4) Click Sales order 5) Enter a sales order that has tasks or a service product 6) Click the Tasks smart button 7) The embedded actions bar is displayed and, it crashes if an item is clicked opw~4253958 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
OAuth login routes are no longer treated as read-only because they may need to create a user account or record a login event. This prevents failed sign-ins caused by the system blocking required database updates during authentication.
Original PR description
Follow-up of #186319 and #186786 These routes are auth=none but aren't technically read-only, as they can create the user record and need to record the login event anyway. The signin one even as a broad catch for Exception, which would prevent the readonly->read-write fallback to work, leading to a failed login.
Message tracking updates now correctly display the word 'none' when that is the intended value. This prevents blank entries in message histories, making changes clearer for users reviewing updates.
Original PR description
Previously, in the mail message body, setting any tracking value to 'none' would result in an empty value instead of showing 'none'. This commit addresses the issue, ensuring 'none' is displayed as expected. Task-4282534
Invoices now correctly account for online down payments that were made before the invoice existed, even when those payments do not create accounting journal entries. This prevents customers from being asked to pay more than the actual order total and keeps invoice and portal payment displays accurate.
Original PR description
Steps to reproduce: - Install sign; account; sales - Payment Providers > Enable Demo - Sales app > New Quotation > Other Info tab > Online Payment: 50% - Preview > Sign and pay > Make the 50% down…
Steps to reproduce: - Install sign; account; sales - Payment Providers > Enable Demo - Sales app > New Quotation > Other Info tab > Online Payment: 50% - Preview > Sign and pay > Make the 50% down payment - Back to SO > Create invoice > Regular invoice > Confirm > Preview Coupled with https://github.com/odoo/enterprise/pull/74108 The down payment amount is not deducted from the invoice, meaning we essentially force the customer to pay 150% of the total price. This is a by-product of the rework 01b87f1230beac0568f4e3b1b76e547909506892 which made the creation of journal entries optional, on which the invoice was previously dependant to track existing payments. Since the first payment here is made before any invoice is created, we want to create a separate payment with no associated journal entry (See the rework commit for more details on why we would want to do that, but in short we don't necessaily want to track payments that could be cancelled, etc...). However the matched_payment_ids on the invoice we create afterwards is not updated correctly, and above all the field is not taken into account by many views and functions which still assume there will be a corresponding account_move. This fix mostly aims to recompute the amount_residual of the invoice since that is the source most places draw from, and to reestablish the customer displays to prevent excessive payments from being made. To avoid disturbing other functions which could depend on the edited method payment_content is being kept separate (Not all fields are available without an account move so we would risk accessing missing fields unexpectedly by mixing them with regular move lines. opw-4208717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents payment post-processing from failing when a journal has more than one payment method line. It helps ensure online or point-of-sale payments can complete reliably instead of being blocked by a configuration-related error.
Original PR description
Currently, an exception is generated at the time of the post-processing payment transaction. error: ``` ValueError: Expected singleton: account.payment.method.line(11, 12) File…
Currently, an exception is generated at the time of the post-processing payment transaction.
error:
```
ValueError: Expected singleton: account.payment.method.line(11, 12)
File "addons/payment/models/payment_transaction.py", line 852, in _cron_post_process
tx._post_process()
File "addons/pos_online_payment/models/payment_transaction.py", line 29, in _post_process
super()._post_process()
File "addons/website_payment/models/payment_transaction.py", line 14, in _post_process
super()._post_process()
File "addons/sale/models/payment_transaction.py", line 91, in _post_process
super(PaymentTransaction, done_tx)._post_process() # Post the invoices.
File "addons/account_payment/models/payment_transaction.py", line 122, in _post_process
tx.with_company(tx.company_id)._create_payment()
File "addons/account_payment/models/payment_transaction.py", line 163, in _create_payment
'payment_method_line_id': payment_method_line.id,
File "odoo/fields.py", line 5287, in __get__
raise ValueError("Expected singleton: %s" % record)
```
The above exception was generated because we got multiple payment method lines in a single journal.
This commit fixes the above issue by accessing the first payment method line.
sentry-6007333118Employee remaining leave balances now exclude time off types that are hidden from the dashboard. This prevents employees and managers from seeing inflated or confusing leave totals based on leave categories that should not be displayed.
Original PR description
This commit excludes the time off types which are hidden from dashbaord in the count of employee's remaining leaves. task-4268945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
New databases now include a second default follow-up reminder level, so overdue invoices can receive a gradual sequence of reminders instead of only one. Demo cleanup also prevents deleted snailmail follow-up records from being recreated during module updates.
Original PR description
The second level already configured in demo has been moved in data because having only one follow-up level in a new database is a bit weird. Not only does it look weird, but in practice it also leads to a weird situation that by default the invoices will only be reminded once and never after. + we're failing to convey the usefuleness of the feature of building gradually harded reminders for the partner. Also added forcecreate="False" in snailmail demo data, because we don't waznt to recreate the missing xml ids (if people deleted it) in every module's update. task-4334758
Project managers can now create document folders from project settings without hitting an access error in demo scenarios. Project document links also open the more useful folder document view, making it easier to manage centralized project documents.
Original PR description
Commit 1: Reproduce: 1. Open a project's settings as Admin/Demo (project managers) 2. Make sure "Use Documents" is checked 3. Try quick creating a folder 4. Access Error This occurs because you are not allowed to create in the restricted "Projects" folder. This commit adapts demo data so that flows can easily be demonstrated and tested without requiring extra configuration steps for a common flow. Commit 2: Quick create folders instead of requests to centralize projects' documents. Also, the `documents_folder_many2one` widgets links to the documents kanban view of the folder instead of the less useful form view, as it is done in the other apps and bridges. Task-4344434
This update fixes several issues in Documents, including preventing employees from being automatically granted access to employee-related documents, improving the My Documents and Shared With Me filters, and avoiding crashes when shortcuts point to inaccessible files. It also reduces clutter from frozen spreadsheet folders in Home, making document navigation faster and clearer for users.
Frozen shared spreadsheets are now excluded from the list of available spreadsheets when inserting pivot data. This prevents users from selecting spreadsheets that should no longer be edited, reducing confusion and avoiding failed or inappropriate updates.
Original PR description
Steps to reproduce: - create a spreadsheet - Freeze and Share this spreadsheet - go to a pivot view and hit "Insert in spreadsheet" => the frozen spreadsheet is included in the dialog Task: 4353076
This fix updates the website shop rental flow so unavailable dates are identified more accurately during checkout tests. It helps prevent errors when customers choose rental dates, reducing the risk of blocked or confusing purchase flows.
Original PR description
The previous fix (odoo/enterprise#74860) was incomplete as out of range date also have the .o_date_item_cell class. Runbot Error 108371
This corrects the translation configuration for the FedEx delivery integration. It helps ensure translation updates are managed properly, with no expected change to day-to-day user workflows.
The point of sale quantity control now correctly changes a product quantity to a negative value when the +/- button is pressed. This prevents unexpected zero quantities and supports more accurate adjustments such as returns or corrections.
Original PR description
Before this commit ------------------------ Previously, when adding a product and clicking the "+/-" button, the quantity would change to "0" instead of becoming negative. After this commit ---------------------- After implementing this commit, pressing the +/- button now results in the quantity value changing to negative instead of changing it to 0. task- 4281516 Related PR: https://github.com/odoo/odoo/pull/185441/
Invoices now correctly account for online down payments made before the invoice exists, even when those payments do not create accounting journal entries. This prevents customers from being asked to pay more than the actual order total and keeps invoice payment information accurate.
Original PR description
Steps to reproduce: - Install sign; account; sales - Payment Providers > Enable Demo - Sales app > New Quotation > Other Info tab > Online Payment: 50% - Preview > Sign and pay > Make the 50% down…
Steps to reproduce: - Install sign; account; sales - Payment Providers > Enable Demo - Sales app > New Quotation > Other Info tab > Online Payment: 50% - Preview > Sign and pay > Make the 50% down payment - Back to SO > Create invoice > Regular invoice > Confirm > Preview Coupled with https://github.com/odoo/odoo/pull/185645 The down payment amount is not deducted from the invoice, meaning we essentially force the customer to pay 150% of the total price. This is a by-product of the rework 01b87f1 which made the creation of journal entries optional, on which the invoice was previously dependant to track existing payments. Since the first payment here is made before any invoice is created, we want to create a separate payment with no associated journal entry (See the rework commit for more details on why we would want to do that, but in short we don't necessaily want to track payments that could be cancelled, etc...). However the matched_payment_ids on the invoice we create afterwards is not updated correctly, and above all the field is not taken into account by many views and functions which still assume there will be a corresponding account_move. This fix mostly aims to recompute the amount_residual of the invoice since that is the source most places draw from, and to reestablish the customer displays to prevent excessive payments from being made. To avoid disturbing other functions which could depend on the edited method payment_content is being kept separate (Not all fields are available without an account move so we would risk accessing missing fields unexpectedly by mixing them with regular move lines. opw-4208717
WhatsApp conversations that have been inactive are now automatically unpinned after 5 days instead of 2 weeks. This helps prevent teams with high WhatsApp message volumes from hitting conversation limits that can slow down Discuss.
Original PR description
Follow-up of https://github.com/odoo/enterprise/pull/74131 PR above attempts to solve an issue of every-growing unpinned whatsapp conversations that make it harder to use Discuss for performance reasons, due to reaching the technical limit of around 2000 pinned conversations. To do so, it automatically forces unpinning whatsapp conversation after 2 weeks of inactivity, even if the conversation was unread. While this is an improvement, if there are around 150 whatsapp new whatsapp conversations made every day, then the 2 week force unpin is not enough, because the 2000 pinned conversation limit is reached. This commit fixes the problem by reducing the force unpin of whatsapp conversation to 5 days. The architecture of Discuss should scale better, but this is hardly achievable in short manner, hence why the current solution to this problem is prevent reaching a high amount of pinned conversations. opw-4330847
Appointment notifications in the chatter no longer show unwanted extra spacing. This makes messages look cleaner and easier to read without changing appointment behavior.
Original PR description
Purpose of this commit: This commit resolves an issue in the appointment module where system notifications in the chatter were displaying with unnecessary padding in the message body. Before  After  task-4291913
Documentation and clarification updates
This pull request updates the corporate Contributor License Agreement record for DinamicheAziendali. It is an administrative legal update that helps keep contribution permissions current and does not change product functionality.
Original PR description
Related to odoo/enterprise#73595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Version: 17.0+ Issue: If there is no partner on the stock moves, the delivery address will not display on the delivery slip. Purpose of this PR: Change the logic to use the stock.picking partner so that the delivery address will be printed on the delivery slip. Steps to reproduce on runbot: 1) create a receipt transfer 2) return the receipt transfer 3) print the delivery slip for the return 4) view that there is no delivery address, only the warehouse address Notes: There are
Original PR description
Version: 17.0+ Issue: If there is no partner on the stock moves, the delivery address will not display on the delivery slip. Purpose of this PR: Change the logic to use the stock.picking partner so that the delivery address will be printed on the delivery slip. Steps to reproduce on runbot: 1) create a receipt transfer 2) return the receipt transfer 3) print the delivery slip for the return 4) view that there is no delivery address, only the warehouse address Notes: There are three conditions that must be met for the delivery address to be printed on the delivery slip. - there are stock moves - the first stock move has a partner - the picking type code is outgoing With the above workflow, the stock moves are not assigned a partner although a partner is assigned on the picking. opw-4177811 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180677
Steps to reproduce the issue: - Create a storable product “P1” with two BoMs - Open one of the BoMs and add an attachment - Open the second BoM Problem: The attachment is added to all the BoMs. opw-4263943 Forward-Port-Of: odoo/odoo#189016
Original PR description
Steps to reproduce the issue: - Create a storable product “P1” with two BoMs - Open one of the BoMs and add an attachment - Open the second BoM Problem: The attachment is added to all the BoMs. opw-4263943 Forward-Port-Of: odoo/odoo#189016
Steps to reproduce the bug: - Create storable products “P1,” “P2,” and “P3,” and update their quantities in stock. - Create a picking for one unit of P1 and P2. - Create a second picking for one unit of “P3.” - Mark both pickings as "To Do." - Set the move of P1 as "Picked." - Add both pickings to a new batch. - Try to validate the batch. - A wizard to create a backorder is triggered. - Discard the wizard Problem: The picking for P3 is detached from the batch. When validating th
Original PR description
Steps to reproduce the bug: - Create storable products “P1,” “P2,” and “P3,” and update their quantities in stock. - Create a picking for one unit of P1 and P2. - Create a second picking for one unit…
Steps to reproduce the bug: - Create storable products “P1,” “P2,” and “P3,” and update their quantities in stock. - Create a picking for one unit of P1 and P2. - Create a second picking for one unit of “P3.” - Mark both pickings as "To Do." - Set the move of P1 as "Picked." - Add both pickings to a new batch. - Try to validate the batch. - A wizard to create a backorder is triggered. - Discard the wizard Problem: The picking for P3 is detached from the batch. When validating the batch, empty or non-picked pickings are checked for detachment. Since the picking for P3 is not picked, it is marked to be detached: https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock_picking_batch/models/stock_picking_batch.py#L213-L214 https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock_picking_batch/models/stock_picking_batch.py#L201-L202 Afterward, we check if the other pickings can be validated. Since one move (P1) is picked and the other (P2) is not, the wizard to create a backorder is triggered, but the result is not checked, and detachment continues regardless: https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock_picking_batch/models/stock_picking.py#L125-L126 opw-4320352 Forward-Port-Of: odoo/odoo#188176 Forward-Port-Of: odoo/odoo#187256
When generating the mail alias for a journal, we check whether the name of the company is already in it, and add it if it's not. The problem is before this commit, we didn't sanitize the name of the company to do that check, so a company name with spaces or accents would never be detected as part of the alias, and could end up being in it twice. This caused issues in the Winbooks import of one customer, who ended up with duplicate aliases because of that, since the journal code was not proper
Original PR description
When generating the mail alias for a journal, we check whether the name of the company is already in it, and add it if it's not. The problem is before this commit, we didn't sanitize the name of the company to do that check, so a company name with spaces or accents would never be detected as part of the alias, and could end up being in it twice. This caused issues in the Winbooks import of one customer, who ended up with duplicate aliases because of that, since the journal code was not properly added to the generated alias while it should, and a duplicate of the company name was put instead. opw-4196597 Forward-Port-Of: odoo/odoo#189149
Before this PR, clicking on the "user pinned a message to the channel" notification linked to a not yet loaded message would not scroll to the pinned message. This issue arises because the `highlightMessage` function does nothing if the message's thread is different from the current one. However, when a message is unknown, the thread is also unknown, and the function does nothing. The notification is only displayed in the origin thread of the message, so we can safely pass this information
Original PR description
Before this PR, clicking on the "user pinned a message to the channel" notification linked to a not yet loaded message would not scroll to the pinned message. This issue arises because the `highlightMessage` function does nothing if the message's thread is different from the current one. However, when a message is unknown, the thread is also unknown, and the function does nothing. The notification is only displayed in the origin thread of the message, so we can safely pass this information, assuming the message thread and the notification thread are the same. Forward-Port-Of: odoo/odoo#189282
Originally, the inventory adjustment view will attempt to merge quants eventhough this merging is done in the scheduler. In this PR we allow a way to skip the function _quant_tasks which performs merging. This is done through a system parameter. Merging quants has been seen to cause deadlocks in cases where multiple users are visiting the same view at the same time. Skipping this process will make sure to only merge quants through the scheduler. This will speedup opening the quants views and
Original PR description
Originally, the inventory adjustment view will attempt to merge quants eventhough this merging is done in the scheduler. In this PR we allow a way to skip the function _quant_tasks which performs merging. This is done through a system parameter. Merging quants has been seen to cause deadlocks in cases where multiple users are visiting the same view at the same time. Skipping this process will make sure to only merge quants through the scheduler. This will speedup opening the quants views and could also be helpful in debugging. opw-4226821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189053
Steps to reproduce: 1. Take any snippet and select any custom gradient color. 2. Reopen the background color - The selected custom gradient color is not retained as expected. Before version 16, we used wysiwyg, which called the start function to set selected colors easily. In version 17, we switched to OwlJS. Now, color picker always setting the default color as selected color. Therefore, it displays the default color instead of the selected color.  After this PR, the selected color will be set in the start function by replacing the default color, and updating RGBA values accordingly.  Task-3631963 Forward-Port-Of: odoo/odoo#186748 Forward-Port-Of: odoo/odoo#166961
Users rely on analytical accounting for accurate sales reporting. In operations involving automated inventory valuation, when an account move is confirmed, cogs entries are created with the same analytic account as the product line. However, due to a recent commit this is no longer the case. Steps to reproduce: - Enable Analytic Accounting and Anglo-Saxon Accounting in the settings - Create a storable product - Set inventory valuation to Automated on the product's category - Add
Original PR description
Users rely on analytical accounting for accurate sales reporting. In operations involving automated inventory valuation, when an account move is confirmed, cogs entries are created with the same analytic account as the product line. However, due to a recent commit this is no longer the case. Steps to reproduce: - Enable Analytic Accounting and Anglo-Saxon Accounting in the settings - Create a storable product - Set inventory valuation to Automated on the product's category - Add a cost to the product - Create an invoice with the product and add an analytic distribution - When the invoice is confirmed, COGS line are created Issue: Analytic distribution is not applied to COGS line This reverts commit https://github.com/odoo/odoo/commit/2a5463eb013aecc1d24041928974a9bbff5fb23a. opw-4347110 opw-4351323 opw-4351111 opw-4350640 opw-4350188 ... Forward-Port-Of: odoo/odoo#189216 Forward-Port-Of: odoo/odoo#188865
This PR fixes multiple issues related to the mass_mailing_html_field used in `marketing_automation` and in `mass_mailing` modules. This PR is the continuation of https://github.com/odoo/odoo/pull/187134 1) The edition dialog for the marketing campaign overlaps the fullscreen editor of the mail template destined to that marketing campaign. - concerns: marketing_automation 2) The snippets sidebar in a dialog does not stick to the dialog title when scrolling the dialog - concerns: marke
Original PR description
This PR fixes multiple issues related to the mass_mailing_html_field used in `marketing_automation` and in `mass_mailing` modules. This PR is the continuation of https://github.com/odoo/odoo/pull/187134 1) The edition dialog for the marketing campaign overlaps the fullscreen editor of the mail template destined to that marketing campaign. - concerns: marketing_automation 2) The snippets sidebar in a dialog does not stick to the dialog title when scrolling the dialog - concerns: marketing_automation See individual commits for further explanation. task-4178640 Co-authored-by: Astik Singh <assi@odoo.com> Co-authored-by: Damien Abeloos <abd@odoo.com> Co-authored-by: Mahdi Cheikh Rouhou <macr@odoo.com> Co-authored-by: Shubham Thanki <shut@odoo.com> Forward-Port-Of: odoo/odoo#183602
Steps: - Open any list view with more than 1 page - apply a limit if you don't have enough records - Toggle first record checkbox - Click on `o_pager_next` - Shift click on another record - Traceback The problem arises when you change page after using range-selection with the shift key. Indeed, range-selection uses `this.lastCheckedRecord`, which is the last record clicked on to start the selection, except that if you change page (and if you use a filter), thi
Original PR description
Steps:
- Open any list view with more than 1 page
- apply a limit if you don't have enough records
- Toggle first record checkbox
- Click on `o_pager_next`
- Shift click on another record
- Traceback
The problem arises when you change page after using range-selection with the shift key.
Indeed, range-selection uses `this.lastCheckedRecord`, which is the last record clicked on to start the selection, except that if you change page (and if you use a filter), this element may no longer be in the current page.
Currently, the code just checks that this element exists before attempting to create a selection by range.
The fix consists in checking that this element exists in the list of records before attempting anything.
opw-4284708
Forward-Port-Of: odoo/odoo#187596
Forward-Port-Of: odoo/odoo#187244When event_sale is installed the combined compute for the status and state resets the state to "open" and "free", the default values when there is no sale order. We now check whether state and status were already set before writing on them. task-4364856 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189037 Forward-Port-Of: odoo/odoo#188952
Original PR description
When event_sale is installed the combined compute for the status and state resets the state to "open" and "free", the default values when there is no sale order. We now check whether state and status were already set before writing on them. task-4364856 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189037 Forward-Port-Of: odoo/odoo#188952
Currently a parse error would arises if the user deletes the saleable product category and try to install POS To reproduce this issue 1) Install Sale Management without a demo data 2) Delete the Saleable product category 3) Try to install POS Error:- ``` ParseError: while parsing /home/odoo/src/odoo/18.0/addons/point_of_sale/data/point_of_sale_data.xml:21, somewhere inside <record id="product_category_pos" model="product.category"> <field name="parent_id" ref="product.
Original PR description
Currently a parse error would arises if the user deletes the saleable product category and try to install POS To reproduce this issue 1) Install Sale Management without a demo data 2) Delete the…
Currently a parse error would arises if the user deletes the saleable product category and try to install POS
To reproduce this issue
1) Install Sale Management without a demo data
2) Delete the Saleable product category
3) Try to install POS
Error:-
```
ParseError: while parsing /home/odoo/src/odoo/18.0/addons/point_of_sale/data/point_of_sale_data.xml:21, somewhere inside
<record id="product_category_pos" model="product.category">
<field name="parent_id" ref="product.product_category_1"/>
<field name="name">PoS</field>
</record>
```
This error is occurring because the user deleted the saleable product category, which leads to the above traceback as the saleable product category is referenced at multiple places to create master data.
https://github.com/odoo/odoo/blob/51296055790f8c6f01dfbbc82ca340756c54cdb3/addons/point_of_sale/data/point_of_sale_data.xml#L16
We can resolve this issue by preventing the user to delete the saleable product category.
sentry-6026143114
Forward-Port-Of: odoo/odoo#188788When creating an invoice in foreign currency with only 0% tax, we still want to display the company currency table on the invoice pdf. task-4367088 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189169 Forward-Port-Of: odoo/odoo#188955
Original PR description
When creating an invoice in foreign currency with only 0% tax, we still want to display the company currency table on the invoice pdf. task-4367088 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189169 Forward-Port-Of: odoo/odoo#188955
Improvements for PR https://github.com/odoo/odoo/pull/130806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189238
Original PR description
Improvements for PR https://github.com/odoo/odoo/pull/130806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189238
Add information in email footer when relevant to let people know that Peppol will become mandatory in their country, and recommend Odoo as a compliant software in that regard. task-4332306 Example of sent emails: To a customer in a Peppol country, with Email + Peppol sending:  To a customer in a Peppol country with Email only (obviously the Belgian specific information only appear to invoices se
Original PR description
Add information in email footer when relevant to let people know that Peppol will become mandatory in their country, and recommend Odoo as a compliant software in that regard. task-4332306 Example of sent emails: To a customer in a Peppol country, with Email + Peppol sending:  To a customer in a Peppol country with Email only (obviously the Belgian specific information only appear to invoices sent to belgian customers):  To a cutomer in a non Peppol country: No change  Forward-Port-Of: odoo/odoo#189118 Forward-Port-Of: odoo/odoo#188618
### Description of the issue/feature this PR addresses: - On selecting multiple cells in a table and applying formatting commands like (Bold, Italic, Underline, and Strikethrough) resulted in the loss of selection. The root cause of this issue was identified in the `cleanForSave()` function, which triggered `deselectTable()` during command execution, removing the entire selection from the table results in collapsing the selection to start. - When table cells with text are selected alongsid
Original PR description
### Description of the issue/feature this PR addresses: - On selecting multiple cells in a table and applying formatting commands like (Bold, Italic, Underline, and Strikethrough) resulted in the…
### Description of the issue/feature this PR addresses: - On selecting multiple cells in a table and applying formatting commands like (Bold, Italic, Underline, and Strikethrough) resulted in the loss of selection. The root cause of this issue was identified in the `cleanForSave()` function, which triggered `deselectTable()` during command execution, removing the entire selection from the table results in collapsing the selection to start. - When table cells with text are selected alongside empty cells, both selectedNodesInTds and selectedNodes have values. However, selectedTextNodes takes the value of selectedNodes, overwriting selectedNodesInTds. This causes the formatting to apply only to the text, deselecting the table cells. ### Approach: This PR addresses the issue by restoring selection using `historyResetLatestComputedSelection()` after executing the command, ensuring that the selection is preserved as intended. ### Desired behavior after PR is merged: We maintain the selection after applying formatting commands (Bold, Italic, Underline, and Strikethrough) in table. task-3822527 Forward-Port-Of: odoo/odoo#188452 Forward-Port-Of: odoo/odoo#165089
**Current behavior:** With a product that is invoiced based on ordered qty, has avg costing, and real time valuation: it is possible to invoice and received quantity in such an order that, when there is a landed cost associated with an invoice instance of the product, the standard price of the product may be updated with an incorrect value. **Expected behavior:** Product cost follows 'average' selection logically. **Steps to reproduce:** *Enable anglo-saxon accounting* 1. Create
Original PR description
**Current behavior:** With a product that is invoiced based on ordered qty, has avg costing, and real time valuation: it is possible to invoice and received quantity in such an order that, when there…
**Current behavior:** With a product that is invoiced based on ordered qty, has avg costing, and real time valuation: it is possible to invoice and received quantity in such an order that, when there is a landed cost associated with an invoice instance of the product, the standard price of the product may be updated with an incorrect value. **Expected behavior:** Product cost follows 'average' selection logically. **Steps to reproduce:** *Enable anglo-saxon accounting* 1. Create a product with: * real time property valuation * average cost method * on ordered quantities control policy 2. Create a purchase order for the product, for 100 000 units of the product at 1.35 each -> confirm the order 3. Create an invoice for 23 000 units, receive 23 000 units and backorder the rest 4. Create a landed cost on the invoice for 23 000 in the company currency units 5. Post the invoice 6. Create a second invoice for 27 000 units and post it 7. Receive 27 000 more units from the receipt 8. See that the product standard price is not the expected value of 1.81 **Cause of the issue:** The landed cost on the invoice is not taken into account. Since the price unit for the moves informing the new price value are obtained with `_get_price_unit()`, we end up only taking into account the sum value of the invoice lines linked to the move. So the landed cost does not get included in the subsequent price unit calculation here: https://github.com/odoo/odoo/blob/22e7bfb591c43e849c554eb4c128279d76ad31f9/addons/stock_account/models/stock_move.py#L328 **Fix:** Extract a method which returns invoice lines to the `_get_price_unit()` method of purchase_stock so that we may return line records that represent landed costs that will otherwise be omitted. opw-4048396 Forward-Port-Of: odoo/odoo#188648 Forward-Port-Of: odoo/odoo#185889
Description of the issue this PR addresses: Previously, selection using Shift + Arrow keys was not possible across contenteditable=false elements such as banners and clipboards. This commit makes sure now selection be done across these elements using Shift + Arrow keys. task-3502724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187910 Forward-Port-Of: odoo/odoo#182503
Original PR description
Description of the issue this PR addresses: Previously, selection using Shift + Arrow keys was not possible across contenteditable=false elements such as banners and clipboards. This commit makes sure now selection be done across these elements using Shift + Arrow keys. task-3502724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187910 Forward-Port-Of: odoo/odoo#182503
In this commit, we fix sign_resend_expired_link_tour tour by doing click in step action instead of doing nothing. Forward-Port-Of: odoo/enterprise#74898 Forward-Port-Of: odoo/enterprise#74767
Original PR description
In this commit, we fix sign_resend_expired_link_tour tour by doing click in step action instead of doing nothing. Forward-Port-Of: odoo/enterprise#74898 Forward-Port-Of: odoo/enterprise#74767
Problem ---------- Since 1st October, the SHIF replace the NHIF, the only difference is the computation of the amount. All payslip before and on the 9 October use the NHIF and all new payslip from the 9 October use the SHIF Objective ---------- Adapt the salary rules to compute the good rule. Adapt the NHIF Report to make NHIF or SHIF reports. Solution ---------- Create new SHIF rule parameter with a min amount and rate computation. Create a new report wizard to manage the 2 differe
Original PR description
Problem ---------- Since 1st October, the SHIF replace the NHIF, the only difference is the computation of the amount. All payslip before and on the 9 October use the NHIF and all new payslip from the 9 October use the SHIF Objective ---------- Adapt the salary rules to compute the good rule. Adapt the NHIF Report to make NHIF or SHIF reports. Solution ---------- Create new SHIF rule parameter with a min amount and rate computation. Create a new report wizard to manage the 2 different rules NHIF and SHIF task-4294419 Forward-Port-Of: odoo/enterprise#74241
Version: - saas-17.4 Steps to reproduce: 1. Install sale_subscription. 2. Create a Sales Order and invoice it. 3. Click on upsell. 4. Duplicate the upsell. 5. Change the start date. Issue: - When duplicating the upsell and changing the start date, an error occurs due to a missing next_invoice_date value. Solution: - Added a condition to retrieve next_invoice_date if it's missing, preventing the error. task:4325916 Forward-Port-Of: odoo/enterprise#73371
Original PR description
Version: - saas-17.4 Steps to reproduce: 1. Install sale_subscription. 2. Create a Sales Order and invoice it. 3. Click on upsell. 4. Duplicate the upsell. 5. Change the start date. Issue: - When duplicating the upsell and changing the start date, an error occurs due to a missing next_invoice_date value. Solution: - Added a condition to retrieve next_invoice_date if it's missing, preventing the error. task:4325916 Forward-Port-Of: odoo/enterprise#73371
Romania does not use the 3-column trial balance report, instead they use a 4-column and 5-column variant. This commit adds the 4/5-column report as variants to the standard trial balance. The standard trial balance implementation has been changed to be easier to override and add column groups. task: 3810685 Forward-Port-Of: odoo/enterprise#74590 Forward-Port-Of: odoo/enterprise#59115
Original PR description
Romania does not use the 3-column trial balance report, instead they use a 4-column and 5-column variant. This commit adds the 4/5-column report as variants to the standard trial balance. The standard trial balance implementation has been changed to be easier to override and add column groups. task: 3810685 Forward-Port-Of: odoo/enterprise#74590 Forward-Port-Of: odoo/enterprise#59115
…ayslip form Steps: • Install the payroll app. • Install l10n_au_hr_payroll module. • Open payslip and remove the employee from the form and click outside to apply changes. • It will cause the traceback error. Cause of the issue: • After removing the employee name corresponding contract will become empty. • The issue is due to empty record set of contract. Fix: • Added a check to ensure contract is present. task-4341523 Forward-Port-Of: odoo/enterprise#74238
Original PR description
…ayslip form Steps: • Install the payroll app. • Install l10n_au_hr_payroll module. • Open payslip and remove the employee from the form and click outside to apply changes. • It will cause the traceback error. Cause of the issue: • After removing the employee name corresponding contract will become empty. • The issue is due to empty record set of contract. Fix: • Added a check to ensure contract is present. task-4341523 Forward-Port-Of: odoo/enterprise#74238
[link to broken tests](https://runbot.odoo.com/web#id=68972&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) since [this pr](https://github.com/odoo/enterprise/pull/62136), a lot of things changed in swiss payroll localization. One of the changes was introduction of new module, l10n_ch_hr_payroll_elm. This affected one of the assertQueryCount tests checking compute_sheet function, which is also overwriten in said module. Therefore, we need to increase the query count acc
Original PR description
[link to broken tests](https://runbot.odoo.com/web#id=68972&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) since [this pr](https://github.com/odoo/enterprise/pull/62136), a lot of things changed in swiss payroll localization. One of the changes was introduction of new module, l10n_ch_hr_payroll_elm. This affected one of the assertQueryCount tests checking compute_sheet function, which is also overwriten in said module. Therefore, we need to increase the query count accordingly. Flamegraph of function _get_base_local_dict before above mentioned pr:  Flamegraph of same function after the pr:  Forward-Port-Of: odoo/enterprise#73831
10 changes
New functionality added to Odoo
This update adapts payroll calculations to reflect the recent shift from NHIF to SHIF, which only affects the amount calculation. A new report wizard is created to manage both NHIF and SHIF reporting requirements, ensuring accurate payroll reporting from October 1st onwards.
Original PR description
Problem ---------- Since 1st October, the SHIF replace the NHIF, the only difference is the computation of the amount. All payslip before and on the 9 October use the NHIF and all new payslip from the 9 October use the SHIF Objective ---------- Adapt the salary rules to compute the good rule. Adapt the NHIF Report to make NHIF or SHIF reports. Solution ---------- Create new SHIF rule parameter with a min amount and rate computation. Create a new report wizard to manage the 2 different rules NHIF and SHIF task-4294419
Resolved issues and error corrections
This update resolves a bug that prevented users from selecting the 'id' field when creating global filters within the spreadsheet edition of Odoo. Previously, this functionality was limited to relational filters. This change ensures consistent filter options for all users, improving data selection and reporting.
Original PR description
Steps to reproduce: - Insert a pivot from CRM - Create a global filter, with type date or text => The id field can be selected With this commit, field `id` is now available only on relational global filters. Task: 4348477
This update fixes a bug where the POS system would unexpectedly start clocking in users even if a cashier wasn't selected. The change ensures a cashier is selected before clocking in, preventing errors and ensuring the POS remains usable. This improves the overall reliability of the Point of Sale experience.
Original PR description
Behavior before commit: When opening the POS and selecting a cashier, if the user decides to go back without selecting any cashier, the clock-in function gets called anyways. This leads to pos_blacbox trying to clock in an undefined cashier, which in turn leads to more errors down the line (including an unusable pos). With the modification proposed in this commit, we check that a cashier has indeed been selected and only then proceed with the clocking in. opw-4293988 opw-4182434
This update corrects a problem where multiple cancellation requests for Mexican tax documents (CFDI) could lead to errors. When a customer rejects a cancellation, a new cancellation request is created. When the SAT approves the second request, the original cancellation request is automatically removed, preventing data inconsistencies. This ensures accurate tax reporting and avoids potential issues with the Mexican tax authority.
Original PR description
In a production setup: - Create an invoice and sign it - Ask for a cancellation rejected by the customer => an invoice_request_cancel document is created - Ask for another cancellation request => another invoice_request_cancel document is created - Trigger the SAT to approve the second cancellation request => The first invoice_request_cancel document is unlink.
This update resolves issues with Mexican CFDI invoice generation related to rounding calculations. Specifically, it corrects an error in how taxes are calculated during global invoice creation, ensuring compliance with Mexican tax regulations. The fix improves the accuracy of CFDI invoices for Mexican businesses.
Original PR description
## Steps to reproduce the issue 1. Activate Mexican Localization 2. In Mexican Company, create two Invoices with one product line: - Price Unit of 3.47, 16% Tax - Activate CFDI to Public 3. Select…
## Steps to reproduce the issue
1. Activate Mexican Localization
2. In Mexican Company, create two Invoices with one product line:
- Price Unit of 3.47, 16% Tax
- Activate CFDI to Public
3. Select both Invoices and create Global Invoice ("Actions" drop menu)
4. Check the CFDI tab in one of the Invoices
5. One of those errors pops up depending on your rounding method:
#### Round per line:
> Code : 301
> Message : Error de validaciones adicionales [Error #CFDI40108] El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual al redondeo de la suma de los importes de los conceptos registrados. Folio: 2. Serie: GINV/. El valor del atributo SubTotal (6.95) no coincide con la suma de los importes (3.47 + 3.47 = 6.94)
#### Round globally:
> Code : CFDI40205
> Message : El valor del campo TotalImpuestosTrasladados no es igual a la suma de los importes registrados en el elemento hijo Traslado.
## Explanation
#### Round per line:
With commit odoo/enterprise@933864a38af21a70b219d2824c64fff488acb15f, base and tax amounts were tweaked in order to satisfy some CFDI constraints. This change calculates amounts in an incorrect order: instead of calculating `tax_amount` with the formula `base_amount * tax_rate`, it calculates the base using `total / (1 + tax_rate)` then subtracts the base from the total to obtain the tax amount.
In our example, with a total of `6.94 + 1.12 = 8.06`, the base is calculated as such: `8.06 / 1.16 = 6.94827586207`, rounded to `6.95`, and the tax as such : `8.06 - 6.95 = 1.11`. The difference between the tweaked base `6.95` and the addition of the base of all invoice lines `3.47 + 3.47 = 6.94` is not accepted.
#### Round globally:
During a Global Invoice creation, we will first calculate the values of the Invoices separately. During this calculation, `total_impuestos_trasladados` is rounded with `precision_digits=2` while values in `traslados_list` are rounded with `precision_digits=6`. https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L583-L590 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L950-L961 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L963-L964 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L1000-L1001
In the example, `3.47 * 0.16 = 0.552`, is rounded to `0.56`. The addition of every rounded value gives `1.12` or `1.110400`, which gives the difference between `total_traslados_impuestos` and `traslados_list`.
## Fix reasoning
#### Round per line:
We will add a hack in `_get_post_fix_tax_amount_map`: CFDI accepts a difference of `1e-<precision_digits>`, which means that `precision_digits=2` would allow a difference of `0.01`. If the difference is lower, we will not perform the operation and only round the values.
In our example, the obtained tax amount is `1.12` and the expected tax amount `6.94 * 0.16 = 1.1104`. The difference between the two is lower than `0.01` and is accepted by the CFDI.
#### Round globally:
We will use the calculated values in `_get_global_invoice_cfdi_values` to compute the total price and totals of taxes at the end of the method instead of using the rounded values received from `cfdi_values_list` at the start.
opw-4085403This update fixes an issue with Odoo's report engines, specifically the account_codes engine, that caused incorrect data display when using LIMIT and OFFSET. The fix ensures consistent behavior across report types by adding an explicit ORDER BY clause, addressing a PostgreSQL requirement for reliable LIMIT/OFFSET functionality. This resolves data discrepancies and ensures accurate report results.
Original PR description
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html ,…
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior
As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already.
=======================================
[FIX] account_reports: properly handle groupby in account_codes engine for grouping keys used with multiple accounts
// TO REPRODUCE
1) Create a report with a single line, whose computation uses the account_codes engine, with formula "1". Set "partner_id" as the groupby value for that line. Setup a "load more limit" of 2 on your report.
2) Create 3 accounts, with codes 11, 12, 13
3) Create 3 partners: A, B, and C
4) Create journal entries, with the following lines (all balancing lines must use other accounts as the ones defined in 2) ), in that order:
- on account 11, with partner A, debit=10
- on account 11, with partner A, debit=20
- on account 12, with partner A, debit=25
- on account 11, without partner, debit=30
- on account 11, without partner, debit=40
- on account 12, with partner B, debit=50
- on account 13, with partner C, debit=60
5) Open the report for a period covering all the created journal entries, and have a look at the sublines generated for the groupby.
=> With the limit being 2, you'd expect to see "A", "B", and a "Load more..." line allowing to visualize the rest (namely a line for "C", and "Unknown"). Instead of that, you see no "Load more ...", and line "A"'s amount is wrong.
// EXPLANATION
The SQL query of the account_codes engine is grouping not only by groupby key (here, partner_id), but also by account_id, to be able to process the "C" and "D" suffixes of the formula later on. Because of that, the LIMIT passed by the load_more_limit is applied on that grouping.
With a load_more_limit of 2, we try to load 3 lines. If we manage to load 3, we only display 2, but know we need to display the "Load more..." line. Else, we know there are no more results, so no need for that additional line.
So, with our example, the query runs with a LIMIT of 3, returning
- 30 for A on account 11
- 25 for A on account 12
- 70 for no partner on account 11
Then, another issue happens:
The results returned by the SQL query (hence, by the engine) contain two times the same partner_id. From an engine perspective, the grouping key is only partner_id, not account_id (which is only used for an inner computation, with the SQL query). So that means the same grouping key has two different values. This is not legit, and causes one of them to shadow the other.
The report computation then receives 1 result for A, and 1 for "Unknown", so it renders them, and since there is no third result, it does not display the "Load more ...".
Forward-Port-Of: odoo/enterprise#74784This update optimizes the performance of reports displaying large amounts of asset data. By passing currency and expression values directly, the system avoids redundant data retrieval, resulting in faster report generation. This change significantly reduces processing time, especially with a large number of assets.
Original PR description
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |--------------|---------|--------| | 500 | 2 s | 1.55 s | | 7k | 20 s | 19 s | | 17k | 50 s | 41 s | ### Reference opw-4287192
This update resolves a bug preventing the correct rendering of event templates when using sale templates in event communication settings. The fix corrects a misconfiguration in how the system searches for templates, ensuring compatibility with both event and sale templates. This improves the reliability of event communication workflows.
Original PR description
Current behaviour: --- When setting mail templates in the communication tab of an event, you initially only see event templates, unless you click on "Search more ..." which allows you to set…
Current behaviour: --- When setting mail templates in the communication tab of an event, you initially only see event templates, unless you click on "Search more ..." which allows you to set non-event templates. Expected behaviour: --- Only seeing/and being able to set event templates Steps to reproduce: --- 1. Install event_sale 2. Go to Events, pick an event 3. In the communication tab, remove all templates 4. By clicking on "Search more ..." add a sale template 5. Set as Immediately and After each registration 6. Click on the smart button "Attendees" 7. Create a new attendee with an email then save 8. You may need to create multiple attendees 9. Failed to render inline_template template Cause of the issue: --- When selecting a sale template, the render model is `sale.order` So when passing the registration id to get rendered, it tries to read this id on a `sale.order`, causing an error if a `sale.order` with this id doesn't exist. Caused by: https://github.com/odoo/odoo/commit/6abd149259e9caf815fe1804f1322f623f8fcb50 `_name_search` was overriden, but the "Search more ..." option doesn't used `_name_search` but `web_search_read` Fix: --- Overrode `_search` instead opw-4106237
This update fixes an issue where sales order line subtotals were incorrectly displaying tax-included prices when orders were synchronized from Amazon with Avatax. The change ensures that the subtotal accurately reflects the amount before tax by intentionally excluding the Amazon's tax information, which Avatax is best positioned to handle.
Original PR description
When synchronizing orders from Amazon with Avatax enabled, sales order lines currently show no taxes and incorrectly set the tax included price as being the subtotal. This occurs because the fiscal position used does not include any tax, which is the expected behavior for Avatax. The recomputation then uses the full amount of the line (which is tax included), and in the absence of tax, consider this is also the subtotal. We now intentionally do not consider the tax amount from Amazon on the order lines, because the distribution of the Amazon's given tax amount is unknown. The multiple real taxes across that line is not an information that Amazon gives us, and needs to be seen from Avatax. This setup ensures that the subtotal on sales order lines remain accurate. opw-4214775
This update resolves a bug that prevented the 'sign-up tour' from running correctly when the Odoo application was launched with only one app installed locally. The fix ensures the tour functions as expected in this common development scenario, improving the user experience for developers. This change does not impact any business functionality.
Original PR description
When the tour is running in single app locally, it is failing