Daily updates from Odoo
Thursday, December 12, 2024
87 changes
13 changes
Resolved issues and error corrections
A web interface test was adjusted to match a recent change in keyboard shortcut behavior. This helps keep automated checks reliable without changing the product experience for users.
Original PR description
fix test broken by: https://github.com/odoo/odoo/pull/189163/commits/be23ed0ef17d0e5522c2cadc6267799f0a690fdb --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
An error can occur when the email subject contains line breaks when the audit trail is enabled. For example, steps to reproduce using follow-up reports: 1. Add or modify the "Payment Reminder" mail template to add a line break in the subject, like {{ '\n' } 2. Install the 'account_audit_trail' module. 3. Enable audit trail in the settings 4. Attempt to send a follow-up report email to the partner 5. An error will occur: "You cannot remove parts of the audit trail. Archive the record
Original PR description
An error can occur when the email subject contains line breaks when the audit trail is enabled.
For example, steps to reproduce using follow-up reports:
1. Add or modify the "Payment Reminder" mail template to add a line break in the subject, like {{ '\n' }
2. Install the 'account_audit_trail' module.
3. Enable audit trail in the settings
4. Attempt to send a follow-up report email to the partner
5. An error will occur: "You cannot remove parts of the audit trail.
Archive the record instead."
The issue arises because the subject is considered different from the original message, prompting Odoo to attempt an update.
New behavior:
We allow any subject whitespace modifications to be ignored whenchecking for changes in the audit trail.
opw-4317844
Forward-Port-Of: odoo/odoo#187429The mail module override of `_invalidate_im_status` is calling the wrong super method. This PR fixes the issue. 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#190238
Original PR description
The mail module override of `_invalidate_im_status` is calling the wrong super method. This PR fixes the issue. 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#190238
Previously, the fields in the calendar popover were misaligned. This fix ensures proper alignment of the fields. Task-4315829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190234 Forward-Port-Of: odoo/odoo#188757
Original PR description
Previously, the fields in the calendar popover were misaligned. This fix ensures proper alignment of the fields. Task-4315829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190234 Forward-Port-Of: odoo/odoo#188757
Defines dataset directly on website elements such that it can be overridden by other modules if necessary. This was done due to the override in the `test_themes` module completely overriding all attributes of the website_switcher's dropdown items. Runbot Error 106501 Forward-Port-Of: odoo/odoo#190366 Forward-Port-Of: odoo/odoo#187391
Original PR description
Defines dataset directly on website elements such that it can be overridden by other modules if necessary. This was done due to the override in the `test_themes` module completely overriding all attributes of the website_switcher's dropdown items. Runbot Error 106501 Forward-Port-Of: odoo/odoo#190366 Forward-Port-Of: odoo/odoo#187391
Using the fields `lot_ids` on `stock.move` will create a line with the given serial. However, it will use the move's location as reference. But the serial could be in a sublocation. Currently the user has a warning that display the real location of the serial but it's annoying to do it when the sytem know. So set the current location as default and remove the warning for this case. opw-4342448 Description of the issue/feature this PR addresses: Current behavior before PR: Desired
Original PR description
Using the fields `lot_ids` on `stock.move` will create a line with the given serial. However, it will use the move's location as reference. But the serial could be in a sublocation. Currently the user has a warning that display the real location of the serial but it's annoying to do it when the sytem know. So set the current location as default and remove the warning for this case. opw-4342448 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#188061
Incorporate Eduardo Martinez (emtz10) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190149
Original PR description
Incorporate Eduardo Martinez (emtz10) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190149
Issue: ====== url autocomplete doesn't work in mass mailing Steps to reproduce the issue: ============================= - Install website - Create a new mass mailing - Choose welcome message - Select some text and click on the link icon on the toolbar in the snippets sidebar - You will see the hint of `type / to search ....` - If you type that nothing happens Origin of the issue: ==================== The behavior of autocomplete was added only in website but the hint was added f
Original PR description
Issue: ====== url autocomplete doesn't work in mass mailing Steps to reproduce the issue: ============================= - Install website - Create a new mass mailing - Choose welcome message - Select some text and click on the link icon on the toolbar in the snippets sidebar - You will see the hint of `type / to search ....` - If you type that nothing happens Origin of the issue: ==================== The behavior of autocomplete was added only in website but the hint was added for the linkTools in general. Solution: ========= Patch linkTools to include the behavior too. opw-4318224 Forward-Port-Of: odoo/odoo#186741
**Steps to reproduce:** - Create a new mailing - Add a link with "Link" widget - Enter a link with the same domain (e.g. a link to an event) - Insert the link **Issue:** The link is automatically converted to a relative link. This may cause some issue in a multi-company environment where each company has a website (i.e. has its own domain url) and "web.base.url" is configured with the domain of the other company. **Cause 1:** The "Autoconvert to relative link" checkbox is never displ
Original PR description
**Steps to reproduce:** - Create a new mailing - Add a link with "Link" widget - Enter a link with the same domain (e.g. a link to an event) - Insert the link **Issue:** The link is automatically…
**Steps to reproduce:** - Create a new mailing - Add a link with "Link" widget - Enter a link with the same domain (e.g. a link to an event) - Insert the link **Issue:** The link is automatically converted to a relative link. This may cause some issue in a multi-company environment where each company has a website (i.e. has its own domain url) and "web.base.url" is configured with the domain of the other company. **Cause 1:** The "Autoconvert to relative link" checkbox is never displayed and is always applied as it is checked by default. The display toggle is done in "_onURLInput" function of "Link" component, but it is never called by the override function in "LinkDialog". **Cause 2:** Even if the "Autoconvert to relative link" checkbox is displayed, the link will be stripped from its domain as soon as an URL is inputted and save in "this.state.url". When the checkbox is unchecked, "this.state.url" stays unchanged because it is not possible to retrieve the stripped domain from "this.state.url". **Solution 1:** Call the super function in "_onURLInput" function of "LinkDialog". **Solution 2:** Retrieve the URL from the input when the domain should not be stripped and update "this.state.url" with it. opw-4357095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189351
Consider this situation: - Customer invoice. - All invoice lines use a tax type with l10n_es_type=no_sujeto_loc. - The sum of the invoice is 0€. - Sent to SII. Before this patch, the process would raise a wrong `UserError`. If the process was being executed by the cron, **no invoice would be sent**, even if there was only one failing. After this patch, the invoice will be notified nevertheless. If there's any kind of real validation problem, the SII servers will return an error that wi
Original PR description
Consider this situation: - Customer invoice. - All invoice lines use a tax type with l10n_es_type=no_sujeto_loc. - The sum of the invoice is 0€. - Sent to SII. Before this patch, the process would raise a wrong `UserError`. If the process was being executed by the cron, **no invoice would be sent**, even if there was only one failing. After this patch, the invoice will be notified nevertheless. If there's any kind of real validation problem, the SII servers will return an error that will get logged in the invoice. No exceptions raised in Odoo. The process can continue. Faulty invoices are marked; others work. Apart from that, there's also the fix to support the specific case outlined above. @moduon MT-7949 OPW-4344661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189529
**Current behavior:** When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This results in an incorrect total cost displayed on the POS order, which does not match the computed price from the BOM shown on the product page. **Expected behavior:** The total cost for the POS order should match the computed BOM price shown on the product page. **Steps to reproduce:** 1. Creat
Original PR description
**Current behavior:** When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This…
**Current behavior:** When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This results in an incorrect total cost displayed on the POS order, which does not match the computed price from the BOM shown on the product page. **Expected behavior:** The total cost for the POS order should match the computed BOM price shown on the product page. **Steps to reproduce:** 1. Create two products: Product 1 and Product 2. 2. Set both products to be tracked by "quantity" or make them "storable" and assign them to a product category with "average cost" as the costing method (instead of "standard price"). 3. Create a Bill of Materials for each product, ensuring they share at least one component. Make sure BoM Type is 'kit' - Tip: For better visibility of the error, assign a quantity of 10 or more to the shared component in Product 2's BOM, and set the shared component’s `standard_price` (cost) to 5 or higher. This will make the discrepancy in the total cost more apparent. 4. Create the shared component as a new product and assign it a price. 5. Open a new POS order, add Product 1 and Product 2, and close the order. 6. Locate the order and observe that the "total cost" is incorrect. **Cause of the issue:** The stock move filter does not consider that stock moves for BOM lines need to belong to the current product. As a result, if two kit products share components, the stock moves for one product are mistakenly included in the calculation for the other, leading to an incorrect total cost. **Fix:** When filtering out the stock moves, ensure they are correctly associated with the current product by verifying that each stock move’s BOM line belongs specifically to the current product and does not include nested BOMs. opw-4274532 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187130
`*` = [hr_expense, pos_loyalty, product, sale_loyalty , website_sale_loyalty] Before this commit: In the mobile and form view, when a checkbox field had a long label, the checkbox would appear on top, with the label text displayed below. Also, Long labels extend beyond the boundaries of the form view, appearing outside of it. After this commit: Checkbox fields with long labels are now properly aligned in the mobile and form views. The checkbox and its label text are displayed corr
Original PR description
`*` = [hr_expense, pos_loyalty, product, sale_loyalty , website_sale_loyalty] Before this commit: In the mobile and form view, when a checkbox field had a long label, the checkbox would appear on top, with the label text displayed below. Also, Long labels extend beyond the boundaries of the form view, appearing outside of it. After this commit: Checkbox fields with long labels are now properly aligned in the mobile and form views. The checkbox and its label text are displayed correctly, Task-4269578 Forward-Port-Of: odoo/odoo#187980
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input using 'email_split(_and_format)', which finds emails but do not format them. This leads to incoherent behavior as most emails are normalized as we generally always use partners, but not all. In this commit we now split, normalize and format email_to and email_cc in outgoing emails. This fixes a fi
Original PR description
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input…
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input using 'email_split(_and_format)', which finds emails but do not format them. This leads to incoherent behavior as most emails are normalized as we generally always use partners, but not all. In this commit we now split, normalize and format email_to and email_cc in outgoing emails. This fixes a first issue where name are lost if a formatted email was entered in email_cc field. Only address was kept, now the name is correctly found and put back. This also fixes an issue for validated email detection, in order to compare normalized emails. This was introduced at odoo/odoo#185793 and may skip valid emails entered in email_to or email_cc. This commit backports a tool introduced at odoo/odoo@dd4709e579841672b0c2a57d5f2941f3ce770801 which aims at allowing a quick convert from a string holding emails to a list of nicely formatted emails, using normalize version of email addresses. This is the standard we use in most flows. Task-4376876 Followup of task-3704658 Forward-Port-Of: odoo/odoo#190033 Forward-Port-Of: odoo/odoo#189409
27 changes
Enhancements to existing features
A new automated test checks that helpdesk tickets are converted to CRM opportunities or leads correctly based on a user's permissions. This helps reduce the risk of regressions in the support-to-sales handoff process.
Original PR description
This commit introduces a new test case that ensures the conversion of helpdesk tickets to opportunities in the CRM module is functioning as expected. Test Details: A new user is created, and conversion is attempted both before and after assigning the user to the relevant group (crm.group_use_lead). Assertions check for both "Convert to Opportunity" and "Convert to Lead" behavior depending on the user's group permissions. task: 4180279
The delivery pickup location tests were updated to avoid unnecessary email sending during automated checks. This keeps test runs stable and reduces maintenance effort without changing the customer-facing delivery flow.
Original PR description
Now that the salesperson is set on the cart after its confirmation, the test failed because it tried to send an email when the mail configuration was not properly configured. By relying on the standard test common from website_sale, we disable the mail sending, and can simplify the existing test setup. task-4270127
This work begins loading product expiry information into barcode-based stock operations. It should help warehouse teams handle lots and expiration dates more accurately when scanning products, though the change appears to be work in progress.
Timesheet approver information is now shown with a clearer label in tooltips, filters, and grouping options. Employees can also be grouped by their Timesheet Approver, making it easier for managers to review and organize timesheet responsibilities.
Original PR description
This commit renames the label of `timesheet_manager_id` field to have `Timesheets Approver` displayed in tooltip and custom filter/group by. It also adds a group by in `hr.employee` model to let the user to group by Timesheet Approver. task-4313650
Resolved issues and error corrections
This fix ensures placeholder text remains visible when users drag and drop fields such as name or email onto a document in the Sign app. It improves document setup by making field placement clearer and reducing confusion during signing template preparation.
Original PR description
Version: - Master Steps to reproduce: 1. Install the Sign module. 2. Upload a document. 3. Drag and drop the Name, email, etc field. Issue: - The placeholder is not visible when the field is dragged and dropped. Cause: - The placeholder alignment is incorrect. Solution: - Adjusted the margin height of placeholder to align it correctly. task-4347387
The Point of Sale pricer module now stores sample pricing data in the demo area instead of loading it as regular data. This prevents demo-only content from being included where it should not be, keeping production setups cleaner.
Original PR description
In the PR #66351 the demo data was unintentionally merged in the 'data' folder. This PR moves it to the correct 'demo' folder Related Upgrade PR: https://github.com/odoo/upgrade/pull/6831
This fixes an issue in the Indian QR code bill scanning feature where an outdated action reference could trigger warnings or unnecessary processing. The change helps ensure bill scanning behaves more smoothly and keeps translation files up to date.
Original PR description
In commit https://github.com/odoo/enterprise/commit/c60bf8eae152e25003cdeeeafc3b2f267fa483c3, `_l10n_in_get_notification_action` was removed, accidently it's all the references were not changed and an uneccesarry pre-call to `bill_action` was added In this commit we remove the pre-called action and fix the warning
This fixes an issue in the FedEx delivery integration where location request messages could fail because they tried to use translation handling that was not available in that request context. The change restores the previous behavior, helping FedEx pickup location lookups work reliably for online shoppers.
Original PR description
DUring the request to fexed, FEDEXLocationsRequest is not a model, so it does not have an environment. Revert to old code.
Demo data for the point-of-sale pricing feature is now stored in the proper demo area instead of being loaded as regular data. This prevents sample records from being installed where they should not appear, keeping production setups cleaner.
Original PR description
In the PR #66351 the demo data was unintentionally merged in the 'data' folder. This PR moves it to the correct 'demo' folder Associated Upgrade PR: https://github.com/odoo/upgrade/pull/6831
The Partner Ledger now clears the customer filter after users leave a customer statement and later reopen the report from the main accounting area. This prevents old customer selections from carrying over unintentionally, helping users see the expected full report without manually clearing filters.
Original PR description
This commit changes the way filters are loaded on the partner ledger report, particularly when clicking on the Customer Statement smart button from the customer view. **Before this commit:** When opening the report from the customer view, the partner filter was set to the selected customer, which is the desired behavior. However, after leaving the report and reloading it from the main accounting view, the partner filter remained applied, which was not intended. **After this commit:** Once you leave the report and reload it from the main view, the partner filter is reset. task-4274283
The Belgian SODA feature now depends on the full Accounting app instead of only Invoicing. This prevents access errors when users edit bank transactions or configure SODA, because the required accounting permissions are available.
Original PR description
Steps to reproduce: - Install account_accountant & l10n_be - l10n_be_soda is auto installed - Modify a bank transaction OR - Try to configure SODA from settings Access Error: The write method on account.move.line, and the SODA import wizard require `group_account_user` access. But this group is only activated with accounting. This module currently depends on Invoicing (account_accountant) but it should depend on Accounting (accountant). Furthermore, It doesn't make sense to import journal entries if accounting is not available. Issue reported by AVW
Code cleanup and technical improvements
Point of Sale components were adjusted so they can receive the right sales order data directly when used across PoS and Self Order flows. This keeps shared checkout and receipt features more consistent while separating customer display handling where pre-processed data is required.
Original PR description
*: l10n_cl_edi_pos, l10n_de_pos_cert, pos_avatax, pos_blackbox_be, pos_l10n_se, pos_urban_piper Components in the Point of Sale (PoS) context should always be able to receive related model objects as props. Usually, if a component is only used in PoS or Self Order, it can use services to get the needed object. However, if a component is used in both Self Order and PoS, it cannot use services to get the object because the service will be different in each context. Since Self Order and PoS both use the same models, we can pass the model object as props to the component. PoS context components should not be used in the customer display. Since the customer display is a separate context, it receives pre-processed data from PoS. Therefore, we need to create a new component for the customer display.
The field service task setup was simplified by relying on the shared project definition for partner phone information. This reduces duplication behind the scenes and helps keep related project and website project features consistent.
Original PR description
In this commit, we move the partner_phone field in the project module to avoid the duplicate field declaration in website_project. related-https://github.com/odoo/odoo/pull/188581/commits/d958d25629a6e8bc719cb312107ff75a903cf02a task-4357466
This update aligns enterprise mail-related code with the community version by renaming internal channel methods to make their intended private use clearer. It should not change day-to-day behavior for users, but helps keep the codebase consistent and easier to maintain.
Original PR description
Adapt the code based on code in community. odoo/odoo#189366
This change reorganizes automated tests for the Sales Timesheet Enterprise features, especially around leaderboard timer views. It helps maintain reliability of these timesheet experiences without changing day-to-day user functionality.
Original PR description
task-4354311
Miscellaneous changes
Following the change of account type in the community pr, some tests had to be modified. task: 4341375 Forward-Port-Of: odoo/enterprise#75435 Forward-Port-Of: odoo/enterprise#75114
Original PR description
Following the change of account type in the community pr, some tests had to be modified. task: 4341375 Forward-Port-Of: odoo/enterprise#75435 Forward-Port-Of: odoo/enterprise#75114
**Issue:** If a user changes a salary rule to the default Python Code for computation, an error occurs when trying to `Compute Sheet` on an employee's payslip.  **Expected:** The computation should be feasible. **Steps to reproduce:** - Activate Payroll app; - Move to `Configuration/Salary:Rules`; - Select any rule having its `Computation` `Amount Type` field not
Original PR description
**Issue:** If a user changes a salary rule to the default Python Code for computation, an error occurs when trying to `Compute Sheet` on an employee's payslip.  **Expected:** The computation should be feasible. **Steps to reproduce:** - Activate Payroll app; - Move to `Configuration/Salary:Rules`; - Select any rule having its `Computation` `Amount Type` field not set to `Python Code` (e.g. `Regular Pay > House Rent Allowance`);  - Change the `Amount Type` to `Python Code`;  - Create a new payslip entry for any employee and change the structure for the one you changed the rule in (e.g. `Regular Pay`); - Click `Compute Sheet`; **Cause:** The Python code displayed in the computation rule contains an uncommented comment line that. **Fix:** Comment the blocking line. opw-4377712 Forward-Port-Of: odoo/enterprise#75525
Steps to reproduce: - Install account_accountant & l10n_be - l10n_be_soda is auto installed - Modify a bank transaction OR - Try to configure SODA from settings Access Error: The write method on account.move.line, and the SODA import wizard require `group_account_user` access. But this group is only activated with accounting. This module depends on Invoicing (account_accountant) but it should depend on Accounting (accountant). Since this change is not possible for stable, we check fo
Original PR description
Steps to reproduce: - Install account_accountant & l10n_be - l10n_be_soda is auto installed - Modify a bank transaction OR - Try to configure SODA from settings Access Error: The write method on account.move.line, and the SODA import wizard require `group_account_user` access. But this group is only activated with accounting. This module depends on Invoicing (account_accountant) but it should depend on Accounting (accountant). Since this change is not possible for stable, we check for access to the SODA models (`group_account_user`) while the correct fix is applied in master 18.1 (https://github.com/odoo/enterprise/pull/75505) Issue reported by AVW Forward-Port-Of: odoo/enterprise#75480
`*` = [sale_subscription] Before this commit: In the mobile and form view, when a checkbox field had a long label, the checkbox would appear on top, with the label text displayed below. After this commit: In the mobile and form view, checkbox fields with long labels are now properly aligned, with the checkbox and label text displayed. Task-4269578 Forward-Port-Of: odoo/enterprise#75424 Forward-Port-Of: odoo/enterprise#74561
Original PR description
`*` = [sale_subscription] Before this commit: In the mobile and form view, when a checkbox field had a long label, the checkbox would appear on top, with the label text displayed below. After this commit: In the mobile and form view, checkbox fields with long labels are now properly aligned, with the checkbox and label text displayed. Task-4269578 Forward-Port-Of: odoo/enterprise#75424 Forward-Port-Of: odoo/enterprise#74561
Steps to reproduce: 1. Go to Configuration > Email Links 2. click on New -> Blank page 3. click on a record -> Blank page Technical Reason: passed an empty form view and the id got overwritten because of the same name. After this commit: - form view will be open - 'documents.document' related aliases here Task-4265660 Forward-Port-Of: odoo/enterprise#73622
Original PR description
Steps to reproduce: 1. Go to Configuration > Email Links 2. click on New -> Blank page 3. click on a record -> Blank page Technical Reason: passed an empty form view and the id got overwritten because of the same name. After this commit: - form view will be open - 'documents.document' related aliases here Task-4265660 Forward-Port-Of: odoo/enterprise#73622
To comply with Mexican tax regulations (Article 29-A, section VII of the Fiscal Code and the CFDI guide, pg. 22), both the customs number and its emission date must be included in product descriptions for national sales. This commit adds the date(s) of the emission of the customs number(s) to every customer invoice line label task-4132754 Forward-Port-Of: odoo/enterprise#75325 Forward-Port-Of: odoo/enterprise#74475
Original PR description
To comply with Mexican tax regulations (Article 29-A, section VII of the Fiscal Code and the CFDI guide, pg. 22), both the customs number and its emission date must be included in product descriptions for national sales. This commit adds the date(s) of the emission of the customs number(s) to every customer invoice line label task-4132754 Forward-Port-Of: odoo/enterprise#75325 Forward-Port-Of: odoo/enterprise#74475
Before this commit, the trash button displayed in the wizard used when the user clicks on stop button in a task (when a timer is running on that task for that current user) has not the same height than the other buttons displayed in that wizard. This commit makes sure the button has the same height than the other buttons. task-4382070 Forward-Port-Of: odoo/enterprise#75226
Original PR description
Before this commit, the trash button displayed in the wizard used when the user clicks on stop button in a task (when a timer is running on that task for that current user) has not the same height than the other buttons displayed in that wizard. This commit makes sure the button has the same height than the other buttons. task-4382070 Forward-Port-Of: odoo/enterprise#75226
In rare cases there can be more than one tax on the same line with the same taxName and rate. These taxes are different e.g.: ``` Charleston Co Educational Capital Improvements Tax (Special) at 1% Charleston Co Tt (Special) at 1% ``` But `find_or_create_tax()` maps both of them to SC SPECIAL 1%. This doesn't cause issues for invoice_line_ids, those amounts are correct. But the journal items are not because there's only one tax journal item for this tax and its summary total gets over
Original PR description
In rare cases there can be more than one tax on the same line with the same taxName and rate. These taxes are different e.g.: ``` Charleston Co Educational Capital Improvements Tax (Special) at 1%…
In rare cases there can be more than one tax on the same line with the same taxName and rate. These taxes are different e.g.: ``` Charleston Co Educational Capital Improvements Tax (Special) at 1% Charleston Co Tt (Special) at 1% ``` But `find_or_create_tax()` maps both of them to SC SPECIAL 1%. This doesn't cause issues for invoice_line_ids, those amounts are correct. But the journal items are not because there's only one tax journal item for this tax and its summary total gets overwritten instead of added to. This leads to the total on the invoice not matching the sum of debits/credits in the journal items tab. Fix it by adding to the summary total instead of overwriting it. PS. An alternative solution is to create unique tax names by incorporating the jurisCode and possibly other relevant fields. This approach would enhance the accuracy of tax representation on invoices. However, historically, we have prioritized brevity over accuracy [1]. [1] https://github.com/odoo/enterprise/pull/68549 Forward-Port-Of: odoo/enterprise#75464
Issue: When printing PDF reports, long account names cause the report to overflow out of the page. Steps to reproduce: - Install the accounting app - Enable "Analytic Accounting" in the settings - Create one (or more) analytic account(s) with very long names - Open either "Balance Sheet" or "Profit and Loss" reporting - Do an "Analytic Group By" with the created account(s) - Print the PDF Cause: The default style in the associated scss file does not use wrapping. https://github.co
Original PR description
Issue: When printing PDF reports, long account names cause the report to overflow out of the page. Steps to reproduce: - Install the accounting app - Enable "Analytic Accounting" in the settings -…
Issue: When printing PDF reports, long account names cause the report to overflow out of the page. Steps to reproduce: - Install the accounting app - Enable "Analytic Accounting" in the settings - Create one (or more) analytic account(s) with very long names - Open either "Balance Sheet" or "Profit and Loss" reporting - Do an "Analytic Group By" with the created account(s) - Print the PDF Cause: The default style in the associated scss file does not use wrapping. https://github.com/odoo/enterprise/blob/bf6c64b8fd5591f271e9b0f18f40d205a64cd5bd/account_reports/static/src/scss/account_pdf_export_template.scss#L41 Solution: Override the default style by using the "o_overflow_name" class. This is the class already used for handling overflow in the tables' content lines. This gives a more readable result than just editing the "white-space" field (see below for comparison). The proposed solution gives the following result:  As opposed to just editing to "white-space: wrap;"  Ticket: opw-4277596 Forward-Port-Of: odoo/enterprise#74927 Forward-Port-Of: odoo/enterprise#73761
Forward-Port-Of: odoo/enterprise#74972
Original PR description
Forward-Port-Of: odoo/enterprise#74972
Versions -------- - 15.0+ Steps ----- 1. Have a task assigned to you; 2. ensure planned hours are empty; 3. plan the task partially outside working hours (e.g. 16:00 -> 21:00); 4. save. Issue ----- Planned hours are overwritten. Cause ----- Commit 52536bf8bb5 added logic to provide schedule-based start dates for tasks created in Gantt view, as well as other tasks, by overwriting the provided (default) date values. Solution -------- Check whether the provided date values
Original PR description
Versions -------- - 15.0+ Steps ----- 1. Have a task assigned to you; 2. ensure planned hours are empty; 3. plan the task partially outside working hours (e.g. 16:00 -> 21:00); 4. save. Issue ----- Planned hours are overwritten. Cause ----- Commit 52536bf8bb5 added logic to provide schedule-based start dates for tasks created in Gantt view, as well as other tasks, by overwriting the provided (default) date values. Solution -------- Check whether the provided date values are indeed defaults rather than hand-picked values. This can be done by seeing whether the time span between them is exactly 23:59:59, as the default is 00:00:00 -> 23:59:59 This way, tasks scheduled in batch or Gantt can still use schedule-based hours, while user-selected values from a daterange picker don't have to be written twice to select time slot that falls outside the assignee's schedule. opw-3947876 Forward-Port-Of: odoo/enterprise#75391 Forward-Port-Of: odoo/enterprise#65404
Following this commit : New food delivery aggregators have been introduced, including: - Jahez - SkipTheDishes - Rafeeq - Ninja task- 4369004 Forward-Port-Of: odoo/enterprise#75341
Original PR description
Following this commit : New food delivery aggregators have been introduced, including: - Jahez - SkipTheDishes - Rafeeq - Ninja task- 4369004 Forward-Port-Of: odoo/enterprise#75341
38 changes
Enhancements to existing features
The accounting guided tours were simplified to avoid getting stuck on setup steps that may already be completed. The update also adds product description guidance, making the tour smoother and more useful for users learning invoice workflows.
Original PR description
Problem --------- The account tour had some troublesome steps such the one waiting for the user to select a template. If this had already been done before, it meant that the tour would be on stand…
Problem --------- The account tour had some troublesome steps such the one waiting for the user to select a template. If this had already been done before, it meant that the tour would be on stand by. The Send & Print wizard steps were also quite heavy with extra steps being taken to add an email to the partner, this would stop the tour if the selected partner already had a email address. Solution --------- This commit removes - the steps related to the template selection (for both the manual and automatic tours) - the extra steps in the send and print, asking the user to select add an address for the partner without one and simply asks him to Send & Print directly (only for the manual tour, the automatic tour maintain those steps since the automatic tour creates a new partner without email address during the run). This commit adds - Steps to add a description of a product (for both manual and auto) task-4309716 odoo/enterprise/pull/74092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Korean state and province names are now stored in Korean instead of English. This makes local address and invoice information clearer and more appropriate for users operating in Korea.
Original PR description
States are not handled by translations, and the Korean states were added into the data with their english version. As these will mostly be used by Korean users, to issue invoices/... in Korea, it makes more sense to store the Korean version instead. Task [link](https://www.odoo.com/odoo/project/967/tasks/4402317) task-4402317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Korean administrative regions are now stored in Korean instead of English. This makes Korean addresses and invoices clearer and more appropriate for users operating in Korea.
Original PR description
States are not handled by translations, and the Korean states were added into the data with their english version. As these will mostly be used by Korean users, to issue invoices/... in Korea, it makes more sense to store the Korean version instead. task id # 4402317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Send & Print screen now correctly shows the Romanian EDI checkbox when it should be available. This fixes a regression from an earlier refactor, helping Romanian invoicing users access the expected electronic invoicing option.
Original PR description
… on Send & Print During the previous refactor [1], we broke the display of the checkbox of the Romanian EDI. [1]: https://github.com/odoo/odoo/commit/9e769e1b11f22890e5245859053bc8dd31e42634 task-4403772
The configuration document preview now appears below the form on mobile screens, so users no longer need to scroll sideways to see it. Input spacing was also corrected to keep fields comfortably aligned and readable on smaller devices.
Original PR description
Before this commit, the preview was on the rigth and you had to scroll to see the preview of the document. Now, the preview is below on mobile. Task-4377734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale now shows order changes correctly in cases affected by decimal rounding. This helps cashiers and staff see accurate change information during checkout, reducing confusion and potential transaction mistakes.
Original PR description
Before this commit, rounding was passed to the floatIsZero function, while the decimal places should have been passed. This caused the changes to not be displayed correctly in some cases. opw-4393181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how global lead days are handled in subcontracting and stock purchase flows. It helps ensure planned dates and related tests match expected business timing, reducing scheduling errors in manufacturing and purchasing.
Original PR description
Contains style/semantic corrections for commit: 23c39ea opw-4370201
Fixed the display of subchannel hierarchy markers in the Discuss sidebar for right-to-left languages. This improves readability and visual consistency for users working in languages such as Arabic or Hebrew.
Original PR description
The SVG used for the subchannel hierarchy marker was positioned using inline styles. However, `rtlcss` does not process inline CSS rules. This commit moves the positioning rules to SCSS files to ensure proper handling of RTL layouts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A demo invoice for Export/SEZ transactions now uses the correct Export/SEZ tax instead of an inter-state tax. This improves the accuracy of Indian localization sample data and helps users see the right tax treatment in demos.
Original PR description
### Before this commit: > In one of the demo invoices representing Export/SEZ, an incorrect inter-state tax was applied. The tax should have been specific to Export/SEZ transactions. ### After this commit: > The issue has been resolved by correctly applying the Export/SEZ tax, replacing the incorrectly applied inter-state tax.
This fixes an issue where some users could hit an access error while importing data because the import tool tried to read field definitions they were not allowed to access. The import process now skips inaccessible property definitions, helping authorized imports complete more reliably.
Original PR description
We try to import a model, `get_fields_tree` is called recursively to fetch all available fields importable. Since https://github.com/odoo/odoo/issues/174366, it also includes Property of Properties Field, but the code to do that, search directly on the definition model which can be inaccessible for the current record leading to an AccessError. Filtered out Properties where the definition is inaccessible to avoid the issue.
The Point of Sale product grid now displays long product names correctly when product images are turned off. This helps cashiers identify items more easily and avoids confusion during checkout.
Original PR description
**Problem**: When product images are hidden in the Point of Sale (PoS) interface, long product names are clipped. Following the commit: https://github.com/odoo/odoo/commit/1bc90a18807c43206c4620d7faad2579a3a61fc9#diff-15a6744dfd3306e9ae2ff1236ed670da656f52c81619823fb331967dbc790487R25 the product article container's size was fixed using `aspect-ratio: 4 / 3;`. This approach is not suitable for long product names, leading to truncation. **Solution**: Revert the `aspect-ratio: 4 / 3;` style back to `min-height: 4rem` to prevent clipping and allow proper display of long product names. **After fix**  **Steps to reproduce**: 1. Go to the Point of Sale (PoS) settings. 2. Disable the display of product images. 3. Open the PoS interface. 4. Observe that long product names are clipped and improperly aligned. opw-4389643
Users editing tables can now preview solid and custom background colors by hovering over them, matching the existing behavior for gradient colors. This makes it easier to choose the right table cell color before applying it.
Original PR description
### Steps to reproduce: - Open a table (e.g., /table) and select a cell to apply backgroundColor. - Hover over a color in the Gradient tab to see the preview update. - Hover over a color in the Solid or Custom tab — no preview appears. ### Approach: Setting previewMode to true in `onColorHover` temporarily removes `o_selected_td` class in applyTableColor, clearing backgroundColor to allow preview of the hovered color. `COLOR_RESET_PREVIEW` is dispatched on `onColorHoverOut`, reapplying o_selected_td. ### Description of the issue/feature this PR addresses: - Only Gradient tab colors preview on hover in table cells. - Solid and Custom tab colors do not trigger a preview. ### Desired behavior after PR is merged: - Colors from the Solid and Custom tabs now preview on hover in table cells. task-4320353
The accounting walkthroughs now open the right Accounting app menu and use the updated button names. This keeps guided accounting flows usable for teams validating or learning key accounting processes.
Original PR description
Problem --------- When launching the accounting tours, the don't actually run. This is because, when account_accountant is available, the App menu item name is different than when only Invoicing is available. Furthermore, the last steps of the tours where failing because the buttons had be renamed. Solution --------- When account_accountant is available, the app menu name should be `accountant.menu_accounting`, this is done using a patch of the `goToAccountMenu`. Furthemore, the button names for the last steps have been updated accordingly and a few extra steps have been added to generate a transaction. task-4309716 odoo/odoo/pull/188073
This fix ensures page titles in the Room app are included in translations. Businesses using Odoo in multiple languages will see a more consistent localized experience for room-related pages.
Miscellaneous changes
**Current behavior:** When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This results in an incorrect total cost displayed on the POS order, which does not match the computed price from the BOM shown on the product page. **Expected behavior:** The total cost for the POS order should match the computed BOM price shown on the product page. **Steps to reproduce:** 1. Creat
Original PR description
**Current behavior:** When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This…
**Current behavior:** When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This results in an incorrect total cost displayed on the POS order, which does not match the computed price from the BOM shown on the product page. **Expected behavior:** The total cost for the POS order should match the computed BOM price shown on the product page. **Steps to reproduce:** 1. Create two products: Product 1 and Product 2. 2. Set both products to be tracked by "quantity" or make them "storable" and assign them to a product category with "average cost" as the costing method (instead of "standard price"). 3. Create a Bill of Materials for each product, ensuring they share at least one component. Make sure BoM Type is 'kit' - Tip: For better visibility of the error, assign a quantity of 10 or more to the shared component in Product 2's BOM, and set the shared component’s `standard_price` (cost) to 5 or higher. This will make the discrepancy in the total cost more apparent. 4. Create the shared component as a new product and assign it a price. 5. Open a new POS order, add Product 1 and Product 2, and close the order. 6. Locate the order and observe that the "total cost" is incorrect. **Cause of the issue:** The stock move filter does not consider that stock moves for BOM lines need to belong to the current product. As a result, if two kit products share components, the stock moves for one product are mistakenly included in the calculation for the other, leading to an incorrect total cost. **Fix:** When filtering out the stock moves, ensure they are correctly associated with the current product by verifying that each stock move’s BOM line belongs specifically to the current product and does not include nested BOMs. opw-4274532 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190116 Forward-Port-Of: odoo/odoo#187130
Due to the changes in https://github.com/odoo/odoo/pull/153265 , the access url for the test record changed between the setup and the mails being sent. By patching the token generation function we ensure that the token stays the same during the lifetime of the test. Runbot-Error: 98029, 98030 Forward-Port-Of: odoo/odoo#184770
Original PR description
Due to the changes in https://github.com/odoo/odoo/pull/153265 , the access url for the test record changed between the setup and the mails being sent. By patching the token generation function we ensure that the token stays the same during the lifetime of the test. Runbot-Error: 98029, 98030 Forward-Port-Of: odoo/odoo#184770
Issue: ====== url autocomplete doesn't work in mass mailing Steps to reproduce the issue: ============================= - Install website - Create a new mass mailing - Choose welcome message - Select some text and click on the link icon on the toolbar in the snippets sidebar - You will see the hint of `type / to search ....` - If you type that nothing happens Origin of the issue: ==================== The behavior of autocomplete was added only in website but the hint was added f
Original PR description
Issue: ====== url autocomplete doesn't work in mass mailing Steps to reproduce the issue: ============================= - Install website - Create a new mass mailing - Choose welcome message - Select some text and click on the link icon on the toolbar in the snippets sidebar - You will see the hint of `type / to search ....` - If you type that nothing happens Origin of the issue: ==================== The behavior of autocomplete was added only in website but the hint was added for the linkTools in general. Solution: ========= Patch linkTools to include the behavior too. opw-4318224 Forward-Port-Of: odoo/odoo#189437 Forward-Port-Of: odoo/odoo#186741
Only display lot/serial numbers if their forecasted quantity is available. Now when using a 2 step routes (inventory) we only show in PoS the serial numbers that are not already reserved for a stock move (like in sales). To do this we check that the `stock.lot` is located in the `pos_config` default source location. task-id: 4320066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187194
Original PR description
Only display lot/serial numbers if their forecasted quantity is available. Now when using a 2 step routes (inventory) we only show in PoS the serial numbers that are not already reserved for a stock move (like in sales). To do this we check that the `stock.lot` is located in the `pos_config` default source location. task-id: 4320066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187194
**Steps to reproduce:** - Create a new mailing - Add a link with "Link" widget - Enter a link with the same domain (e.g. a link to an event) - Insert the link **Issue:** The link is automatically converted to a relative link. This may cause some issue in a multi-company environment where each company has a website (i.e. has its own domain url) and "web.base.url" is configured with the domain of the other company. **Cause 1:** The "Autoconvert to relative link" checkbox is never displ
Original PR description
**Steps to reproduce:** - Create a new mailing - Add a link with "Link" widget - Enter a link with the same domain (e.g. a link to an event) - Insert the link **Issue:** The link is automatically…
**Steps to reproduce:** - Create a new mailing - Add a link with "Link" widget - Enter a link with the same domain (e.g. a link to an event) - Insert the link **Issue:** The link is automatically converted to a relative link. This may cause some issue in a multi-company environment where each company has a website (i.e. has its own domain url) and "web.base.url" is configured with the domain of the other company. **Cause 1:** The "Autoconvert to relative link" checkbox is never displayed and is always applied as it is checked by default. The display toggle is done in "_onURLInput" function of "Link" component, but it is never called by the override function in "LinkDialog". **Cause 2:** Even if the "Autoconvert to relative link" checkbox is displayed, the link will be stripped from its domain as soon as an URL is inputted and save in "this.state.url". When the checkbox is unchecked, "this.state.url" stays unchanged because it is not possible to retrieve the stripped domain from "this.state.url". **Solution 1:** Call the super function in "_onURLInput" function of "LinkDialog". **Solution 2:** Retrieve the URL from the input when the domain should not be stripped and update "this.state.url" with it. opw-4357095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190385 Forward-Port-Of: odoo/odoo#189351
Content of the IMP: --- In the form picking view, it is possible to edit the move lines that are related to a given move by using the `SMLX2ManyField`. However, untill you save the record, available quantity of quants present in the DB are not updated. This commit ensures that the quants proposed for your move line creation have an available quantity (even if currenlty dirty) and that the quantity used for the next move line creation is both related to the demand of the move, and the real
Original PR description
Content of the IMP: --- In the form picking view, it is possible to edit the move lines that are related to a given move by using the `SMLX2ManyField`. However, untill you save the record, available…
Content of the IMP: --- In the form picking view, it is possible to edit the move lines that are related to a given move by using the `SMLX2ManyField`. However, untill you save the record, available quantity of quants present in the DB are not updated. This commit ensures that the quants proposed for your move line creation have an available quantity (even if currenlty dirty) and that the quantity used for the next move line creation is both related to the demand of the move, and the real availability of the quant used to create it. [FIX] stock: avoid move line reset when opening detailled ops --- This reverts [1] commit b45e249f8f5f36cffdb1ff615953eac7bb45b995. ### Steps to reproduce: - Enable Multi-step routes - Create a storable product: put 5 units on shelf 1 and 5 on shelf 2 - Create and "mark as todo" a delivery order for 3 units - Click on the detailed operation and change the reservation from shelf 1 to shelf 2 > save (the subrecord not the record) - Reopen the details operation #### > The records get resets in front of you ### Cause of the issue: One of the main problems of [1] is that it modifies dirrectly the data's of the props of the component used by the X2many dialog: https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/static/src/fields/stock_move_line_x2_many_field.js#L48 As such, as soon as you mount that component, you will reset the data's used by that same component. Worse, the component is doing this to itself. Hence, if you did not perform a save before opening the details operation you will reset the values to match the DB's data. Furthermore this data change modifying the props of the component we are looking at will force to reload the component with the newly hardcoded data (which explains that you see your last change resetting in front of you). In addition, the `quant_id` field of the stock.move.line model is a very particular field as it is neither stored or computed but is used by the create and the write for the stock.move.line data's to match some of the quant informations: https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/models/stock_move_line.py#L85 https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/models/stock_move_line.py#L310-L311 Therefore this field will never be set on a move. line that was not modified in JS and is not saved yet. In order to take into account the offset between the DB Data and the data's we are setting on the form of stock move it is therefore necessary to perform an rpc to **guess** what quant was used to create a given line. HOWEVER, as teached by the JS framework formation: ``` The first rule of customizing Odoo in JS is: do it in python ``` So that you should not do that matching in JS but rather where it belongs. Finally, modifying the props of a component during the `onMounted` is a super hacky way to use OWL as it is the first Hook for which OWL does not destroy the component because of props inconsistency... opw-4294650 Original issue of the reverted "FIX": --- ### Steps to reproduce - In the setting enable Multi Step Routes - Create a storable prodcut and put 5 units on shelf 1 - Create and Mark as Todo a delivery order for 3 units of your product - Set the quantity of the move to 0 and save the record - Click on the "burger list icon" of the stock move to edit the detailed operations and make the reservations for your 3 units - We want to make the reservation in 2 lines targetting the same quant - Add a new line selecting your shelf 1 quant and set the qty to 1 - Try to add a second one the quant is not proposed ### Cause of the issue: When a quant has been selected at least once and the record is not yet saved the js data of the record contains the info of the quant used to create/update the move line because of the non stored not computed dummy field `quant_id` of the stock move. As such the quant will be considered to already having been used in this transaction and hence not available: https://github.com/odoo/odoo/blame/54e06a1b25ed9e317e368e89979c7c77ddbffc08/addons/stock/static/src/fields/stock_move_line_x2_many_field.js#L52-L54 ### Note: The IMP fixes the original issue + more. This reverted commit already required an other fix: Commit ea4fca8faa4ee84693e645514085a65b92364842 opw-4072541 opw-4294650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189173 Forward-Port-Of: odoo/odoo#186400
Defines dataset directly on website elements such that it can be overridden by other modules if necessary. This was done due to the override in the `test_themes` module completely overriding all attributes of the website_switcher's dropdown items. Runbot Error 106501 Forward-Port-Of: odoo/odoo#190411 Forward-Port-Of: odoo/odoo#187391
Original PR description
Defines dataset directly on website elements such that it can be overridden by other modules if necessary. This was done due to the override in the `test_themes` module completely overriding all attributes of the website_switcher's dropdown items. Runbot Error 106501 Forward-Port-Of: odoo/odoo#190411 Forward-Port-Of: odoo/odoo#187391
Currently, when using `pos_blackbox_be`, if you make an order to be shipped later, you cannot validate your order. Steps to reproduce: ------------------- * Install `pos_blackbox_be` * Set up the blackbox on the pos store * Configure the shop to allow shipping later * Open shop * Make an order * Select customer and ship for a later date * Select payment method and try to validate > Observation: Error message: Modifying registered orders in not allowed Why the fix: ------------ T
Original PR description
Currently, when using `pos_blackbox_be`, if you make an order to be shipped later, you cannot validate your order. Steps to reproduce: ------------------- * Install `pos_blackbox_be` * Set up the blackbox on the pos store * Configure the shop to allow shipping later * Open shop * Make an order * Select customer and ship for a later date * Select payment method and try to validate > Observation: Error message: Modifying registered orders in not allowed Why the fix: ------------ The error is trigerred by a write operation on a `pos.order` record. The field that is being modified is not in the list of white listed fields https://github.com/odoo/enterprise/blob/ade74c4ebecc1d78fe9cd4a4301b332cb79fc6db/pos_blackbox_be/models/pos_order.py#L89-L97 By passing `backend_recomputation=True` in the context we bypass the check of whitelisted fields. It allows to fix without having to modifying the blackbox code. opw-4369744 Forward-Port-Of: odoo/odoo#190316
Incorporate Eduardo Martinez (emtz10) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190149
Original PR description
Incorporate Eduardo Martinez (emtz10) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190149
This commit will do multiple things: - Change one tax type - Change some account types task: 4341375 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190185 Forward-Port-Of: odoo/odoo#189350
Original PR description
This commit will do multiple things: - Change one tax type - Change some account types task: 4341375 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190185 Forward-Port-Of: odoo/odoo#189350
Fix tests broken by https://github.com/odoo/odoo/pull/185960/commits/72fd261edeaac13914e82ec88a639d94f20f63be --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190157
Original PR description
Fix tests broken by https://github.com/odoo/odoo/pull/185960/commits/72fd261edeaac13914e82ec88a639d94f20f63be --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190157
Previously, the fields in the calendar popover were misaligned. This fix ensures proper alignment of the fields. Task-4315829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190234 Forward-Port-Of: odoo/odoo#188757
Original PR description
Previously, the fields in the calendar popover were misaligned. This fix ensures proper alignment of the fields. Task-4315829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190234 Forward-Port-Of: odoo/odoo#188757
Issue: ------ Commit 749e0af3639d243f1d24e40f9c0d374c634eaf79 improves the performance of the `res.device` model in the case of a filtered search (for a given user or a given id). However, when the search is not filtered it takes a long time. This scenario occurs when an administrator goes to the list view of this model. Cause: ------ This is because, although the data in the view is already ordered, the ORM explicitly adds an order (by default, `ORDER BY 'res_device'.'id'`). The re-so
Original PR description
Issue: ------ Commit 749e0af3639d243f1d24e40f9c0d374c634eaf79 improves the performance of the `res.device` model in the case of a filtered search (for a given user or a given id). However, when the…
Issue:
------
Commit 749e0af3639d243f1d24e40f9c0d374c634eaf79 improves the performance of the `res.device` model in the case of a filtered search (for a given user or a given id).
However, when the search is not filtered it takes a long time. This scenario occurs when an administrator goes to the list view of this model.
Cause:
------
This is because, although the data in the view is already ordered, the ORM explicitly adds an order (by default, `ORDER BY 'res_device'.'id'`). The re-sort forces an exhaustive search (before satisfying the limit) which is very time-consuming given the amount of data.
Solution:
---------
Remove the sort in the non-materialised view and let the ORM add it, thus sorting the data just once.
Note:
Optimisations on this view only work if a limit is applied.
Appendices:
-----------
For the query: `SELECT * FROM res_device ORDER BY id LIMIT 80`
Before:
```
Limit (cost=723566.00..723566.20 rows=80 width=154) (actual time=18565.185..18565.198 rows=80 loops=1)
-> Sort (cost=723566.00..728832.00 rows=2106398 width=154) (actual time=18453.028..18453.036 rows=80 loops=1)
Sort Key: d.id
Sort Method: top-N heapsort Memory: 66kB
-> Sort (cost=641185.54..646451.53 rows=2106398 width=154) (actual time=17845.533..18159.999 rows=2355457 loops=1)
Sort Key: d.last_activity DESC
Sort Method: external merge Disk: 348000kB
-> Merge Anti Join (cost=1.11..419946.90 rows=2106398 width=154) (actual time=0.043..15869.920 rows=2355457 loops=1)
Merge Cond: ((d.user_id = d2.user_id) AND ((d.session_identifier)::text = (d2.session_identifier)::text))
Join Filter: ((NOT ((d2.platform)::text IS DISTINCT FROM (d.platform)::text)) AND (NOT ((d2.browser)::text IS DISTINCT FROM (d.browser)::text)) AND ((d2.last_activity > d.last_activity) OR ((d2.last_activity = d.last_activity) AND (d2.id > d.id))))
Rows Removed by Join Filter: 64036293
-> Index Scan using res_device_log__composite_idx on res_device_log d (cost=0.56..230733.16 rows=4674167 width=154) (actual time=0.018..3639.566 rows=4679317 loops=1)
-> Index Only Scan using res_device_log__composite_idx on res_device_log d2 (cost=0.56..142436.83 rows=4674167 width=73) (actual time=0.005..6216.295 rows=64036294 loops=1)
Heap Fetches: 4284155
Planning Time: 0.402 ms
Execution Time: 18588.272 ms
```
After:
```
Limit (cost=0.99..117.94 rows=80 width=154) (actual time=0.028..0.974 rows=80 loops=1)
-> Nested Loop Anti Join (cost=0.99..3079343.32 rows=2106398 width=154) (actual time=0.027..0.968 rows=80 loops=1)
-> Index Scan using res_device_log_pkey on res_device_log d (cost=0.43..202459.12 rows=4674167 width=154) (actual time=0.012..0.118 rows=138 loops=1)
Filter: (NOT revoked)
Rows Removed by Filter: 3
-> Index Only Scan using res_device_log__composite_idx on res_device_log d2 (cost=0.56..0.61 rows=1 width=73) (actual time=0.006..0.006 rows=0 loops=138)
Index Cond: ((user_id = d.user_id) AND (session_identifier = (d.session_identifier)::text))
Filter: ((NOT ((platform)::text IS DISTINCT FROM (d.platform)::text)) AND (NOT ((browser)::text IS DISTINCT FROM (d.browser)::text)) AND ((last_activity > d.last_activity) OR ((last_activity = d.last_activity) AND (id > d.id))))
Rows Removed by Filter: 6
Heap Fetches: 9
Planning Time: 0.368 ms
Execution Time: 0.996 ms
```
Forward-Port-Of: odoo/odoo#189576Trapping the focus in modal dialogs and refocusing the last focused element when closing the dialog are requirements from the WCAG. It was not done up to now for popup snippets in the website. As popups without backdrop aren't dialogs (they don't prevent interacting with the rest of the page), we don't trap the focus in these. Steps to reproduce (Chrome/Firefox): - Drop a popup and save - Wait for the popup to appear - Use tab / shift + tab to navigate around the page => Without the fix,
Original PR description
Trapping the focus in modal dialogs and refocusing the last focused element when closing the dialog are requirements from the WCAG. It was not done up to now for popup snippets in the website. As popups without backdrop aren't dialogs (they don't prevent interacting with the rest of the page), we don't trap the focus in these. Steps to reproduce (Chrome/Firefox): - Drop a popup and save - Wait for the popup to appear - Use tab / shift + tab to navigate around the page => Without the fix, you're able to focus elements outside of the popup. task-4256274 Forward-Port-Of: odoo/odoo#190291 Forward-Port-Of: odoo/odoo#183558
The mail module override of `_invalidate_im_status` is calling the wrong super method. This PR fixes the issue. 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#190238
Original PR description
The mail module override of `_invalidate_im_status` is calling the wrong super method. This PR fixes the issue. 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#190238
### Steps to reproduce: - Enable Multi-Steps Routes in the settings - Inventory > Configuration > Warehouse Management > Locations - Pick any location - With studio add the one2Many field `Store to sublocation` (`location_out_id` of `stock.putaway.rule`) > Close studio - Try to add a line on the associated list #### > Traceback ### Cause of the issue: Adding a line will trigger an onchange of the`stock.putaway.rule` model in order to compute the default data of the new subrecord. H
Original PR description
### Steps to reproduce: - Enable Multi-Steps Routes in the settings - Inventory > Configuration > Warehouse Management > Locations - Pick any location - With studio add the one2Many field `Store to…
### Steps to reproduce: - Enable Multi-Steps Routes in the settings - Inventory > Configuration > Warehouse Management > Locations - Pick any location - With studio add the one2Many field `Store to sublocation` (`location_out_id` of `stock.putaway.rule`) > Close studio - Try to add a line on the associated list #### > Traceback ### Cause of the issue: Adding a line will trigger an onchange of the`stock.putaway.rule` model in order to compute the default data of the new subrecord. However, the code will crash during the `_search_count` of the `_onchange_location_in` because of an invalid domain: https://github.com/odoo/odoo/blob/29939aa5fb1455af89a37293d2f76541ff1645ef/addons/stock/models/product_strategy.py#L80-L88 THis crashed since in our case the `location_out_id` will be a new record created during the onchange to represent the 'stock.location' and from which we are looking at the form. As such, a NewId will be given and treated as an integer in the domain leading to a traceback when the db is served. ### Fix: Onchange method should be robust with respect to the usage of New records and hence the records used here should be replace by their origin if it even exists. opw-4126731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189878 Forward-Port-Of: odoo/odoo#188053
**Current behavior:** Setting a global lead time may result in this time being counted twice in the breakdown of the replenishment for some orderpoint. **Expected behavior:** The global lead time should be counted one time. **Steps to reproduce:** 1. Create a product with a subcontracted BoM 2. Set the system parameter stock.visiblity_days = 365 3. Create a supplierinfo (vendor) on the subcontracted product with 0 delay (lead time) 4. Create a sale order for the subcontracted p
Original PR description
**Current behavior:** Setting a global lead time may result in this time being counted twice in the breakdown of the replenishment for some orderpoint. **Expected behavior:** The global lead time should be counted one time. **Steps to reproduce:** 1. Create a product with a subcontracted BoM 2. Set the system parameter stock.visiblity_days = 365 3. Create a supplierinfo (vendor) on the subcontracted product with 0 delay (lead time) 4. Create a sale order for the subcontracted product 5. In the replenishment report, create an orderpoint for the product and click the (i) on the tree view line 6. See that global visibility days are double-counted **Cause of the issue:** `_get_lead_days()` is called twice here, the second time it ignores vendor lead time but re-counts global visibility days. **Fix:** Ignore the global visibility in a similar manner via context the second time. opw-4370201 Forward-Port-Of: odoo/odoo#189857
**Current behavior:** Having a manufactured product with components, all with 'average' costing, a series of receiptions for the components at difference price points, followed by an MO, followed by another reception at (again) a new price point will result in an imbalanced "Cost of Production" journal if the aforementioned MO is unbuilt. **Expected behavior:** The unbuild operation doesn't leave the journal imbalanced. **Steps to reproduce:** 1. Create a stored product with averag
Original PR description
**Current behavior:** Having a manufactured product with components, all with 'average' costing, a series of receiptions for the components at difference price points, followed by an MO, followed by…
**Current behavior:** Having a manufactured product with components, all with 'average' costing, a series of receiptions for the components at difference price points, followed by an MO, followed by another reception at (again) a new price point will result in an imbalanced "Cost of Production" journal if the aforementioned MO is unbuilt. **Expected behavior:** The unbuild operation doesn't leave the journal imbalanced. **Steps to reproduce:** 1. Create a stored product with average, real_time costing 2. Create a BoM for this product, with 2 stored components (also with average, real_time costing) 3. Create a PO for the components (price is arbitrary), confirm and receive the product 4. Create another PO for the components with a different price from the previous PO, confirm and receive 5. Create an MO for the final product, confirm and consume/produce all 6. Create a final PO for the components with prices different from the previous two orders, confirm and receive 7. Create a second MO for the final product and confirm/consume/produce-all 8. Unbuild the MO from step 5 -> in the "Cost of Production" journal, observe that there is an outstanding balance **Cause of the issue:** When the unbuild operation happens, the current price of the final product informs the SVL's `value` and `unit_price` fields- which of course is not the same as when the MO was completed. We end up with a `unit_price` on the SVL for the final product which is not equal to the sum of the component SVLs' `unit_price` which leads to the generation of account move lines that won't be balanced. **Fix:** During an ubuild operation, stock moves for finished products which may have this issue (i.e., have non-standard costing) with linked SVL records will use that SVL's unit cost for the unbuild SVL (and ensuing journal entries) as opposed to taking the current cost. opw-4062415 Forward-Port-Of: odoo/odoo#189908 Forward-Port-Of: odoo/odoo#188016
An error can occur when the email subject contains line breaks when the audit trail is enabled. For example, steps to reproduce using follow-up reports: 1. Add or modify the "Payment Reminder" mail template to add a line break in the subject, like {{ '\n' } 2. Install the 'account_audit_trail' module. 3. Enable audit trail in the settings 4. Attempt to send a follow-up report email to the partner 5. An error will occur: "You cannot remove parts of the audit trail. Archive the record
Original PR description
An error can occur when the email subject contains line breaks when the audit trail is enabled.
For example, steps to reproduce using follow-up reports:
1. Add or modify the "Payment Reminder" mail template to add a line break in the subject, like {{ '\n' }
2. Install the 'account_audit_trail' module.
3. Enable audit trail in the settings
4. Attempt to send a follow-up report email to the partner
5. An error will occur: "You cannot remove parts of the audit trail.
Archive the record instead."
The issue arises because the subject is considered different from the original message, prompting Odoo to attempt an update.
New behavior:
We allow any subject whitespace modifications to be ignored whenchecking for changes in the audit trail.
opw-4317844
Forward-Port-Of: odoo/odoo#187429**Issue:** If a user changes a salary rule to the default Python Code for computation, an error occurs when trying to `Compute Sheet` on an employee's payslip.  **Expected:** The computation should be feasible. **Steps to reproduce:** - Activate Payroll app; - Move to `Configuration/Salary:Rules`; - Select any rule having its `Computation` `Amount Type` field not
Original PR description
**Issue:** If a user changes a salary rule to the default Python Code for computation, an error occurs when trying to `Compute Sheet` on an employee's payslip.  **Expected:** The computation should be feasible. **Steps to reproduce:** - Activate Payroll app; - Move to `Configuration/Salary:Rules`; - Select any rule having its `Computation` `Amount Type` field not set to `Python Code` (e.g. `Regular Pay > House Rent Allowance`);  - Change the `Amount Type` to `Python Code`;  - Create a new payslip entry for any employee and change the structure for the one you changed the rule in (e.g. `Regular Pay`); - Click `Compute Sheet`; **Cause:** The Python code displayed in the computation rule contains an uncommented comment line that. **Fix:** Comment the blocking line. opw-4377712 Forward-Port-Of: odoo/enterprise#75525
Steps to reproduce: - Install account_accountant & l10n_be - l10n_be_soda is auto installed - Modify a bank transaction OR - Try to configure SODA from settings Access Error: The write method on account.move.line, and the SODA import wizard require `group_account_user` access. But this group is only activated with accounting. This module depends on Invoicing (account_accountant) but it should depend on Accounting (accountant). Since this change is not possible for stable, we check fo
Original PR description
Steps to reproduce: - Install account_accountant & l10n_be - l10n_be_soda is auto installed - Modify a bank transaction OR - Try to configure SODA from settings Access Error: The write method on account.move.line, and the SODA import wizard require `group_account_user` access. But this group is only activated with accounting. This module depends on Invoicing (account_accountant) but it should depend on Accounting (accountant). Since this change is not possible for stable, we check for access to the SODA models (`group_account_user`) while the correct fix is applied in master 18.1 (https://github.com/odoo/enterprise/pull/75505) Issue reported by AVW Forward-Port-Of: odoo/enterprise#75480
Following the change of account type in the community pr, some tests had to be modified. task: 4341375 Forward-Port-Of: odoo/enterprise#75409 Forward-Port-Of: odoo/enterprise#75114
Original PR description
Following the change of account type in the community pr, some tests had to be modified. task: 4341375 Forward-Port-Of: odoo/enterprise#75409 Forward-Port-Of: odoo/enterprise#75114
### Steps to reproduce the issue: 1. Create two Companies, one in EUR, the other in USD 2. In EUR Company, create two Invoices with the following settings: - Total price of 1000 - Invoice date: today and one month ago - You must be able to isolate them using Partner Ledger filters (not date) 3. In USD Company, add EUR Rates as follows: - Today: 1USD = 1EUR - One month ago: 1USD = 0.9EUR 4. In USD Company, open General Ledger and isolate the Invoices 5. First, set
Original PR description
### Steps to reproduce the issue: 1. Create two Companies, one in EUR, the other in USD 2. In EUR Company, create two Invoices with the following settings: - Total price of 1000 - Invoice date: today…
### Steps to reproduce the issue:
1. Create two Companies, one in EUR, the other in USD
2. In EUR Company, create two Invoices with the following settings:
- Total price of 1000
- Invoice date: today and one month ago
- You must be able to isolate them using Partner Ledger filters (not date)
3. In USD Company, add EUR Rates as follows:
- Today: 1USD = 1EUR
- One month ago: 1USD = 0.9EUR
4. In USD Company, open General Ledger and isolate the Invoices
5. First, set the timeframe from beginning last month to end of this month
6. The Invoice of last month is using the current rate, with an amount of 1000$
7. Second, set the timeframe to the current month only
8. The Initial Balance is using the previous rate, with an amount of 1111.11$
### Explanation:
The initial balance is the balance of the company before the start of the currently reviewed timeframe. To calculate it, we must update the options to target the time before the current timeframe. Since we retrieve the rate used for this calculation using the updated options, we use the last rate before the current timeframe instead of the rate used in the current timeframe.
### Fix reasoning:
Since every amount must be calculated using the current rate, we will retrieve it using the main options and not the updated ones.
opw-4299153
Forward-Port-Of: odoo/enterprise#75517
Forward-Port-Of: odoo/enterprise#75441To comply with Mexican tax regulations (Article 29-A, section VII of the Fiscal Code and the CFDI guide, pg. 22), both the customs number and its emission date must be included in product descriptions for national sales. This commit adds the date(s) of the emission of the customs number(s) to every customer invoice line label task-4132754 Forward-Port-Of: odoo/enterprise#75325 Forward-Port-Of: odoo/enterprise#74475
Original PR description
To comply with Mexican tax regulations (Article 29-A, section VII of the Fiscal Code and the CFDI guide, pg. 22), both the customs number and its emission date must be included in product descriptions for national sales. This commit adds the date(s) of the emission of the customs number(s) to every customer invoice line label task-4132754 Forward-Port-Of: odoo/enterprise#75325 Forward-Port-Of: odoo/enterprise#74475
9 changes
New functionality added to Odoo
This pull request adds translations for the Dutch payroll modules, specifically for accounting accounts. This update ensures the system correctly supports Dutch accounting regulations and reporting requirements, improving accuracy and compliance for businesses operating in the Netherlands.
Enhancements to existing features
This update simplifies the accounting report button bar by ensuring the XLSX export button is consistently displayed. This change reduces complexity and improves the user experience by making the key export functionality readily available on all accounting reports.
Original PR description
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561
Resolved issues and error corrections
This update corrects a technical issue in the Romanian localization reports module that prevented the correct handling of date formats. The change ensures that date information is consistently formatted as strings, resolving potential reporting errors and improving data accuracy. This update focuses on internal reporting processes.
Original PR description
Options dict is not supposed to contain date objects.
This update restores the Sales Order (SO) and Service Order (SOL) buttons within the project updates view for field service projects. Previously, these buttons were accidentally removed, preventing users from easily accessing related sales information. This change ensures users can seamlessly link project updates to their corresponding sales orders.
Original PR description
Versions: ---------- - 17.0 Steps to Reproduce ------------ - Create a product and add the template of the field service project. - Create a sale order. - Open the project updates. - We do not see the SO and SOL buttons. Issue ------------ - SO and SOL smart button was removed on project updates in this commit https://github.com/odoo/enterprise/commit/7a82c52fb007ad0f827dd5d124f80d6195bff919 Fix ---------- - We are adding the SO and SOL buttons back. - So the user can at least see the linked data. task-3887972
This update fixes a potential upgrade issue caused by incorrectly mapping window actions to experimental grid views. Removing grid views previously led to problems during updates, particularly when uninstalling related modules. This change ensures that grid views are properly handled, preventing future upgrade complications.
Original PR description
When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields. Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise). Forward-Port-Of: odoo/enterprise#74912
This update prevents the creation of templates when uploading PDF documents for signature processing via the 'Upload a pdf & sign' button. Previously, users could inadvertently save template information. This change ensures a cleaner workflow and avoids unnecessary data storage.
Original PR description
When uploading a pdf through "Upload a pdf & sign" button, no template should be saved. Hence the "Template Properties" button shouldn't show up. This commit aims to hide the button for this type of files. Task: 4317966 Forward-Port-Of: odoo/enterprise#73912
A bug was causing two 'Sign Now' buttons to appear in the signature request dialog. This has been corrected by adjusting the button visibility condition to ensure it disappears when either condition is met. This improves the user experience and prevents confusion.
Original PR description
Version: - 17.0 Step to reproduce: - upload sign template - click on sign now button on template Issue: - two sign now buttons are visible to user Cause: - there is an issue in condition to make button invisible as it require both the condition to be true to make button invisible Solution: - change condition which will make button invisible when any one condition true. task-4234996
This update fixes an issue where clicking between buttons in the softphone interface would unexpectedly generate an input field. The fix ensures that input is only created when a user actively clicks on a button, improving the user experience and preventing unwanted data entry.
Original PR description
Issue: Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated. Fix: Do nothing when click in this situation, only generate input when clicking on buttons.
This update resolves an issue where incoming call ringtones were playing across all open tabs in Odoo. Now, ringtones will only play on the main 'master' tab, creating a cleaner and less disruptive user experience. This improves usability and reduces potential confusion for users.
Original PR description
Currently when receiving incoming calls, it's possible that all opened tabs will play the ringtone. To reduce the chaos, we now only play the incoming ringtone on the master tab. Task-4402909