Thursday, February 8, 2024
33 changes · 17.0
Enhancements to existing features
German language translations have been added to the Dutch localization module for financial reports, specifically for Balance Sheet and Profit & Loss statements. This enables users in German-speaking regions to access these critical financial documents in their preferred language.
Original PR description
It appears that some user need to have the german translation on the dutch localisation. This commit will translate the following files: - Balance sheet - Profit and loss task: 3682464
The system now displays all problematic bank accounts at once when processing Australian batch payments, instead of showing errors one at a time. This makes it faster and easier for users to identify and fix missing or incorrect bank account information for multiple employees or vendors in a single operation.
Original PR description
Issue: Aba is meant for batch payments and raising `UserErrors` individually for each employee/vendor prevents User from knowing all the faulty accounts. At the same time, difficult to find bank accounts for partners with multiple accounts. Fix: Raise a `RedirectWarning` with tree view to show all faulty partners/vendors simultaneously. And makes it simpler to directly find the account without the need to discard/recreate the faulty payments. 3635231
This update extends the US payroll localization demo data setup to include the base company (San Francisco) in addition to the demo US company. Previously, accounting chart configurations were only applied to the demo company, but now both companies receive the proper demo data initialization for consistent payroll processing.
Original PR description
Before this commit, the US localisation was adding charts of account to rules only for the demo US company. However, the base company is based in San Francisco and should also have its demo data updated. task-3713709
This update improves how the system handles sending signature request emails during automated scheduled tasks. Previously, if the system encountered concurrent updates (like email bounces), the scheduled task would fail and repeatedly resend emails. The fix ensures the system completes its database updates before sending emails, preventing duplicate messages from being sent to users.
Original PR description
Be sure that cron is committed before to send email. In case of concurrent update with e.g. bounce, the cron will fail and so the email send again and again...
This update adds German language support to the Dutch localization module, translating key accounting features including chart of accounts, taxes, fiscal positions, tax groups, and tax reports. This enables German-speaking users in the Netherlands to use these accounting features in their preferred language.
Original PR description
It appears that some user need to have the german translation on the dutch localisation. This commit will translate the following files: - COA - Taxes - Fiscal position - Tax group - Tax report task: 3682464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds comprehensive test coverage for the HR holidays module to ensure that public holidays are correctly handled across multiple companies. The test validates that when calculating employee leave intervals, the system properly matches public holidays with the correct company, preventing cross-company data conflicts and ensuring accurate leave calculations for all employees.
Original PR description
Adds a test following a fix done in https://github.com/odoo/odoo/pull/143381 That fix ensured that the public leave used to compute leaves intervals for the resources are in the same company as the resource. task-3668605
Resolved issues and error corrections
Fixed a bug that prevented users from making calls through the phone field in various Odoo applications like Helpdesk and Recruitment. The system was looking for phone numbers under specific field names and would fail when applications used different naming conventions. This update allows the call feature to work correctly regardless of how each application names its phone number field.
Original PR description
Step to reproduce: 1) Install whichever app includes a phone number(Helpdesk, Recruitment, etc.) 2) Click on the 'Call' icon beside the phone field 3) It will throw a validation error Cause: There is a different name for phone/mobile number field in each application In the code, we are only going for 'mobile' and 'phone' field name which throws error Solution: Setting the current field name will solve the issue Task-3635976
This update improves the Spanish translations used in Ecuador's RIDE (electronic tax report) and adjusts the position of the date field for better usability. These changes ensure that Ecuadorian users see accurate and properly positioned information when generating their required tax reports.
Original PR description
Extra Translations for ecuadorian ride and change position of date field in v17.0
The activity inspector was incorrectly showing 0 documents and 0 MB for all activities. This fix corrects the display to accurately show the actual number of documents and their total file size. Users will now see the correct document information when reviewing activity details.
Original PR description
Fix the activity view inspector which was always displaying 0 Documents and 0 MB. The number of documents and the file size is now correctly updated. Getting the file size with the DocumentsModelMixin mixin. Task-3700259
This fix resolves an access permission error that occurred when non-admin users tried to link documents to records (such as vehicles in the Fleet app). The issue happened because the system was trying to access model information without proper permissions. The solution adjusts how the system retrieves this information, avoiding the need to grant additional access rights to users.
Original PR description
Steps to reproduce: ------------------- - install documents and fleet apps; - be a user who is not in the `base.user_admin` group; - have admin rights to fleet and document; - put a document in the "Fleet" workspace; - click on "Link to a vehicle" button; Issue: ------ - First issue: An access error is triggered when we want to get the `model` field for an `ir.model` record. - Second issue: When a `Reference` field has the `model_field` option, a read on `ir.model` is triggered and as we don't have the rights, this causes an access error. Solution: --------- Work on the `ir.model` record in sudo. Do not use the `model_field` option and use a default value for the `Reference` field which expects a string like `"model,id"`. Note: ----- This solution avoids adding a new access right for `ir.model` as follows: ```csv access_ir_model,access_ir_model,base.model_ir_model,documents.group_documents_user,1,0,0,0 ``` opw-3502558 Forward-Port-Of: odoo/enterprise#50784
The activity inspector in the Documents module was incorrectly showing 0 documents and 0 MB for file sizes. This fix corrects the display to accurately show the actual number of documents and their total file size using improved data retrieval methods.
Original PR description
Fix the activity view inspector which was always displaying 0 Documents and 0 MB. The number of documents and the file size is now correctly updated. Getting the file size with the DocumentsDataPointMixin mixin. Task-3700259 Forward-Port-Of: odoo/enterprise#56093 Forward-Port-Of: odoo/enterprise#55011
Fixed an issue where journal entries were missing when exporting the General Ledger report to Excel after unfolding accounts with the "Hierarchy and Subtotals" option enabled. The system now correctly identifies and includes all unfolded journal entries in the exported file, ensuring complete financial reporting data.
Original PR description
Summary: When we unfold an account and show journal entries in the general ledger (with the "Hierarchy and Subtotals" option checked), the journal entries do not appear on the XLSX report. Steps to…
Summary: When we unfold an account and show journal entries in the general ledger (with the "Hierarchy and Subtotals" option checked), the journal entries do not appear on the XLSX report. Steps to reproduce: 1. Enable debug mode 2. Create a new account group (Accounting > Configuration > Accounting > Account Groups) with a code prefix from 1 to 9 3. Open the general ledger (Accounting > Reporting > Audit Reports > General Ledger) and check the option "Hierarchy and Subtotals" 4. Unfold a line until you can see journal entries (e.g., "101000 Current Assets" on runbot) 5. Export the general ledger in XLSX, and open it: the journal entries do not appear Cause: In the local stack, there is a field "unfolded_lines" that is a list containing the unfolded lines in absolute format (e.g., if account A is in account group G, the line is noted as "G|A"). However, when checking if an account is unfolded, it checks if the name of the account is in this field (just the name and not the group/account), which is not the case if the account is in an account group. In this case, the children are not displayed because only the content of the unfolded lines is shown. Fix: Modify the check for whether an account is unfolded: check if the name in absolute format is in the unfolded_lines list. opw-3649550 Forward-Port-Of: odoo/enterprise#55753 Forward-Port-Of: odoo/enterprise#54385
This update removes the default Indian public holidays that were previously added to the payroll system. Due to issues that arose with the implementation, the team decided to revert this feature and allow organizations to manually configure their own public holidays instead.
Original PR description
We revert the below commit in this commit due to some issues that arose, so we decided to remove the default Indian public holiday. commit-https://github.com/odoo/enterprise/commit/403c8faf24afe79a533bab19d6c994ed5b5edc3a task-3693329
This update fixes an issue where the spreadsheet dashboard feature would not properly handle cases when a dashboard is missing or unavailable. The fix ensures the system gracefully manages these situations, preventing errors and improving the overall reliability of the dashboard functionality.
Original PR description
Task: 3581647 Forward-Port-Of: odoo/enterprise#55828 Forward-Port-Of: odoo/enterprise#54628
This fix corrects an issue where document type assignments for Peruvian electronic invoicing were incorrectly affecting non-Peruvian countries. The change ensures that Peruvian-specific document handling only applies to Peruvian operations, preventing unintended side effects on other country configurations.
Original PR description
Avoid affect document type assignation for no Peruvian countries
This update corrects how subscription status is validated when saving sales orders. Previously, the system was incorrectly preventing subscription features from being available during the draft stage of quotations. The fix ensures subscription functionality works properly while maintaining the intended behavior for service products, with validation now occurring when orders are confirmed rather than during initial creation.
Original PR description
Original commit prevented `subscription_state` from being true if the SO wasn't a subscription. This fixed an issue with creating tasks/projects for service products. As of 4ac62c700826ce1b38307641f91b7c9ce4f91d54, keeping `subscription_state` as long as the quotation in draft status is intended behavior for saas-16.4+. Instead the issue gets resolved on in `action_confirm`. This commit was amended to only add tests to verify this behavior. opw-3709457 Forward-Port-Of: odoo/enterprise#55788 Forward-Port-Of: odoo/enterprise#55741
This update resolves a display problem in the HR Contract module where the contract quick-access button (smart button) was not functioning correctly when showing multiple contracts. The fix ensures that users can properly view and access contract information regardless of how many contracts are associated with an employee.
Original PR description
Fix the issue when the number of contract displayed on the contract smart button is greater than 1. Forward-Port-Of: odoo/enterprise#56036
Fixed an issue where switching between different email templates in the mass mailing editor would incorrectly apply the wrong theme design. When users switched from a themed email template to a basic plain text template, the editor would incorrectly display the previous template's design instead. This fix ensures each template displays with its correct design when navigating between them.
Original PR description
Steps: - Create a draft mailing based on a theme that has the snippets menu (the "Event Promo" theme, for instance). - Create another draft mailing, this time based on the basic theme ("Plain Text").…
Steps:
- Create a draft mailing based on a theme that has the snippets menu
(the "Event Promo" theme, for instance).
- Create another draft mailing, this time based on the basic theme
("Plain Text").
- Switch from the former to the latter using the form view pager.
The editor for the basic theme record is not supposed to have a sidebar
(snippets menu), as it uses the floating toolbar instead. But when
switching between records like described above, the basic theme gets
replaced by the theme of the preceding record, and the snippets menu is
added to the UI.
This happens because [1] patched the `setValue` function to handle the
case where the element for dropping snippets (.o_mail_wrapper_td) is
missing, in particular if it gets removed via the codeview. Such fix
most likely had in mind the scenario where the codeview is toggled on
and off, but not the call to `setValue` that also happens when switching
between records via the form view pager. As a result, the html content
of a record based on the basic theme, in which such "dropzone" is
absent, is added as a child of the previous record's .o_mail_wrapper_td
element. This is certainly not the desired behavior, as it ends up
overwriting the basic theme by the one from the previous record (the
theme is defined by a class in the .o_layout div, which is a parent of
the .o_mail_wrapper_td element).
This commit, besides fixing the described issue, takes the opportunity
to add a comment with the presumed reasoning behind commit [1] and
extends the test tour in order to prevent regressions.
[1]: https://github.com/odoo/odoo/commit/9be2cb538f937645be4650af1031c8a1445bb48b
task-3573951
Forward-Port-Of: odoo/odoo#148718
Forward-Port-Of: odoo/odoo#140197Fixed an issue where recurring event details (recurrence type and day names) were not being translated to the user's selected language when sending calendar invitations and updates. Now when users create recurring events and send emails, the recurrence information displays in their chosen language instead of defaulting to English.
Original PR description
### Steps to reproduce: 1. install the calendar module 2. in General settings, add the French -or any- language 3. create a new event 4. under **Options** tab choose the recurrence type to be weekly…
### Steps to reproduce:
1. install the calendar module
2. in General settings, add the French -or any- language
3. create a new event
4. under **Options** tab choose the recurrence type to be weekly
5. select the days to repeat the event on
6. save the event
7. send an email using the **EMAIL** button, you can notice that works like (Weeks) and the days’ names are not translated but still in English
### Investigation
- the translation is applied on the model level, not on the code level. So we have to explicitly/programmatically translate the options.
### Discussion
- In the proposed fix, we compute the recurrence rule `name` by translating it to the current language -the event creator's language- but as this field is **stored**, it resulted in another issue that the invitation emails sent to the participants had a mix of languages: the email template being translated in each participant's language while the recurrence rule itself is translated in the owner's language being a **stored** field
- That's why the fix got extended to embed translating of the recurrence rule directly into the template.
- However there's a **_limitation_** we couldn't deal with that's there are two types of emails we are concerned with:
- invitation emails that follows `calendar attendee` model which works correctly as discussed
- update emails that follows `calendar event` model coming from the composer which deosn't allow to properly use partners/participants languages
### Resolution
- The update emails are sent in the owner's language, with the intention to enhance the behavior in master (Task-3677327)
opw-3483319
Forward-Port-Of: odoo/odoo#150644
Forward-Port-Of: odoo/odoo#141951This fix resolves a bug in CRM where users couldn't send emails directly from the activity preview window. When returning from the preview to the main email interface, the system wasn't properly reconnecting the email thread, causing errors. The fix ensures the email thread is correctly restored so users can send emails without encountering errors.
Original PR description
### [FIX] mail: Fix thread object transfer to chatter in CRM email preview This commit addresses a problem in CRM where it was not possible to send emails directly from the preview window. The issue arose when returning to the chatter interface from the preview window, as the thread object was not properly passed back (to the chatter). This fix ensures the thread object is reintegrated into the chatter interface, resolving the email sending issue. Issue was traced back to the commit [FIX] mail: do not reload chatter when not needed https://github.com/odoo/odoo/commit/5d99de10ec09244e10e4130573ad2e0c38e8600 ### [reproduce] - install crm - create activityTypes AT with an email template specified( crm/configuration/activityTypes) - open a Lead, ( crm/sales/MyPiepline) - schedule activity with activity type AT - click "preview" on the activity - click "send" or just close the preview -> BUG traceback opw-3680600
This update fixes an issue where invoices sent via Peppol Bis 3 would fail validation when the supplier doesn't have a VAT number. The system now uses the Peppol endpoint identifier as a fallback to meet regulatory requirements for supplier identification. This ensures invoices can be successfully transmitted to buyers even when VAT information is unavailable.
Original PR description
When using Peppol Bis 3 with a partner without VAT, use the `peppol_endpoint` to fill the `PartyTaxScheme/CompanyID` and `PartyLegalEntity/CompanyID` to avoid errors like: "[BR-E-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Standard rated" shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63)." "[BR-CO-26]-In order for the buyer to automatically identify a supplier, the Seller identifier (BT-29), the Seller legal registration identifier (BT-30) and/or the Seller VAT identifier (BT-31) shall be present." Also adapt the tests, as the rules for the supplier's identifier are stricter than for customers. Forward-Port-Of: odoo/odoo#152898 Forward-Port-Of: odoo/odoo#152663
This fix resolves a bug where product quantities were incorrectly increased by 1 when users clicked the edit option in the product dropdown menu. The issue occurred because click events were being triggered globally on the product card. Now, the system properly detects when clicks happen within the dropdown menu and prevents the quantity update in those cases.
Original PR description
**Steps to reproduce:** 1- Install Field Service module 2- Create new task and click on products smart button 3- Hover over a product and click on the dropdown menu 4- Click on edit in the dropdown menu 5- Get back to the products page and check the quantity for the product you edited **Current behavior before PR:** When the user clicks on edit in the dropdown menu of any product the quantity gets increased by 1. This is happening because of the global click event so when the user clicks anywhere inside the kanban box the quantity gets updated. **Desired behavior after PR is merged:** This behavior has been adjusted by checking the target where the user click if it is inside the dropdown menu it will not update the product's quantity. opw-3689864 Check https://github.com/odoo/enterprise/pull/54645
This fix resolves an issue where vendor information would disappear from the product variant view when adding multiple suppliers. Previously, the system was incorrectly clearing vendor data when processing empty product variant fields. The fix ensures vendor information is only updated when a valid product variant is actually selected, preventing accidental data loss.
Original PR description
Versions -------- - 15.0+ Steps ----- 1. Go to product variants; 2. select a product; 3. add a new Vendor line in the Purchase tab; 4. save; 5. add another Vendor line; 6. save. Issue ----- Previous…
Versions
--------
- 15.0+
Steps
-----
1. Go to product variants;
2. select a product;
3. add a new Vendor line in the Purchase tab;
4. save;
5. add another Vendor line;
6. save.
Issue
-----
Previous line disappears from view.
Cause
-----
In 93bc96047ff684cb66b69186822493815cf37982 I added logic which sets the `product_tmpl_id` in `product.supplierinfo` if a `product_id` gets written without accompanying `product_tmpl_id`. Adding lines from the Product Variant views add `{'product_id': False}` to the values for every vendor in the list without a Product Variant, so their `product_tmpl_id` gets overwritten with the `product_tmpl_id` of an empty product.
Solution
--------
Only overwrite `product_tmpl_id` iff `product_id` gets written to a non-falsy value by changing `if 'product_id' in vals` to `if vals.get('product_id')`.
Related
-------
https://github.com/odoo/odoo/pull/149618
opw-3664524
Forward-Port-Of: odoo/odoo#153115
Forward-Port-Of: odoo/odoo#152881The web interface was crashing when trying to search for a large number of elements on a page due to technical limitations in how the search function was implemented. This fix updates the search method to use a more efficient approach that prevents these crashes and improves overall performance.
Original PR description
__Current behavior before commit:__
The `find` jQuery method calls at some point `apply` on the results. Sometimes however the number of results can exceed the maximum number of arguments given to a function.
In such case `RangeError: Maximum call stack size exceeded` is thrown.
__Description of the fix:__
Instead of selecting all children with `find('*')` and filter them afterwards with the selector, we can simply use `querySelectorAll`. This will lead to the same result.
In order to respect the specification that `$from` can contain multiple elements we need to execute `querySelectorAll` on each of them. In practice however `cssFind` is always used on a single element therefore it basically serves the same purpose as `querySelectorAll`. Thus, it is marked as deprecated and should be removed in master.
opw-3703963
Forward-Port-Of: odoo/odoo#152729Fixed a bug where archived taxes were still being suggested when creating new purchase orders. The system now correctly filters out archived taxes, matching the behavior already in place for sales orders. This ensures users only see active, applicable taxes when building purchase orders.
Original PR description
Steps to reproduce: - Create a new purchase tax and archive it - Create a new PO Bug: the archived tax is still sugested on the PO Line Fix: apply same logic as for sales opw-3701429 Forward-Port-Of: odoo/odoo#152076