Thursday, February 22, 2024
26 changes · 17.0
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
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
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
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
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 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
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