Daily updates from Odoo
Navigate
Branch
Thursday, February 22, 2024
65 changes
13 changes
Enhancements to existing features
This update adjusts Odoo's tax settings to reflect a recent change in Malaysian SST tax regulations. Starting March 1, 2024, the standard SST tax rate will shift from 6% to 8%. This change ensures Odoo accurately reflects the current tax requirements for Malaysian businesses.
Original PR description
As of the first of March 2024, the SST tax will increase from 6% to 8%. To that end, the current 6% tax will be set to inactive by default, and we will add a new 8% service tax to replace it. Task id # 3748127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154966 Forward-Port-Of: odoo/odoo#154534
Resolved issues and error corrections
This update fixes a translation issue in the DIN 5008 localization for German sales orders. Previously, certain terms like 'Quotation No' were not fully translated. This change ensures all terms in the document layout are correctly translated, improving the user experience for German-speaking customers.
Original PR description
Steps to reproduce: - - Install the DIN 5008 localization - Settings > change the document layout to the DIN 5008 layout - Add the German language to the database and make a contact German - Create a…
Steps to reproduce: - - Install the DIN 5008 localization - Settings > change the document layout to the DIN 5008 layout - Add the German language to the database and make a contact German - Create a sales order for that contact - Click the Preview Button - Click the View Details button **Some terms such as 'Quotation No' are not transalted.** Cause of the issue: - In the pot file, the `odoo-python` flags are not present on the keys of terms present in python files. As such the translations of these terms will not be loaded here: https://github.com/odoo/odoo/blob/4c22cfe59972342363736effc8a37108dbed1f97/odoo/tools/translate.py#L1670 since the lines are not tagged as `PYTHON_TRANSLATION_COMMENT`. Prior to 17.1, (this change: commit 60f66ef21fe96c9418b0b3704149aea9dde70ad1) the translations were still loaded for the "wrong" reasons that they were not tagged as `JAVASCRIPT_TRANSLATION_COMMENT`: https://github.com/odoo/odoo/blob/d9e554bae879c294f39f10d1b666343431ed0e3d/odoo/tools/translate.py#L1681-L1683 Fix: - In order to load the translations of these terms we add the `odoo-python` flags to the keys corresponding to python translations. This can be done automatically by exporting the translations corresponding to the pot file and by replacing the current pot with the newly created file. Even if it was not necessary for the fix to work, the keys have been changed accordingly in the associated po files (just as done everywhere else in the code base). Notes: - - The keys of the nl.po were already updated and have not been changed. - The translation of "Sales Order" in the de.po was changed by the export to the term that seems to be uniformly used in the code base. opw-3734589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual glitch in the ecommerce category scrollbar on recent Chrome browsers and ensures consistent styling across Odoo. It also addresses an issue where the scrollbar was obscured on touchscreens and ensures proper display on various devices.
Original PR description
In commit https://github.com/odoo/odoo/commit/bdede43e1ea4587185a9f37f051cee87a61cf488 an improvement was made to increase the scrollbar height on hover to make it easier to scroll. However chromium…
In commit https://github.com/odoo/odoo/commit/bdede43e1ea4587185a9f37f051cee87a61cf488 an improvement was made to increase the scrollbar height on hover to make it easier to scroll. However chromium updated the way ::webkit-scrollbar works breaking the behavior on recent browser. On firefox the margin was applied without the change of height on the scrollbar creating a visual glitch on hover. On chromium >121 the `scrollbar` property takes priority over the `::webkit`-x to keep the scrollbar styling with height change on webkit browser we have to apply the `scrollbar` property only on Firefox. The mixin was used only on `website_sale` filter offcanvas and category horizontal scrollbar, this commit removes the mixin and customization on the offcanvas vertical scroll to make it consistent with the other offcanvas across website. This PR also disables the scrollbar hover effect on touchscreens. The transform was causing an issue on some devices displaying the scrollbar behind the items, thus it's now applied on the container. Note: We use not `.o_wsale_filmstip_fancy_disabled` to avoid the `scrollbar` property being set when the Javascript is not loaded yet. Otherwise the scrollbar would be invisible until a hover from the user. task-3718501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152456
This update fixes an issue where large numbers (formatted with commas) were being incorrectly parsed when sharing data via Odoo's spreadsheet feature. Previously, the share link would display the number in a simplified format. Now, the share link exports the raw, formatted value, ensuring accurate sharing of amounts, especially those with thousands or millions.
Original PR description
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#154712 Forward-Port-Of: odoo/odoo#153704
This update optimizes how Odoo handles DELETE and UNLINK commands within StaticLists, specifically when adding or removing actions. Previously, a large number of these commands caused significant performance slowdowns. Now, the system processes these commands more efficiently, resulting in faster operation times and a smoother user experience.
Original PR description
Before this commit, calling _applyCommands with a lot of commands DELETE or UNLINK on a StaticList already containing a lot of commands was very slow. This happened for instance in the Automated Rule…
Before this commit, calling _applyCommands with a lot of commands DELETE or UNLINK on a StaticList already containing a lot of commands was very slow. This happened for instance in the Automated Rule form view, click on "Add an action", and in the dialog form view, select a "mail" type, e.g. "Add followers". In that form view there's a many2many field "available_model_ids" which contains at first almost all models of the database (LINK commands). Switching to a "mail" model restricts those models to the ones inheriting from the thread mixin, i.e. it generates a lot of UNLINK commands. On runbot, in represents 1000+ LINK and UNLINK commands. This could take several seconds. With this commit, we no longer iterate over all commands when applying a DELETE or UNLINK command. Instead, we simply push the command, store somewhere the information that we applied such a command, and after having processed all commands, we iterate (once) over this._commands, this.records and this._currentIds to do the necessary cleanups. task 3599674 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#154568
This update resolves an issue where exporting invoices with 0% tax generated incorrect XML files, leading to warning and error messages. The fix ensures that tax exemption information is now correctly placed only within the relevant tax total section of the invoice XML, aligning with UBL standards. This improves data accuracy and avoids potential export failures.
Original PR description
Previously, exporting BIS3 when there is a 0% tax in the invoice will results in the XML showing warning of UBL-CR-601. But if we do not include any TaxExemptionReason reason at all, a fatal error…
Previously, exporting BIS3 when there is a 0% tax in the invoice will results in the XML showing warning of UBL-CR-601. But if we do not include any TaxExemptionReason reason at all, a fatal error BR-E-10 will pop up.
Here is the details of those 2 rules:
```xml
(with context: /*/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory
[normalize-space(cbc:ID) = 'E'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT'])
<assert id="BR-E-10" flag="fatal" test="exists(cbc:TaxExemptionReason) or
exists(cbc:TaxExemptionReasonCode)">
[BR-E-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118)
"Exempt from VAT" shall have a VAT exemption reason code (BT-121)
or a VAT exemption reason text (BT-120). </assert>
and
(no context)
<assert id="UBL-CR-601" flag="warning" test="
not((cac:InvoiceLine|cac:CreditNoteLine)/cac:Item/
cac:ClassifiedTaxCategory/cbc:TaxExemptionReason)">
[UBL-CR-601]-A UBL invoice should not include the InvoiceLine
Item ClassifiedTaxCategory TaxExemptionReason </assert>
```
Based on these rules, we can conclude that:
- TaxExemptionReason must not appear in InvoiceLine/Item/ClassifiedTaxCategory
- TaxExemptionReason must appear (when some line in invoice has exempt tax) in TaxTotal/TaxSubtotal/TaxCategory
Previously, the TaxExemptionReason will appear on both places. This commit fixes that and adds a test to ensure that when a 0% tax is present, TaxExemptionReason only appear in TaxTotal/TaxSubtotal/TaxCategory
task-id: 3703206
Forward-Port-Of: odoo/odoo#154865
Forward-Port-Of: odoo/odoo#154055This update resolves an issue that prevented users from correctly editing mega menus in Odoo. The change was necessary due to a recent update to Bootstrap, which triggered an error when the mega menu's dropdown behavior was being utilized. The fix involves a temporary adjustment within Bootstrap itself to ensure proper functionality.
Original PR description
Since [1] when the mega menu were first introduced, to make their edition possible, the bootstrap dropdown behavior was neutralized by removing the `data-[bs-]toggle` attribute. In [2] when Bootstrap…
Since [1] when the mega menu were first introduced, to make their edition possible, the bootstrap dropdown behavior was neutralized by removing the `data-[bs-]toggle` attribute. In [2] when Bootstrap was upgraded to version 5.1.3, the `dataApiKeydownHandler` event handler that is called when up, down or escape are pressed raises an error if `data-bs-toggle` cannot be found on a previous sibling of the dropdown. This makes the approach chosen in [1] incomplete. This commit avoids this issue by temporarily adding a class that is excluded from the event handler selector. The patch must unfortunately be applied within bootstrap itself because the event handler is registered right after the method is defined and we have no way to access the registered event handlers afterwards. This makes it impossible to patch the called method from outside, nor its associated selector. We cannot simply update the selector that was already patched by [3] because it is also used by other methods. A test is included which should mitigate the risk of accidentally losing this patch upon bootstrap upgrades. Steps to reproduce: - Create a mega menu. - Edit the page. - Open the mega menu. - Click inside the mega menu content to have a cursor selection. - Press the arrow up key, the arrow down key or the escape key. => An error dialog was displayed. The same issue happened with a nested menu instead of a mega menu. [1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7 [2]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968 [3]: https://github.com/odoo/odoo/commit/daca8fe4e3da4a5ad5fabf3730496a3919af8abc task-3614926 opw-3741670 Forward-Port-Of: odoo/odoo#154864 Forward-Port-Of: odoo/odoo#154409
This update resolves an issue where dropdown menus within the Odoo Studio editor wouldn't close when the toolbar was clicked. The fix addresses a technical limitation with the iframe environment, ensuring that clicks outside the editor now properly close dropdowns. This improves the user experience when working with reports and documents in Studio.
Original PR description
Steps to reproduce: =================== - Open any app (sales for example) - Toggle studio - select reports tab - Select any report - Select some text and open any dropdown (font size or color) - Click somewhere else on the document - Select some text again - The dropdown stayed open from the first select Origin of the issue: ==================== Clicking somewhere on the document in studio doesn't trigger the events `defined in bootstrap/js/dist/dropdown.js` because of the iframe. Solution: ========= Trigger click event on toggle button for the opened dropdown when hiding the toolbar to close them task-3674736 Forward-Port-Of: odoo/odoo#152681
This update fixes a bug where articles were incorrectly flagged as needing to be saved, leading to frequent and unwanted autosaves. The fix removes irrelevant information (history IDs) from the comparison process, ensuring autosaves only occur when actual content changes are made. This improves performance and user experience.
Original PR description
Issue: Articles were erroneously marked as changed, leading to unnecessary autosaves. Part of this was caused by the inclusion of history IDs in the content comparison process, which differ even without substantive content changes. Solution: Applied `stripHistoryIds` to the content obtained from the WYSIWYG editor before performing the dirty check. This ensures that comparisons focus solely on actual content changes, eliminating history IDs as a factor in the dirty state determination. opw-3707380 Forward-Port-Of: odoo/odoo#154068
This update corrects a bug where Stripe payment providers incorrectly linked to the wrong website when activating Stripe for multiple companies. The fix ensures each Stripe provider is associated with the correct company's website, preventing errors and ensuring consistent payment processing across all company environments. This improves stability and reliability for our multi-company users.
Original PR description
Description: In a multi-company environment, `payment.provider` records are specific to each company. After activating Stripe on Company 1, you can set a Website for the record if you wish. If you…
Description: In a multi-company environment, `payment.provider` records are specific to each company. After activating Stripe on Company 1, you can set a Website for the record if you wish. If you wish to activate Stripe for Company 2, Odoo will use `.copy()` to create a new `payment.provider` record for Company 2. However, this will lead to differing incorrect behavior depending on the version. On 16, a new `payment.provider` record will be created, but will be connected to the Website set on Company 1's provider. On 17, Odoo will throw an error after a `check_company` call reveals that the Website set on the new record is for the wrong company, preventing the record from being created. In both cases, the `.copy()` grabs the optional Website set on the existing `payment.provider` record to be used incorrectly for the new record. Desired behavior after PR is merged: The Website relation is always neutralized when Odoo creates a new Stripe `payment.provider` record using the `.copy()` method opw-3683338 Forward-Port-Of: odoo/odoo#154521 Forward-Port-Of: odoo/odoo#154280
This update fixes an issue where the legal note from a fiscal position on invoices was not appearing after installing the l10n_it module. The problem stemmed from an incorrect condition within the module that limited note display to Italian companies. Removing this condition ensures the note appears correctly for all invoices.
Original PR description
Steps to reproduce: - Install Accounting - Create a fiscal position with a legal note - Create an invoice with the created fiscal position - Preview the invoice => The legal note from the fiscal position appears on the invoice as expected - Install l10n_it - Preview the invoice => The legal note from the fiscal position doesn't appear anymore Cause: The condition to display the legal note from the fiscal position is overridden by l10n_it module to only display it for Italian companies, which is not correct. Solution: Remove the condition about the Italian companies. By removing that condition, the inherited view becomes useless as the overridden condition is the same as the original one. The inherited view will have to be removed in master. opw-3709443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153638
Documentation and clarification updates
This pull request formally confirms the signing of a legal agreement (CLA) with Asergo, a key partner for Odoo's SaaS offering. This action ensures compliance and strengthens our legal relationship. The change is a procedural update related to legal documentation.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154828
This pull request formally incorporates a legal agreement (CLA) from Buckstop Labs. Previously, this agreement was missing, but it has now been added to ensure compliance with Odoo's open-source licensing. This update allows for the continued use of Buckstop Labs' contributions within the Odoo project.
Original PR description
Description of the issue/feature this PR addresses: added my agreement Current behavior before PR: did not include my agreement Desired behavior after PR is merged: you can read the .md i added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154830
19 changes
New functionality added to Odoo
Mexican Point of Sale users can now create a single global invoice from one or more eligible POS orders. This streamlines compliance invoicing by using a configured default customer and preventing invoice creation when required conditions are not met.
Original PR description
Add the possibility to create a global invoice from (a) point of sale order(s). It can be done through the list view or the form view of the orders using the action menu and select 'Global Invocie'. The user needs to configure a default customer for the global invoice in the settings of the point of sale and it will automatically add that customer to the orders that have been selected for the global invoice. The global invoice contains all the move lines corresponding to the selected orders and the reference (No Identificación) of the order. The user can't create a global invoice: - Without having a default customer for the global invoice set - Without selectionf at least one order - If one (or more) order are already assigned tot a customer - If one or more order are already invoiced Task-2192391
Enhancements to existing features
Users creating map views in Studio now receive a clearer message when setup cannot be completed. This helps them understand the issue faster and reduces confusion or support needs during configuration.
This update restructures how IoT devices communicate through web connections, moving print-specific behavior into the printer driver. This makes it easier to support additional connected devices in the future without redesigning the communication flow.
Original PR description
The purpose of this PR is to simplify the implementation of websockets for other devices Before the only message supported by ws was "print" and the websocket_client called _action_default() method Now the message name is 'iot_action' and websocket_client call the action() instead of _action_default, send_to_controller() is now called from the printer driver task-3756857 [odoo/odoo#154543](https://github.com/odoo/odoo/pull/154543)
Field service tasks now show a clear count of products that need to be picked up for the linked sales order. This helps technicians prepare for customer visits without needing sales access or viewing pricing and margin details.
Original PR description
Currently, the user has to open the SO form view and check the deliveries to identify if they need to bring something and what. This is not the most practical. In addition, it is common for companies not to give sales access to field workers as they don't want them to see the prices and the margin they are making. In this PR we'll add a 'x products to pick up' stat button should represent the following stock move lines - associated with the SO linked to the task - and that are not done or canceled - and the destination location should be a 'customer location' type Task-3511049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Intrastat reports now group entries by country, currency, and commodity code, making the report easier to review and less cluttered. Users can still expand grouped lines to see individual account moves, while arrival or dispatch-only views also show group and overall totals.
Original PR description
In the intrastat report, each account move is now grouped by country (using norm ISO 3166), currency (norm ISO 4217) and commodity code. Each line can be unfolded to show each individual account move with its corresponding values. When only Arrival or Dispatch is selected, the total value for each group is shown as well as a total line for the total value of Arrivals or Dispatches. This change was done because usually people and organisation to which they must report this information aren't interested in each individual move but rather to have an overall view of how much of a certain commodity was ship to a certain country. The previous report was too verbose. People still have the options to unfold all the lines if they need it. task-3605696 X-original-commit: bede57056142a167d06a652cc208203c9f430615
Features or functions removed from Odoo
The appointment app no longer shows onboarding banners that were considered distracting and less helpful than expected. This simplifies the appointment setup experience and removes related onboarding screens, links, and tests.
Original PR description
Banners are usually distracting and do not provide the help we expected. The calendar onboarding is removed in the related COM PR. Task-3724601
Code cleanup and technical improvements
Spreadsheet pivot-related actions were updated to use the new command names, keeping Enterprise aligned with the related core Odoo change. This is an internal cleanup that helps maintain compatibility and reduces confusion for future spreadsheet updates.
Original PR description
This commit is the counterpart of https://github.com/odoo/odoo/pull/154701. It updates the code to the new name of the pivot command. Task: 3748421
Miscellaneous changes
This PR changes the order of appointment types on the appointment page based on the appointment's published status. This makes it easier for internal users to access published appointments first. Task-3725160 Forward-Port-Of: odoo/enterprise#56782 Forward-Port-Of: odoo/enterprise#56377
Original PR description
This PR changes the order of appointment types on the appointment page based on the appointment's published status. This makes it easier for internal users to access published appointments first. Task-3725160 Forward-Port-Of: odoo/enterprise#56782 Forward-Port-Of: odoo/enterprise#56377
Suppose the following reconciliation situation: Company's currency = EUR We want to reconcile 105 USD = 98 EUR with 105 CAD = 73 EUR Before this PR: When encountering two foreign currencies Odoo will try to reconcile in EUR (company's currency). After the first step of reconciliation there is a residual of 25 EUR = 27 USD left on the first line. We therefore try to create a write-off of 25 EUR and reconcile it with the residual, those 25 EUR are converted in USD at the Odoo rate =>
Original PR description
Suppose the following reconciliation situation: Company's currency = EUR We want to reconcile 105 USD = 98 EUR with 105 CAD = 73 EUR Before this PR: When encountering two foreign currencies Odoo will try to reconcile in EUR (company's currency). After the first step of reconciliation there is a residual of 25 EUR = 27 USD left on the first line. We therefore try to create a write-off of 25 EUR and reconcile it with the residual, those 25 EUR are converted in USD at the Odoo rate => 24 USD. 27 USD != 24 USD, the reconciliation can't be full while it should have. Now we detect cases where there is only one residual left in multicurrency and create the write-off in that currency. opw-3497793 Forward-Port-Of: odoo/enterprise#57176 Forward-Port-Of: odoo/enterprise#54069
See community commit Task: 3730232 Forward-Port-Of: odoo/enterprise#57086 Forward-Port-Of: odoo/enterprise#56253
Original PR description
See community commit Task: 3730232 Forward-Port-Of: odoo/enterprise#57086 Forward-Port-Of: odoo/enterprise#56253
Steps to reproduce: - Create a payslip with mpf gross less than $7100 Current behaviour: - ERMC is missing because it not included when mpf gross is less than $7100 Expected behaviour: - ERMC should be included by the gov law Explanation: - By gov law, employer mpf contribution doesn't need to check with the mpf threshold amount $7100. Therefore remove the checking for ERMC. task-3643660 X-original-commit: 45321a2 Forward-Port-Of: odoo/enterprise#57013 Forward-Port-Of:
Original PR description
Steps to reproduce: - Create a payslip with mpf gross less than $7100 Current behaviour: - ERMC is missing because it not included when mpf gross is less than $7100 Expected behaviour: - ERMC should be included by the gov law Explanation: - By gov law, employer mpf contribution doesn't need to check with the mpf threshold amount $7100. Therefore remove the checking for ERMC. task-3643660 X-original-commit: 45321a2 Forward-Port-Of: odoo/enterprise#57013 Forward-Port-Of: odoo/enterprise#56897
Forward-Port-Of: odoo/enterprise#57102
Original PR description
Forward-Port-Of: odoo/enterprise#57102
Issue: Embedded views within articles incorrectly include loader and error messages as part of the content upon saving, leading to irrelevant data being stored. Steps to Reproduce: 1. Install Knowledge and create a new Article. 2. Add a calendar at the top of the Article. 3. Add many lines and then a new calendar so that this one is not visible when we scroll to the top of the article. 4. Refresh the page. 5. Each time the mouse leaves the page is uselessly saved and the first calendar
Original PR description
Issue: Embedded views within articles incorrectly include loader and error messages as part of the content upon saving, leading to irrelevant data being stored. Steps to Reproduce: 1. Install…
Issue: Embedded views within articles incorrectly include loader and error messages as part of the content upon saving, leading to irrelevant data being stored. Steps to Reproduce: 1. Install Knowledge and create a new Article. 2. Add a calendar at the top of the Article. 3. Add many lines and then a new calendar so that this one is not visible when we scroll to the top of the article. 4. Refresh the page. 5. Each time the mouse leaves the page is uselessly saved and the first calendar is reloaded Solution: Enhanced the `cleanForSave` method in `knowledge_plugin.js` to filter out non-content elements from embedded views. This is achieved by only retaining child elements with a `data-prop-name` attribute within `.o_knowledge_behavior_type_embedded_view` elements. As a result, loaders or error messages, which do not have this attribute, are excluded from the saved content, ensuring that only relevant, intended content is preserved. opw-3707380 Forward-Port-Of: odoo/enterprise#56626
After the sign conversion to OWL, when accessing an unsigned shared document it would show a "send" button close to the public user. However, since it's a shared document, there is no email to send the document to. Clicking on it, will cause a traceback. This commit hides this button for shared requests. task-3710635 Forward-Port-Of: odoo/enterprise#57092 Forward-Port-Of: odoo/enterprise#55470
Original PR description
After the sign conversion to OWL, when accessing an unsigned shared document it would show a "send" button close to the public user. However, since it's a shared document, there is no email to send the document to. Clicking on it, will cause a traceback. This commit hides this button for shared requests. task-3710635 Forward-Port-Of: odoo/enterprise#57092 Forward-Port-Of: odoo/enterprise#55470
Create a Vendor Bill with a Colombia Partner and withholding tax Accounting > Reporting > Certificado de Retención en IVA Print PDF Issue: Currently the lines in the report are being generated despite the balance in “tax_base_amount” (“Monto Total Operacion) being 0.00. Expected behavior: If the “tax_base_amount is 0.00 do not consider this balance neither in the report lines nor in the SUM of the Report total. opw-3704972 Forward-Port-Of: odoo/enterprise#56849 Forward-Port-Of: odo
Original PR description
Create a Vendor Bill with a Colombia Partner and withholding tax Accounting > Reporting > Certificado de Retención en IVA Print PDF Issue: Currently the lines in the report are being generated despite the balance in “tax_base_amount” (“Monto Total Operacion) being 0.00. Expected behavior: If the “tax_base_amount is 0.00 do not consider this balance neither in the report lines nor in the SUM of the Report total. opw-3704972 Forward-Port-Of: odoo/enterprise#56849 Forward-Port-Of: odoo/enterprise#56308
Same as on user.preference, `how_to_call_on_mobile` should be editable. Forward-Port-Of: odoo/enterprise#52362 Forward-Port-Of: odoo/enterprise#52240
Original PR description
Same as on user.preference, `how_to_call_on_mobile` should be editable. Forward-Port-Of: odoo/enterprise#52362 Forward-Port-Of: odoo/enterprise#52240
**Before the change:** The behavior before the change was that in the preparation display, the system considered the last stage as an indicator that the order is done. Orders in others stages were not differentiated and were included in the list displayed to customers as not ready. **After the change:** After the change, the system now correctly identifies the second to last stage as the indicator that the order is ready for display. Completed orders are now filtered out based on the last s
Original PR description
**Before the change:** The behavior before the change was that in the preparation display, the system considered the last stage as an indicator that the order is done. Orders in others stages were not differentiated and were included in the list displayed to customers as not ready. **After the change:** After the change, the system now correctly identifies the second to last stage as the indicator that the order is ready for display. Completed orders are now filtered out based on the last stage, ensuring that only relevant orders are shown to customers. This adjustment improves clarity and accuracy in the order tracking process for both customers and staff. Forward-Port-Of: odoo/enterprise#57106
The audit of cell made in this commit https://github.com/odoo/enterprise/commit/a0f96b8a7f74f618725f5e09d4ee5bb9fbcada6c can be improved to also include 'misc' entries. The previous solution did not work because MISC entries do not have the 'payment_state' field set. opw-3635049 Forward-Port-Of: odoo/enterprise#54314
Original PR description
The audit of cell made in this commit https://github.com/odoo/enterprise/commit/a0f96b8a7f74f618725f5e09d4ee5bb9fbcada6c can be improved to also include 'misc' entries. The previous solution did not work because MISC entries do not have the 'payment_state' field set. opw-3635049 Forward-Port-Of: odoo/enterprise#54314
Problem: When a user sets a custom filter on field 'followup_status' to "is set/is not set", a traceback error occurs with the message: "TypeError: 'bool' object is not iterable". Solution: To prevent the traceback error, the check for value should be done first. Steps to reproduce on Runbot: 1. Install Contacts and Accounting 2. Navigate to Contacts and add a custom filter for "Follow-up Status is set/not set" and traceback error occurs opw-3736643 Forward-Port-Of: odoo/enterprise#5
Original PR description
Problem: When a user sets a custom filter on field 'followup_status' to "is set/is not set", a traceback error occurs with the message: "TypeError: 'bool' object is not iterable". Solution: To prevent the traceback error, the check for value should be done first. Steps to reproduce on Runbot: 1. Install Contacts and Accounting 2. Navigate to Contacts and add a custom filter for "Follow-up Status is set/not set" and traceback error occurs opw-3736643 Forward-Port-Of: odoo/enterprise#57184 Forward-Port-Of: odoo/enterprise#57093
33 changes
New functionality added to Odoo
This update adds official Balance Sheet and Profit and Loss reports for Czech companies using Odoo. These reports comply with Czech accounting regulations (Decree No. 500/2002) and include additional account configurations needed for proper financial reporting in the Czech Republic.
Original PR description
This commit adds the Balance and the Profit and Loss report for CZ localization. Those reports follow the Decree No. 500/2002 Coll. It also adds some missing accounts. task-2348644
This update adds an intelligent auto-complete widget for HSN (Harmonized System of Nomenclature) codes in the India localization module. When users enter product information, the system now suggests matching HSN codes and automatically fills in the corresponding description, making data entry faster and more accurate for Indian businesses.
Original PR description
- In this PR, we make some requests in js to get a list of HSN codes to match with the input entered by the user in the field. - And for the options attribute in hsn_autocomplete widget, when a user selects an option from the list, the hsn_decription will be stored in the field specified by the user. task-3646598
Enhancements to existing features
This update ensures that when marketing activities are copied within a campaign, their associated emails are also duplicated. Previously, copying activities without their emails would cause the campaign to cancel those emails when run. Additionally, the default interval setting for new campaigns has been adjusted to zero for easier testing and execution.
Original PR description
When we copy activities, we should also copy their mailings, otherwise when we run campaign it cancels emails. task-3465452
The order tracking display system now correctly shows which orders are ready for pickup by identifying the second-to-last stage as "ready" instead of treating all non-final orders the same. This change ensures customers and staff see accurate, relevant order information, reducing confusion about order status.
Original PR description
**Before the change:** The behavior before the change was that in the preparation display, the system considered the last stage as an indicator that the order is done. Orders in others stages were not differentiated and were included in the list displayed to customers as not ready. **After the change:** After the change, the system now correctly identifies the second to last stage as the indicator that the order is ready for display. Completed orders are now filtered out based on the last stage, ensuring that only relevant orders are shown to customers. This adjustment improves clarity and accuracy in the order tracking process for both customers and staff.
Users can now edit expense line details again while viewing receipts, making it easier to make corrections without losing the receipt viewer. Critical fields like quantity and taxes remain protected to prevent accidental changes that could invalidate the expense report.
Original PR description
In #138387 we modified the expense lines tree in expense reports so that the user can click on the lines to see an attached receipt in the viewer at the side of the webpage. The tree was made to be readonly to make clicking the lines easier and to make it harder for the user to change a field by mistake. This commit reverts the lines to being editable again while leaving some fields as readonly like quantity and taxes as those can invalidate the expense. Task link: https://www.odoo.com/web#model=project.task&id=3685651 task-3685651
This update adds a new manifest key called 'maintenance_loc' that allows modules to store their actual lines of code count. This is particularly important for data modules where automatic code counting tools are inaccurate. By hardcoding this value in the module manifest, the system can now provide accurate code metrics for reporting and maintenance purposes.
Original PR description
For data modules, cloc is not accurate based on the path. It is therefore needed to compute it on a database where this module was imported. This new key allows us to save the value in the manifest so that the number of lines of code will be hardcoded into the modules. This is only used for industries for now.
This update reorganizes the menu options in the Point of Sale interface by moving 'Close session' and 'Backend' options to the bottom of the menu list. This improves the user experience by placing less frequently used administrative actions at the end, making the most common operations more accessible at the top of the menu.
Original PR description
-Move menu options to have 'Close session' and 'Backend' at the bottom of the list task id: 3759943 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
Malaysia's Service and Sales Tax (SST) rate is increasing from 6% to 8% effective March 1, 2024. This update deactivates the old 6% tax rate and introduces the new 8% rate to ensure accurate tax calculations for Malaysian businesses using Odoo.
Original PR description
As of the first of March 2024, the SST tax will increase from 6% to 8%. To that end, the current 6% tax will be set to inactive by default, and we will add a new 8% service tax to replace it. Task id # 3748127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154959 Forward-Port-Of: odoo/odoo#154534
Product documents are now sorted by name instead of ID, giving users better control over how documents appear on ecommerce pages and in quote builders. This allows businesses to organize and present product documentation in their preferred order without relying on system IDs.
Original PR description
Ordering documents attached to a produt by name, rather than ID. That allows a control on the order in the PDF quotation builder, and the eCommerce page. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix corrects a bug where the total quantity displayed in a subscription preview was showing an incorrect value. When upselling a subscription, the preview now accurately displays the combined quantity from the original subscription and the upsell amount, ensuring customers and sales teams see the correct totals before confirming orders.
Original PR description
Steps to reproduce: - Create a monthly subscription for a customer with a quantity of 1 - Make an invoice and confirm it - Upsell with 2 quantity - Click on preview in new SO - Total quantity is 5 Issue: Total quantity should be 3 opw-3698971
A test for tax report carryover was failing because it was finding more external values than expected. The fix makes the search more specific to only find the intended carryover value, preventing test errors. This ensures the tax reporting tests run reliably without false failures.
Original PR description
In the `l10n_lu_reports` `annual_tax_report` the label `_default_balance` creates an `account.report.external.value` by default. The tests for `tax_report_carry_over` search for all external values expecting to find just the carry-over one, but they find more - so they traceback with "Expected singleton". To fix this, we're changing the search domain to be more specific. Link: https://runbot.odoo.com/web/#id=56375&model=runbot.build.error Runbot error 56375
This fix prevents articles from being automatically saved every time a user's mouse leaves the page. Previously, embedded views like calendars were incorrectly saving loader and error messages along with the actual content, causing unnecessary saves and page reloads. Now only the actual content is saved, eliminating these redundant saves.
Original PR description
Issue: Embedded views within articles incorrectly include loader and error messages as part of the content upon saving, leading to irrelevant data being stored. Steps to Reproduce: 1. Install Knowledge and create a new Article. 2. Add a calendar at the top of the Article. 3. Add many lines and then a new calendar so that this one is not visible when we scroll to the top of the article. 4. Refresh the page. 5. Each time the mouse leaves the page is uselessly saved and the first calendar is reloaded Solution: Enhanced the `cleanForSave` method in `knowledge_plugin.js` to filter out non-content elements from embedded views. This is achieved by only retaining child elements with a `data-prop-name` attribute within `.o_knowledge_behavior_type_embedded_view` elements. As a result, loaders or error messages, which do not have this attribute, are excluded from the saved content, ensuring that only relevant, intended content is preserved. opw-3707380
This update resolves a display problem in Mexican invoices where the total amounts section was overlapping with the digital stamp. The fix repositions the digital stamp to appear after all invoice elements, ensuring a clean and professional invoice layout that complies with Mexican localization requirements.
Original PR description
**Issue:** The total amounts div overlaps the digital stamp from the Mexican localization **Solution:** Put the digital stamp at the final of every element of the invoice to avoid the overlapping **opw-3742996**
Fixed an issue in the timesheet grid module that was causing errors when users tried to view timesheets on fresh databases without demo data. The module was attempting to access sample data that didn't exist in the database, resulting in crashes. This fix ensures the timesheet grid works correctly regardless of whether demo data is present.
Original PR description
To reproduce: ============= - On a fresh database without demo data, install the timesheet_grid module - Create new user demo with following settings: - Project: User - Timesheet: User : all timesheets - Connect as demo and go to timesheet - Timesheets > All Timesheets - On list view Delete the Admin's "Internal" timesheets - Refresh > Timesheets > All Timesheets -> Receive error Problem: ======= The timesheet_grid module makes ORM calls with sample data, that don't exist in the database. Solution: ========= The timesheet_grid module should not make ORM calls with sample data. opw-3747297
This fix corrects the employer mandatory provident fund (MPF) contribution calculation for Hong Kong payroll. Previously, employer contributions were incorrectly excluded when the MPF gross amount was below $7,100. The fix ensures employer contributions are now properly included in all cases, as required by Hong Kong government regulations.
Original PR description
Steps to reproduce: - Create a payslip with mpf gross less than $7100 Current behaviour: - ERMC is missing because it not included when mpf gross is less than $7100 Expected behaviour: - ERMC should be included by the gov law Explanation: - By gov law, employer mpf contribution doesn't need to check with the mpf threshold amount $7100. Therefore remove the checking for ERMC. task-3643660 X-original-commit: 45321a2 Forward-Port-Of: odoo/enterprise#56997 Forward-Port-Of: odoo/enterprise#56897
This update resolves an error that occurred when users tried to filter contacts by Follow-up Status using "is set" or "is not set" options. The fix ensures the system properly handles these filter conditions, allowing users to create and apply custom filters without encountering errors.
Original PR description
Problem: When a user sets a custom filter on field 'followup_status' to "is set/is not set", a traceback error occurs with the message: "TypeError: 'bool' object is not iterable". Solution: To prevent the traceback error, the check for value should be done first. Steps to reproduce on Runbot: 1. Install Contacts and Accounting 2. Navigate to Contacts and add a custom filter for "Follow-up Status is set/not set" and traceback error occurs opw-3736643 Forward-Port-Of: odoo/enterprise#57184 Forward-Port-Of: odoo/enterprise#57093
This fix improves how the accounting system identifies which transactions impact cash basis reports. Previously, miscellaneous entries were not properly included in the audit because they lack a payment status field. The update adds a new tracking mechanism to ensure all relevant transactions are correctly captured in accounting reports.
Original PR description
The audit of cell made in this commit https://github.com/odoo/enterprise/commit/a0f96b8a7f74f618725f5e09d4ee5bb9fbcada6c can be improved to also include 'misc' entries. The previous solution did not work because MISC entries do not have the 'payment_state' field set. opw-3635049 Forward-Port-Of: odoo/enterprise#54314
This fix resolves an issue where reconciling transactions in multiple foreign currencies would fail to complete fully. The system now correctly handles write-offs by creating them in the residual currency instead of converting to the company currency, ensuring accurate reconciliation when dealing with custom exchange rates between different currencies.
Original PR description
Suppose the following reconciliation situation: Company's currency = EUR We want to reconcile 105 USD = 98 EUR with 105 CAD = 73 EUR Before this PR: When encountering two foreign currencies Odoo will try to reconcile in EUR (company's currency). After the first step of reconciliation there is a residual of 25 EUR = 27 USD left on the first line. We therefore try to create a write-off of 25 EUR and reconcile it with the residual, those 25 EUR are converted in USD at the Odoo rate => 24 USD. 27 USD != 24 USD, the reconciliation can't be full while it should have. Now we detect cases where there is only one residual left in multicurrency and create the write-off in that currency. opw-3497793 Forward-Port-Of: odoo/enterprise#56857 Forward-Port-Of: odoo/enterprise#54069
This fix resolves an issue where users couldn't properly edit intrastat-related fields directly on product templates. Previously, these fields were converted to computed fields but lacked the necessary logic to handle updates made at the template level. Now users can modify intrastat information on product templates, and the changes will correctly sync to the underlying product variants.
Original PR description
The aim of this commit is handling properly intrastat fields in product template. In this commit (https://github.com/odoo/enterprise/commit/175615a7d715d790e9ba5b0addbde1b964164d5d), we change related fields to computed ones but we forgot to add inverse function to handle the case where users want to modify their `product.template` instead of their `product.product`. opw-3755024 opw-3755048 opw-3755048 Forward-Port-Of: odoo/enterprise#57131
This fix ensures that product warning and blocking messages are now properly displayed when adding products through the catalog in sales quotations. Products with blocking messages are marked as read-only to prevent accidental addition, matching the original safety behavior. The same warning functionality has been extended to purchase orders.
Original PR description
Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message. Steps to reproduce: ------------------- *…
Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message.
Steps to reproduce:
-------------------
* Go to **Sales** app -> Configuration -> Settings
* Enable **Sale Warnings**
* Go to **Products** -> Products
* Create a new product
* Under **Sales** tab:
* For warning, select either warning or blocking message
* Write a message
* Go to **Orders** -> Quotations
* Create a new quotation
* Select the **Catalog** to add products
* Add the newly created product
Why the fix:
------------
The first version of this fix was a python exclusive change. It was a bit hacky; it was raising an error when the product had a blocking warning and sending a message on the bus when the product had a non-blocking warning.
The second version was changing the return value of `_update_order_line_info` to return the price and the warning if any. The warning was shown inside JS with `_updateQuantity`. This change was not good for a stable verion as it was changing the signature of a public method.
This fix automatically changes the data that is loaded to the catalog. It adds the warning message if any and changes the `readOnly` field accordingly.
Warning/blocking messages will be automatically displayed in the catalog, on the product informations. Products with blocking messages will me marked as readonly to avoid being able to add the product to the sale order (this is the original behavior for blocking messages).
Regarding the field `readOnly` and ẁarning`:
* We can't write `res[product.id]['readOnly'] = product.sale_line_warn == "block"' because readOnly is set to True by default if the sale order is cancelled and doing this would overide that value later. See:
https://github.com/odoo/odoo/blob/21c25a7ccd0ba2d6574ddbcfbcf50dbbc03a1e6c/addons/product/models/product_catalog_mixin.py#L97-L99
* We're also sending the warning only if there is one because of this:
```python
<span t-elif="props.readOnly" class="my-2 pt-3 border-top" t-out="props.warning">
You can't edit this product in the catalog.
</span>
```
Because in the case where readOnly is True for another reason than the product having a blocking warning, the initial message will be displyed.
Since the module purchase also uses the warning on products, this fix is extended to include it.
opw-3631511This update improves the performance of channel membership searches in Odoo's messaging system. The fix optimizes how the system queries which channels a user belongs to by using a more efficient database approach, reducing unnecessary processing and making the feature faster for users with many channels.
Original PR description
Part 1: _search_is_member ------------------------- Separate query to fetch candidate channels because the sub-select that `_search` would generate leads psql query plan to take bad decisions. When…
Part 1: _search_is_member ------------------------- Separate query to fetch candidate channels because the sub-select that `_search` would generate leads psql query plan to take bad decisions. When candidate ids are explicitly given it doesn't need to make (incorrect) guess, at the cost of one extra but fast query. It is expected to return hundreds of channels, a thousand at most, which is acceptable. A "join" would be ideal, but the ORM is currently not able to generate it from the domain. `sudo` is added as well because the rules for the member don't need to be checked as no information is leaked. Part 2: clean rules ------------------- The rule for reading "self" is included in the rule for reading other members. It can be disabled for "read" to avoid duplicate. It also checked is_member again, but is_self necessarily implies it. Part 3: clean tests ------------------- The opportunity is taken to fix the tests. The tests where considering as "access error" when there was an assert error inside the test (for example not finding the channel or the member), but those needed to be considered as failure regardless of expected outcome of access check. Extra mute loggers are added to clean the test output.
Articles were being incorrectly marked as changed and auto-saved even when no actual content changes were made. This fix removes technical metadata (history IDs) from the comparison process, so the system only detects real content changes. This reduces unnecessary saving and improves performance.
Original PR description
Issue: Articles were erroneously marked as changed, leading to unnecessary autosaves. Part of this was caused by the inclusion of history IDs in the content comparison process, which differ even without substantive content changes. Solution: Applied `stripHistoryIds` to the content obtained from the WYSIWYG editor before performing the dirty check. This ensures that comparisons focus solely on actual content changes, eliminating history IDs as a factor in the dirty state determination. opw-3707380
Basic users without accounting access can now create and submit their own expense reports without encountering permission errors. The fix removes a problematic field reference that was preventing users from completing the expense report workflow after a recent system update.
Original PR description
Have a base user with no access to Accounting, Expenses, Employee Create an expense, input an amount Save and Create Report Access Error will raise You are not allowed to access 'Journal Entry' (account.move) records. This occurs because of a remaining field in the hr.expense.sheet form view after refactoring the model opw-3690493 Forward-Port-Of: odoo/odoo#152288
This fix restores the ability for non-member users (like visitors) to receive live chat messages. Previously, when a visitor opened a live chat, they weren't being subscribed to channel events, preventing them from receiving messages. This fix ensures visitors and other non-members now properly receive all messages in the chat channels they participate in.
Original PR description
Since [1], accessing a live chat as a non member does not subscribe the user to the channel events. This results in the user not receiving any messages linked to this channel. This PR restores the previous behavior as removing it was not intentional. [1]: https://github.com/odoo/odoo/pull/154292 Steps to reproduce the issue: - Open a live chat with demo as a visitor - Connect as admin and go to live chat history - Open the chat with demo and the visitor - The thread is displayed in discuss - Send another message as the visitor - Admin does not receive the message
This fix resolves an issue where validating multiple pickings at once would incorrectly process empty pickings, preventing further inventory reservations. Now when bulk validating pickings, empty ones are properly skipped and left untouched, while valid pickings are processed as expected.
Original PR description
Usecase to reproduce: - Create a picking with available quantity and another without - Confirm both picking - In list view, select the two picking and use the validate action Expected behavior: The first picking is validated and the second has been untouched Current behavior: The second picking is picked. That will prevent any further reservation It happens because on multiple records the error message for empty picking is bypassed and the picked is applied on it. Close #153983 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an error that occurred when creating multiple accrual levels in the HR holidays module. The issue was caused by a field being incorrectly marked as read-only, which prevented the system from properly saving accrual level data. By adjusting the field settings, users can now successfully create and save multiple accrual levels without encountering validation errors.
Original PR description
Steps to reproduce: ------------------- - create an accrual plan; - create an accrual level; - save; - create a second accrual level; - save the form; Issue: ------ We trigger an error with an…
Steps to reproduce: ------------------- - create an accrual plan; - create an accrual level; - save; - create a second accrual level; - save the form; Issue: ------ We trigger an error with an invalid `added_value_type` field. Cause: ------ The `added_value_type` is a compute stored field without inverse. As it is not inversible, this field will be readonly by default [^1]. When the dialog window is opened, we trigger a specific logic which will trigger an onchange [^2]. During this onchange, we work with a virtual record from the `hr.leave.accrual.level` model (the one corresponding to the first level) which has an origin. Unfortunately, we are using the cached value for the virtual record, i.e. `None`. The latter will have been set as if it is a record without origin. As the `added_value_type` field is readonly on the dialog form view, we have to save the record with this value. Since this field is required, the error occurs. Solution: --------- In order to use the value on the original record, the field must be forced with `readonly=False`. Note: ----- Commit which introduced the issue: 0a9e83dfd81300fd1204693cf6d4dca2bab40b2c The fix allows you not to use `_origin` (which normally shouldn't be used in this case). [^1]: https://github.com/odoo/odoo/blob/e89ed59269974f148c2285446dcd60e871df1a01/odoo/fields.py#L451 [^2]: https://github.com/odoo/odoo/blob/25cda065dccaae5edd861114c29157c7abb68533/addons/web/static/src/model/relational_model/static_list.js#L194-L299 opw-3745463
This fix resolves validation errors when exporting invoices with tax-exempt items in the BIS3 format. Previously, the system would either show warnings or fatal errors depending on how tax exemption information was structured in the XML. The fix ensures tax exemption details are placed in the correct location within the invoice document, allowing compliant exports without validation issues.
Original PR description
Previously, exporting BIS3 when there is a 0% tax in the invoice will results in the XML showing warning of UBL-CR-601. But if we do not include any TaxExemptionReason reason at all, a fatal error…
Previously, exporting BIS3 when there is a 0% tax in the invoice will results in the XML showing warning of UBL-CR-601. But if we do not include any TaxExemptionReason reason at all, a fatal error BR-E-10 will pop up.
Here is the details of those 2 rules:
```xml
(with context: /*/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory
[normalize-space(cbc:ID) = 'E'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT'])
<assert id="BR-E-10" flag="fatal" test="exists(cbc:TaxExemptionReason) or
exists(cbc:TaxExemptionReasonCode)">
[BR-E-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118)
"Exempt from VAT" shall have a VAT exemption reason code (BT-121)
or a VAT exemption reason text (BT-120). </assert>
and
(no context)
<assert id="UBL-CR-601" flag="warning" test="
not((cac:InvoiceLine|cac:CreditNoteLine)/cac:Item/
cac:ClassifiedTaxCategory/cbc:TaxExemptionReason)">
[UBL-CR-601]-A UBL invoice should not include the InvoiceLine
Item ClassifiedTaxCategory TaxExemptionReason </assert>
```
Based on these rules, we can conclude that:
- TaxExemptionReason must not appear in InvoiceLine/Item/ClassifiedTaxCategory
- TaxExemptionReason must appear (when some line in invoice has exempt tax) in TaxTotal/TaxSubtotal/TaxCategory
Previously, the TaxExemptionReason will appear on both places. This commit fixes that and adds a test to ensure that when a 0% tax is present, TaxExemptionReason only appear in TaxTotal/TaxSubtotal/TaxCategory
task-id: 3703206
Forward-Port-Of: odoo/odoo#154865
Forward-Port-Of: odoo/odoo#154055This update fixes an issue where pressing arrow keys or escape while editing mega menus and nested menus would cause error dialogs to appear. The fix prevents Bootstrap's dropdown handler from interfering with menu editing by temporarily applying a special class that excludes the dropdown from triggering errors during keyboard navigation.
Original PR description
Since [1] when the mega menu were first introduced, to make their edition possible, the bootstrap dropdown behavior was neutralized by removing the `data-[bs-]toggle` attribute. In [2] when Bootstrap…
Since [1] when the mega menu were first introduced, to make their edition possible, the bootstrap dropdown behavior was neutralized by removing the `data-[bs-]toggle` attribute. In [2] when Bootstrap was upgraded to version 5.1.3, the `dataApiKeydownHandler` event handler that is called when up, down or escape are pressed raises an error if `data-bs-toggle` cannot be found on a previous sibling of the dropdown. This makes the approach chosen in [1] incomplete. This commit avoids this issue by temporarily adding a class that is excluded from the event handler selector. The patch must unfortunately be applied within bootstrap itself because the event handler is registered right after the method is defined and we have no way to access the registered event handlers afterwards. This makes it impossible to patch the called method from outside, nor its associated selector. We cannot simply update the selector that was already patched by [3] because it is also used by other methods. A test is included which should mitigate the risk of accidentally losing this patch upon bootstrap upgrades. Steps to reproduce: - Create a mega menu. - Edit the page. - Open the mega menu. - Click inside the mega menu content to have a cursor selection. - Press the arrow up key, the arrow down key or the escape key. => An error dialog was displayed. The same issue happened with a nested menu instead of a mega menu. [1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7 [2]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968 [3]: https://github.com/odoo/odoo/commit/daca8fe4e3da4a5ad5fabf3730496a3919af8abc task-3614926 opw-3741670 Forward-Port-Of: odoo/odoo#154864 Forward-Port-Of: odoo/odoo#154409
This fix restores missing images in the website module that disappeared after upgrading from version 16.0 to 17.0. When users upgraded their systems, certain images used in website snippets (like blockquotes) were no longer displaying because the image definitions weren't being properly updated during the upgrade process. This fix ensures those images are restored so websites continue to display correctly after upgrading.
Original PR description
Commit [1] introduced default images changes for the website library. The problem is that the ir.attachment definitions are in a non-updatable environment by mistake (apparently since forever)... so…
Commit [1] introduced default images changes for the website library. The problem is that the ir.attachment definitions are in a non-updatable environment by mistake (apparently since forever)... so they are not updated after update/upgrade. This commit moves the definitions to its own updatable file, in 17.0 and above only (ignoring potential other changes that were made in 15.0/16.0 at the time but apparently led to no issue). But this is not enough: upgraded users will still have those ir.attachment records marked as non updatable and will thus not be updated. Meaning that the ir.attachment record will still reference path to images that do not exist anymore (since [1]) and thus not display anything in related snippets, or worse: crash on some non-robust-to-404-images options (This will be made more robust in another update). Note that, at the moment, we cannot solve this issue by making the /web/image route not return a 404 but a placeholder image in that case, for technical reasons (even though it would be consistent as this is what is done if you try to reach `/web/image/something_with_a_typo`). It would also be annoying to solve this problem by adding a migration script inside the Odoo repo itself: - It would only work if upgraded users do a -u again (unlikely). - That would mean an upgrade script rotting in the main repo forever. Instead, this commit chose to restore the removed images so that upgraded users will be able to use the outdated paths. In master, an upgrade script will be made (in the upgrade repo) to properly update all those attachment records and be able to finally remove those outdated images. Note that this may also be fixed without upgrade script if non-updatable records whose XML declaration is moved out a non-updatable area become updatable (under discussion with the framework team... we will see when this lands in master). Steps to reproduce: - Install a 16.0 with the website module - Upgrade to 17.0 - Drag a "Blockquote" snippet on a page => Crash and the image is missing (in the DOM but invisible and impossible to edit). Note that the crash itself will also be fixed by the later update that will be done to make editor options more robust to 404 images. [1]: https://github.com/odoo/odoo/commit/a4377bfa85b19be29a430573e0f42fff4da52757 opw-3693055 opw-3723895 opw-3744257 opw-3747348 opw-3749764 ...
Fixed a bug where dropdown menus (like font size and color options) in the Studio editor would remain open after selecting text in different locations. The issue occurred because clicks within the editor iframe weren't properly closing previously opened dropdowns. This fix ensures dropdowns close correctly when the toolbar is hidden, improving the user experience when editing reports and other content in Studio.
Original PR description
Steps to reproduce: =================== - Open any app (sales for example) - Toggle studio - select reports tab - Select any report - Select some text and open any dropdown (font size or color) - Click somewhere else on the document - Select some text again - The dropdown stayed open from the first select Origin of the issue: ==================== Clicking somewhere on the document in studio doesn't trigger the events `defined in bootstrap/js/dist/dropdown.js` because of the iframe. Solution: ========= Trigger click event on toggle button for the opened dropdown when hiding the toolbar to close them task-3674736 Forward-Port-Of: odoo/odoo#152681
This fix restores the display of legal notes from fiscal positions on invoices when the Italian localization module is installed. Previously, an overly restrictive condition was preventing these important notes from appearing on invoices for Italian companies. The fix removes this unnecessary restriction, ensuring fiscal position notes display correctly regardless of company location.
Original PR description
Steps to reproduce: - Install Accounting - Create a fiscal position with a legal note - Create an invoice with the created fiscal position - Preview the invoice => The legal note from the fiscal position appears on the invoice as expected - Install l10n_it - Preview the invoice => The legal note from the fiscal position doesn't appear anymore Cause: The condition to display the legal note from the fiscal position is overridden by l10n_it module to only display it for Italian companies, which is not correct. Solution: Remove the condition about the Italian companies. By removing that condition, the inherited view becomes useless as the overridden condition is the same as the original one. The inherited view will have to be removed in master. opw-3709443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153638
Code cleanup and technical improvements
The barcode scanning test methods in the Point of Sale module have been reorganized to use a more standardized barcode function. This refactoring improves the consistency and maintainability of the test code, making it easier for the development team to manage and update barcode-related tests in the future.
Original PR description
refactor 'scan_barcode' method to use barcodes function task id: 3674936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The 'Include Archived' toggle has been removed from the document filtering interface since documents can no longer be archived. This cleanup removes a confusing option that was no longer functional, making the filter interface cleaner and less misleading for users working with documents.
Original PR description
Since we can no longer archive documents, the 'Include Archived' toggle checkbox of the domain selector is now irrelevant and hence this PR removes it. Technical: The archive feature for documents has been removed with #37389. However, the active field is still being utilized for the 'trash' feature and hence cannot be removed. Whether the 'Include Archived' toggle should be displayed or not, is determined by checking if a particular model has 'active' in its fieldDefs (i.e. if the model has archive/unarchive feature). As a result, the condition becomes true in case of 'documents' model despite archive records feature not being available anymore. Thus, this PR adds a condition to check resModel and hides the toggle checkbox from domain selector in case of 'documents' model. Task: [3695462](https://www.odoo.com/web#id=3695462&menu_id=4722&cids=2&action=333&active_id=965&model=project.task&view_type=form)