Daily updates from Odoo
Wednesday, January 24, 2024
57 changes
2 changes
Resolved issues and error corrections
Project update panels now show stat button counts that match the companies selected by the user. This makes multi-company reporting clearer and prevents users from seeing outdated or misleading project figures when switching company context.
Original PR description
Before this commit, the stat buttons count values in the project updates right-side panel were not updated when the user was changing companies in the company selector. After this commit, the counts displayed in the stat buttons are updated based on the selected companies. task-3689065 related-https://github.com/odoo/odoo/pull/150676
Users can now remove an approver from an approval request and immediately select the same person again without refreshing the page. This prevents confusion and keeps approval setup faster and smoother.
Original PR description
when removing approver name in approver line, name won't show again and you need to refresh the record first. Fixed by updating the approver domain so that it would include itself. Task: 3627695
55 changes
Resolved issues and error corrections
This fix removes unnecessary EDI (Electronic Data Interchange) fields from internal transfer payment forms in Mexico. Internal transfers don't require SAT (tax authority) signatures, so displaying these fields was confusing. The change simplifies the user interface by hiding these fields when processing internal transfers.
Original PR description
An internal transfer must not be signed in the SAT. Odoo does not allow generating a EDI document in that process, but shows all the MX fields to EDI documents. Now, the fields are not in the view for internal transfers. Forward-Port-Of: odoo/enterprise#44420 Forward-Port-Of: odoo/enterprise#42569
This update corrects how Social Security Numbers (SSNs) are displayed on employee payslips in the US payroll system. Previously, when printing payslips, an extra character string was being added to the SSN field. The fix ensures that the privacy mask (showing only the last 4 digits as XXXXX1234) is properly applied only when an SSN exists, without adding unnecessary extra characters.
Original PR description
In the US it is necessary to show the Social Security number (SSN) and hide the first 5 numbers (ex: XXXXX1234). When we print the Payslip of an employee with or without an SSN in their record (hr.employee), an extra number chain is added to the printed Payslip. The mask XXX-XX should only be applied when there is a number and it should overwrite the 5 first characters, not be pasted before. Task link: http://www.odoo.com/web#id=3630674&model=project.task task-3630674
This update fine-tunes the appearance of the Portal customer interface following a recent redesign. It fixes spacing inconsistencies, improves layout alignment across different devices, and adjusts font sizes to ensure a polished and professional look for customers viewing their subscriptions and invoices.
Original PR description
# Portal layout fixes This PR fixes some issues within Portal, mainly about spacing, layout, and font-size. - **Requires**: https://github.com/odoo/odoo/pull/147496 - task-3651084 ## Why do we introduce these changes We recently merged the portal redesign. While the redesign is almost done for every screen, we needed to fine tune some spacing or fix some layout issues. ## List of the different changes ### sale_subscription: - [x] Add the expiration date - [x] Fix unconsistent layout for the display of the date - [x] Put the delivery column on the right of the invoice one - [x] Fix minor wording issues
This fix corrects an issue where public holidays in India were incorrectly deducting amounts from employee paychecks and appearing on payslips. The work entry type associated with public holidays has been removed to ensure employees are not charged for these non-working days.
Original PR description
A generic work entry type is used for India's public holidays, which results in the amount being deducted and displayed on the payslip. Therefore, we must remove it. task-3668569
This fix resolves a crash that occurred when creating new deduplication rules in the Data Cleaning module. The issue was caused by querying data without properly preparing the database first, which has now been corrected. Users can now successfully create and save deduplication rules without encountering errors.
Original PR description
Issue: ====== Creating a new deduplication rule will raise a traceback. Steps to reproduce the issue: ============================= - Install data_recycle - Go to Data cleaning/configuration/deduplication - Create a new deduplication rule and save Origin of the issue: ==================== We are querying the data using sql without flushing the model first. opw-3658414
This fix resolves an error that occurred when creating new deduplication rules in the Data Cleaning module. The issue happened because the system tried to access data before it was properly saved to the database. By ensuring the data is flushed to the database at the right time, users can now successfully create and save deduplication rules without encountering errors.
Original PR description
### Steps to reproduce issue: 1. Try to create a new deduplication rule in Data Cleaning module 2. Add mandatory fields (Choosing a "Model" will compute all of them), then save. 3. You get an error: > return self.models[model_name] > KeyError: None ### Explanation: `_search_company_id` is called with a SQL request looking for the currently being saved record. In 17.0, this record is not yet added to the database thus can not be found, leading to an error in the following lines. https://github.com/odoo/enterprise/blob/11e513741499c40e3b339a33b4e3f5c9a2edb511/data_merge/models/data_merge_record.py#L99-L102 ### Suggested fix: `data_merge.model` needs to be added to the table, using flush_model, before trying to access the values in `_search_company_id`. Also using this PR to prevent the same issue from occuring with `data_merge.record`. opw-3673652
This fix resolves a performance issue in the General Ledger report where clicking "Unfold All" would load all lines at once, causing browser slowdowns or freezes on large databases. The system now properly applies the load limit (80 lines by default) to prevent overwhelming the browser with too many elements to render at once.
Original PR description
Before this fix, when clicking "Unfold All" on the General Ledger, the "Load More Limit" assigned to the report (80 by default) was not applied, and all the lines were always loaded in the UI. This caused performance issues on large databases, where the high number of move lines do display can overload the browser, slow it down a lot, or even freeze it (due to the high number of elements needing to be rendered). This was due to the fact the General Ledger's _custom_batch_data_generator needed to filter the additional elements it loads. We cannot filter directly in SQL because we get everything in a single batched query, but we can restrict the number of elements we return after getting them from the db. OPW 3672271 Forward-Port-Of: odoo/enterprise#54664 Forward-Port-Of: odoo/enterprise#54384
This fix ensures that tax report default values are properly calculated when posting a tax closing entry, not just when manually setting the tax lock date. Previously, users would see incomplete or missing values in their tax reports after posting a closing, which could lead to confusion or incorrect reporting. The fix also includes improved test coverage to prevent this issue from recurring.
Original PR description
Before this fix, when the tax closing was posted, though the tax lock date was properly updated, the default external values (computed from _default expressions) of the tax report were not computed. It only worked when setting the tax lock date manually from the lock wizard. We take advantage of this commit to improve the test suite in order to check all possible cases for the creation of default external values. Forward-Port-Of: odoo/enterprise#54654 Forward-Port-Of: odoo/enterprise#54080
This update ensures Belgian payroll tax declarations (forms 281.10 and 281.45) comply with 2023 requirements. The changes include updated validation rules, corrected declaration formats, and a fix to prevent trainees from being incorrectly included on tax forms where they shouldn't be reported.
Spreadsheets were appearing in the wrong order in the spreadsheet selector dialog when using collaborative editing. This fix updates the contributor tracking when users join a spreadsheet, ensuring proper ordering and display of available spreadsheets for insertion.
Original PR description
…ve edition Since 396fe57c08f3997a0a600190d12e2229089627bc, the spreadsheets shown in the spreadsheet selector dialog (dialog to select a spreadsheet to insert something into) are not correctly ordered anymore. This is due to the fact that the contributor table is not correctly updated when a modification is made in the spreadsheet, as with the collaborative edition we use `spreadsheet.revision` to update the spreadsheet whereas before we used the `write` method. This commit fixes this issue by updating the contributor table when the user join the spreadsheet. We could also have updated the contributor table when the user do an update (create a `spreadsheet.revision`), but this would have cause a lot of useless updates. Task-id 3601075 Forward-Port-Of: odoo/enterprise#54929 Forward-Port-Of: odoo/enterprise#52324
This fix corrects the account codes used for employee-related expenses in the Swiss payroll accounting module. Two accounts were moved from the equity section (29xx) to the proper expense section (5xxx): Indemnities from 2990 to 5840, and Company Car Correction from 2999 to 5031. This ensures the Swiss Balance Sheet balances correctly and aligns with standard Swiss accounting practices. Users will need to reload their chart of accounts to apply this fix.
Original PR description
In https://github.com/odoo/odoo/pull/105119, new accounts were added to represent employee-related expenses. Based on the non-official document…
In https://github.com/odoo/odoo/pull/105119, new accounts were added to represent employee-related expenses. Based on the non-official document https://swissdec.ch/document/share/295/4cc46aca-8b47-49e9-882a-03c37eb8dea3 we used account codes 2990 and 2999 for accounts 'Indemnities' and 'Company Car Correction'. However, these accounts have no place with the equity accounts in 29xx, since they are not equity but rather expense accounts. Examples of CoAs that include employee indemnity accounts place them under account group 5 with the other employee-related expenses. (e.g. https://plancompta.com/plan-comptable-suisse-pcg-2021/) As such, we move accounts 2990 Indemnities -> 5840 and 2999 Company Car Correction -> 5031. Fixing this in stable will not cause any in-database corruption, since the updated code is only executed when the CoA is loaded/reloaded. However, users will need to reload the CoA in order to take advantage of the fix. This also ensures that the Swiss Balance Sheet is balanced. Community PR: https://github.com/odoo/odoo/pull/150692 taskid:3060790
Fixed an issue where clicking the 'payments' link on the accounting dashboard for a specific journal (like BANK or CASH) would display all unreconciled payments from every journal instead of just the selected journal. Now the payments list correctly filters to show only payments from the journal you clicked on.
Original PR description
### Steps to reproduce * install `account_accountant` * create payments in the CASH and BANK journal * go to the accounting dashboard * click 'payments' for the BANK or CASH journal You should see that the newly opened list view displays all the unreconciled payments, from all journals. It should only display the payments from the journal you clicked. opw-3688740 Forward-Port-Of: odoo/enterprise#54524
This fix corrects how the system calculates the date for retrieving Belgian bank statements. The code was using an absolute year setting instead of a relative calculation, which caused incorrect date lookups. Now it properly goes back 2 years from today to fetch the correct historical statements.
Original PR description
`relativedelta`'s `year` is absolute whereas `years` is relative. In our case, we need to go back 2 years relatively to the current date, therefore we should use `years`.
This update corrects variable names in subscription payment tests to accurately reflect what they store. Previously, variables labeled as "payment_method" were actually storing payment tokens, which caused confusion with a new payment_method variable being added to the system. This fix ensures clearer code organization and prevents naming conflicts.
Original PR description
Many tests were giving the name `payment_method` to variables that are actually storing a payment token. This conflicted with the `payment_method` variable being added to `PaymentCommon`. See also: - https://github.com/odoo/odoo/pull/149833
This fix prevents global company holidays and leave periods from being incorrectly duplicated when running salary simulations. Previously, the system would copy these shared leave settings during simulation runs, which could cause confusion and data inconsistencies. Now simulations use the existing global leave data without creating duplicates.
Original PR description
…lation
Fixed an issue where employees renewing their contracts couldn't see their previously selected bike in the available options, even though the bike amount was calculated correctly. The fix ensures that an employee's existing bike is now included in the bike selection list when signing a new offer.
Original PR description
When you have to sign an offer and have a bike on your previous contract, the amount is correct, but the selected bike is not the good one. It is because you own bike is not availbale in the list. So we add it.
Users encountered an error when trying to restore deleted articles if they didn't have access to the parent article. This fix allows users to successfully restore articles from trash without permission errors, improving the user experience when managing article hierarchies with restricted access levels.
Original PR description
Currently, the user encounters an access error when attempting to restore an article whose parent is inaccessible. Upon restoration, the system accesses the parent article to determine whether the…
Currently, the user encounters an access error when attempting to restore an article whose parent is inaccessible. Upon restoration, the system accesses the parent article to determine whether the article to restore should be detached from its parent. Note: If the parent article is in the trash, the article should be detached from its parent. Otherwise, it will be automatically deleted when deleting the parent article due to the cascading delete. When the user does not have access to the parent article, the system will raise an access error when doing the check. This commit addresses the issue by introducing a `sudo` on the read call causing the access error. Steps to reproduce the issue: 1. Log in as "Mitchell Admin" 2. Create an article in the workspace 3. Add "Marc Demo" to the member list with "No access" 4. Create an article under the article create at step 2 5. Set the permission of "Marc Demo" to "Can write" 6. In the "More option" panel, click on "Delete" 7. Log in as "Marc Demo" 8. On the Knowledge editor, click on "Open the Trash" 9. Open the article you deleted 10. In the "More option" panel, click on "Restore From Trash" => "Marc Demo" gets an access error when restoring the article. TO BE: "Marc Demo" should be able to restore the article and should not get any access error. task-3648854 Forward-Port-Of: odoo/enterprise#53148
This fix resolves an error that occurred when upgrading the French financial reports module. A database constraint was preventing the upgrade because two report expressions had conflicting labels. The solution removes the outdated expression during the upgrade process, ensuring smooth updates for existing systems while maintaining compatibility with new installations.
Original PR description
In #42351, the account.report.expression with xmlid `account_financial_report_line_02_0_6_fr_bilan_passif_balance` was deleted, and in its place was defined `account_financial_report_line_02_0_6_fr_bilan_passif_net`. However, since the two have the same `label='net'` the SQL constraint introduced in https://github.com/odoo/odoo/commit/987b82e5c9add1e9e2a9fdabe6dc73a3a6daa9ec would fail when upgrading the module. To resolve this, we prefer to delete the old expression pre-migration rather than revert the change in xmlid, in order to not break things for new databases where the new xmlid is used. Upgrade PR: https://github.com/odoo/upgrade/pull/5533 opw-3659810 Forward-Port-Of: odoo/enterprise#54629 Forward-Port-Of: odoo/enterprise#53492
This update fixes a visual glitch in the navigation menu's toggle arrow when using right-to-left languages like Arabic or Hebrew. The arrow now displays correctly in RTL mode, improving the user experience for international users.
Original PR description
Prior to this commit, the `o_menu_toggle` arrow had a glitch when the language was set on RTL. This commit adapts the arrow to fix this glitch. task-3548808 | Before | After | |--------|--------| |  |  | Forward-Port-Of: odoo/enterprise#51554
A translation string in the timesheet leaderboard feature was not properly exported for translation. This fix ensures the string is now available for translation into all supported languages, improving the user experience for non-English speaking teams.
Original PR description
This PR adds a missing translation string that was incorrectly not exported
This fix resolves an upgrade failure in the Belgian HR Contract Salary module that was preventing the system from properly validating a contract template view. The issue occurred because a field was positioned after a button that referenced it, causing validation errors during upgrades. By moving the field to the correct location in the view configuration, the upgrade process now completes successfully.
Original PR description
After odoo/enterprise#54811, the upgrade[^1] of this module fails to validate the `hr_contract_salary.hr_contract_view_form_contract_templates` view because the field `work_time_rate` is "restricted to the group(s) hr.group_hr_manager". Move the (hidden) field above the button that use it to avoid this view validation error. [^1]: For some reasons, it only happen during upgrade and not during normal install.
This update fixes a bug in the Swiss payroll module's LPP (occupational pension plan) compensation rule calculation. The system was not properly accessing the amount value in the rule, causing errors. This fix ensures that employee compensation calculations for LPP contributions work correctly.
Original PR description
We are not accessing the amount in the rule, resulting in an error.
This update removes an unused payment field that was incorrectly appearing in the Approval Types configuration form. The field had no functionality and was never used by the system, so hiding it cleans up the user interface and reduces confusion when managing approval types.
Original PR description
The field ´has_payment_method´ (approval_category.py) is not related to anything but is rendered in form view. Steps to reproduce: ------------------- * Open ´Approvals´ app * Select ´Configuration´ * Select ´Approval Types´ * Select any type Why the fix: ------------ The field is never used anywhere. opw-616042 Forward-Port-Of: odoo/enterprise#54237
This fix restores the ability to recalculate taxes on confirmed sales orders using the "Compute Taxes" button. Previously, this button had no effect on confirmed orders, but users can now update taxes through external tax integrations just as they could in earlier versions. This is particularly useful for subscription orders where tax adjustments may be needed after confirmation.
Original PR description
Before this, clicking the "Compute Taxes" button on a confirmed sale order does nothing. It was possible in previous versions to re-calculate taxes on confirmed sale orders and it's especially handy on subscriptions. Furthermore, it's possible to manually change the taxes on confirmed sale orders anyway, so there's no reason to prevent changing them through an external tax integration. opw-3694079
A previous fix for spreadsheet tour data was incomplete because pivot formulas were trying to access records that don't exist in test environments. This update adds a dedicated test spreadsheet file that uses only actual available data, making the tests more reliable and preventing errors during automated testing.
Original PR description
The fix proposed in 5d19c678 was not thorough as the pivot formula present in the demo sheet will call `name_get` on given record ids that are likely not existing without the demo data (see [1]). This revision adds a dedicated spreasheet file that goes around that problem and limits the name_get calls to actual data (in this case, rely on the country_ids). [1] https://runbot.odoo.com/runbot/build/54397846 Forward-Port-Of: odoo/enterprise#54846 Forward-Port-Of: odoo/enterprise#51734
This fix resolves an issue where timesheet hours created from a timer weren't properly reducing the remaining hours on a sales order in multi-company environments. The problem occurred when helpdesk projects lacked an assigned company, causing the system to lose track of the unit of measurement. The fix adds a fallback to use the current company's settings when a project company isn't specified, ensuring timesheets are correctly counted toward billable hours.
Original PR description
Steps to reproduce: ------------------- - install helpdesk_fsm and sale_timesheet; - to be in a multi-company environment; - create a new helpdesk team with "Timesheets", "Time Billing"; - the newly…
Steps to reproduce:
-------------------
- install helpdesk_fsm and sale_timesheet;
- to be in a multi-company environment;
- create a new helpdesk team with "Timesheets", "Time Billing";
- the newly created project has no company;
- create a service product that creates a task with UoM in hours in the newly created project for the helpdesk team;
- create a sale order with this product with a quantity of 100 hours and confirm it;
- in the helpdesk app (in the new team), create a ticket linked to the sale order line of the product (the customer is necessary);
- on the ticket the "Remaining Hours on SO" is 100 hours;
- create a timesheet directly in the tree view;
- the remaining hours of the sale order are reduced;
- create a timesheet from the timer;
- the remaining hours of the sale order are not reduced;
Cause:
------
During the link between the newly created timesheet and the ticket, we write to the `helpdesk_ticket_id` field (during the flush) in the `account.analytic.line` record. As a result, we pass in the override of the `write` method, which calls `_timesheet_preprocess`. Without a company on the project (or on the analytic account if there is one), the value `{'product_uom_id': False}` will be added to the values to be written to the timesheet. Without a unit of measurement, the timesheet will not be used to calculate the remaining hours.
Solution:
---------
Add a fallback on the current company if no company is found.
opw-3651830
Forward-Port-Of: odoo/odoo#149893This fix addresses a critical accounting discrepancy that occurred when changing a product's inventory valuation method. Previously, when a product's category was changed from manual to real-time valuation after creating inventory adjustments, the system would show mismatched values between inventory and accounting records (a 60€ difference in the example). This fix reverts a previous change that introduced this issue, ensuring accurate financial reporting.
Original PR description
This reverts commit 652edc38527b14995f017d514053a57825091813. It creates a new issue with valuation change. Steps to reproduce: -Create a new product with a cost of 10 (std, manual) -Create an inventory adjustment to set the quantity to -3 -Change the product's category to real-time -Now the valuation for this product is -30€, but the accounting part has 30€, creating a difference of 60€." A better solution to fix both issues has been tried but it was far from optimal. Since it's an edge usecase we will not support it until master 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#149053 Forward-Port-Of: odoo/odoo#147949
This fix resolves an issue where internal users assigned to a company without a website could not access the shop page, receiving a permission error instead. The fix ensures that users can properly access the shop functionality regardless of their company's website configuration, improving the user experience in multi-company environments.
Original PR description
Description of the issue/feature this PR addresses: - Create a company A with a ebsite - Create a company B without website - Create user 1 in company B only --> Issue when user 1 go to /shop --> error 403 Due to security restrictions, you are not allowed to access 'Companies' (res.company) records. https://github.com/odoo/odoo/assets/16716992/968c5c73-e5b5-41e1-b1b2-4916f7283e36 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150108
This fix corrects how Odoo calculates invoice prices for kit products in companies using anglosaxon accounting. Previously, if a Bill of Materials (BOM) changed between order delivery and invoicing, the system could use outdated pricing information. The fix now uses the BOM that was actually used during stock movement, ensuring invoices always reflect the correct costs.
Original PR description
**Description of the issue/feature this PR addresses:** sale mrp accounting for anglosaxon accounting companies **Current behavior before PR:** The BOM may suffer variances from the SO is confirmed till it is invoiced. The BOM associated to the stock moves is more reliable because the cost used in the stock journal is based on that BOM. In order to reproduce the bug you have to have: - Confirm and deliver a SO with KIT BOM - Archive the BOM and create and updated version - Invoice the SO **Desired behavior after PR is merged:** The fix is giving preference to the bom of the stock moves of the sale line, which makes more sense. Because BOMS for the products can change since the sale order was confirmed, not only being archived. It can be also a second version of the BOM which takes over with higher priority. Forward-Port-Of: odoo/odoo#149257 Forward-Port-Of: odoo/odoo#146118
This update resolves two issues in the text editor's color picker feature. Users were experiencing a system error when trying to change text background color after selecting text with spaces, and the color picker would become unresponsive and blink continuously. The fix ensures the color picker works reliably when applying colors to selected text.
Original PR description
This branch fixes two related issues: Issue 1:A traceback issue in `hasColor` Issue 2: When partially select the text and some blank spaces, and change the background color, the background color picker is blinking all the time and cannot choose a color. More details about reproduction and fix are in the commit message Task-3476494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149064 Forward-Port-Of: odoo/odoo#133577
This fix prevents the system from unnecessarily recalculating work entries when running salary simulations. By avoiding redundant recalculations, the salary simulation process now runs more efficiently without affecting actual work entry data.
Original PR description
…simulation 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 random test failures in the Point of Sale configuration settings. When switching between different store configurations, the system now properly updates available pricelists to match the selected store's currency, preventing incompatible pricelist assignments that were causing configuration errors.
Original PR description
After https://github.com/odoo/odoo/commit/54a6f1688fb8d15b662848b03cecbe8236292d07, the `TestConfigureShops.test_should_not_affect_other_pos_config` and `TestConfigureShops.test_is_header_or_footer_to_false` started to fail randomly in runbot. This is because when res.config.settings form initializes, it may start with `pos_config_id` that contains pricelists that are not compatible to the currency of the pos_config that will be selected in the form. This commit makes sure that when the `pos_config_id` is changed to something that doesn't use pricelist, the `pos_available_pricelist_ids` field is updated accordingly. Runbot Errors: 31294, 31293 Forward-Port-Of: odoo/odoo#150220
Fixed an issue where the "Generate Email" button was not appearing when creating new recruitment source trackers. The system now properly checks for email domain configuration by falling back to the company's mail alias domain when a new tracker record doesn't have its own alias yet, ensuring users can generate tracking emails as expected.
Original PR description
To reproduce on runbot: - Log-in as admin - Enable debug mode - Go to Settings / General Settings and ensure that there is a alias domain configured for the current company - Go to recruitment app - on "Experienced Developer", open the option dropdown (meatball) and click on "Trackers" - observe there is no button "Generate Email" The `has_domain` field serve to check if the mail alias domain is correctly configured, before odoo/odoo@638e0f658, is was computed only from the `mail.catchall.domain` ICP, now we only consider the alias domain from the recruitment source alias. But for new record there is no alias, so `has_domain` is always falsy which prevent the `Generate Email` button to be show. This commit fallback to the job's or user's current company mail alias domain to check if mail alias is correctly configured when there is no alias on the recruitment source. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how document type codes are generated in Romanian electronic invoicing (CIUS-RO) XML exports. Previously, the system was not properly handling document type codes according to validation rules. Now, invoices will not include a document type code, while credit notes will correctly include the code '50', ensuring compliance with Romanian EDI standards.
Original PR description
In one of the schematron rules for CIUS-RO, there is a rule for DocumentTypeCode element in the XML that failed the validity test.
```sch
<rule context="cac:AdditionalDocumentReference">
<assert id="UBL-SR-43" flag="fatal" test="((cbc:DocumentTypeCode='130') or
((local-name(/*) = 'CreditNote') and (cbc:DocumentTypeCode='50')) or
(not(cbc:ID/@scheme) and not(cbc:DocumentTypeCode)))">
[UBL-SR-43]-Scheme identifier shall only be used for invoiced object
(document type code with value 130)
</assert>
</rule>
```
This commit fixes the current behavior by applying this behavior:
- DocumentTypeCode won't show up when exporting Invoice XML
- DocumentTypeCode will show up with the value '50' when exporting CreditNote XML
task-id: 3649426This fix resolves an issue where the "Edit Event Menu" option was appearing multiple times in the website editor navigation. The problem occurred because the same menu identifier was being used in multiple page templates (for desktop and mobile versions), causing the system to detect and display duplicate menu editing options. The fix ensures each menu is only shown once, even when multiple templates reference it.
Original PR description
Steps to reproduce (17.0+): - Go to an event website page > go to “Site” > “This Page”. - The menu item used to edit the page content menu “Edit Event Menu” is duplicated. After the event page…
Steps to reproduce (17.0+): - Go to an event website page > go to “Site” > “This Page”. - The menu item used to edit the page content menu “Edit Event Menu” is duplicated. After the event page refactoring in [1], a second template using the same content menu ID was added to customize the UI for mobile. And since the “Edit Menu” items generation is based on detecting current sub menus from the DOM using the same ID (`data-content_menu_id`), we get a new menu item in the nav bar for every menu template using it. The goal of this PR is to fix this behaviour by simply ignoring the duplicated menu IDs (The same menu record will be edited anyway). Remark: the behaviour fixed by this PR was detected in 17.0, but we target 16.0 to prevent any potential issue linked to duplicated menus in the DOM, also, the duplicated data attribute will be removed in master (one ID is enough for the content menu to be detected and edited.) [1]: https://github.com/odoo/odoo/commit/9f2442d09b62fcb3f687ec39928ea0e3ac49557e Forward-Port-Of: odoo/odoo#150491
This fix resolves a crash that occurs in the email marketing editor when users save content containing text or comment nodes within card blocks. The issue affected users creating email templates with the Comparisons block (version 15.0) or Event block (version 16.0+). The fix ensures the editor properly handles all types of content nodes without crashing during the save process.
Original PR description
__Current behavior before commit:__ If `child` is not an `Element` (like a Text or a Comment node), the call to `querySelectorAll` at the following line will crash. __Description of the fix:__ End the current loop iteration if `child` is not an `Element` to avoid calling `querySelectorAll` on it. __Steps to reproduce the issue on runbot:__ In 15.0: - Open Email Marketing > Mailings > Create > Second template - Drag and drop a `Comparisons` block - Display source code - Write some text under the `<div class="card ...">` - Save --> Traceback In 16.0+: - Open Email Marketing > Mailings > New > `Start From Scratch` - Drag and drop an `Event` block - Replace one of the image (a comment node will be added [here][1]) - Save --> Traceback opw-3682469 opw-3689181 [1]: https://github.com/odoo/odoo/blob/df1b43a6de5ad15a8fee3713de7d8ec926c61f12/addons/web_editor/static/src/js/backend/convert_inline.js#L715 Forward-Port-Of: odoo/odoo#150096
Fixed a bug where customers purchasing only service products (non-physical items) would encounter an error during checkout when delivery methods like easypost are configured. The system now correctly skips delivery validation when there are no physical products to ship, allowing service-only orders to proceed to payment without errors.
Original PR description
Steps to reproduce: - Setup easypost delivery - Create a service product and publish it on the website - Add that product alone to the cart and proceed to payment Bug: Error raised because total weight of the order is null Fix: no delivery will be created so we should skip the check if no deliverable product is present on the order note: on "_get_shop_payment_errors" switched the order to short circuit "_get_delivery_methods" opw-3647420 Forward-Port-Of: odoo/odoo#150475 Forward-Port-Of: odoo/odoo#147765
This update resolves compatibility issues between the IoT V23_11 system and Odoo databases running versions 15.0, 16.0, and 17.0. The fix adjusts the versions of three critical software libraries (urllib3, PyPDF2, and Werkzeug) to ensure they work properly with these Odoo versions, preventing system failures when the IoT checkout system connects to older database versions.
Original PR description
When the IoT V23_11 checkout a Odoo DB 15.0, the newest module: urllib3 PyPDF2 Werkzeug Can't run this Odoo version. So we fix the version of these module to match to Odoo 15 / 16 / 17 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 a crash that occurred when users double-clicked on charts in the dashboard on mobile devices or small screens. The mobile dashboard component was missing a required function, causing an error. We've added this function to prevent the crash and ensure a smooth user experience on all device sizes.
Original PR description
Steps to reproduce ================== - Use a mobile viewport / device (small window) - Go to Dashboard - Double click on a chart => `this.env.openSidePanel is not a function` Cause of the issue ================== On mobile, the MobileFigureContainer is used instead of the Spreadsheet component. The both use `useSubEnv` but the mobile one was missing the openSidePanel function. Solution ======== Add an empty `openSidePanel` function that does nothing. opw-3677552 Forward-Port-Of: odoo/odoo#150629
This update corrects an unintended spacing issue in the web editor where the "Slideout Effect" option was appearing indented below the "Colors" option in the Footer settings. The fix ensures that spacing is only applied between related options on the same row, preventing unrelated options from appearing misaligned.
Original PR description
Since [1] a margin is applied when another `o_we_user_value_widget` follows a color palette. Unfortunately this is also applied when the two elements are not on the same row. Because of this the "Slideout Effect" option below the "Colors" option of "Footer" looks like it is indented while it is unrelated to the color selection. This commit restricts that margin to elements that belong to the a `we-row`. [1]: https://github.com/odoo/odoo/commit/2f81c6ae68751d5f93c30aef822730ee04ead391 task-3696870 Forward-Port-Of: odoo/odoo#150614
This fix resolves permission errors that occur when the system automatically creates activity logs during stock operations, such as when receiving inventory in quantities different from the original purchase order. By using elevated permissions for logging activities, users can now complete these operations without encountering access restriction errors, improving the reliability of inventory management workflows.
Original PR description
Description of the issue/feature this PR addresses: In some places I think it is necessary to use sudo to avoid permission errors when creating actions or something else from a other model. For example, I have a stock picking created from PO attached to MO. When receiving inventory in a smaller quantity than actual quantity, will create activity schedule on MO. But if you don't have the rights, you will get an error 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#150348
This fix corrects the account codes for employee-related expenses in the Swiss chart of accounts. Two accounts were incorrectly placed in the equity section (2990 and 2999) and have been moved to the proper expense section (5840 and 5031), aligning with standard Swiss accounting practices. Users will need to reload their chart of accounts to apply this correction, which also ensures the Swiss Balance Sheet balances correctly.
Original PR description
In https://github.com/odoo/odoo/pull/105119, new accounts were added to represent employee-related expenses. Based on the non-official document…
In https://github.com/odoo/odoo/pull/105119, new accounts were added to represent employee-related expenses. Based on the non-official document https://swissdec.ch/document/share/295/4cc46aca-8b47-49e9-882a-03c37eb8dea3 we used account codes 2990 and 2999 for accounts 'Indemnities' and 'Company Car Correction'. However, these accounts have no place with the equity accounts in 29xx, since they are not equity but rather expense accounts. Examples of CoAs that include employee indemnity accounts place them under account group 5 with the other employee-related expenses. (e.g. https://plancompta.com/plan-comptable-suisse-pcg-2021/) As such, we move accounts 2990 Indemnities -> 5840 and 2999 Company Car Correction -> 5031. Fixing this in stable will not cause any in-database corruption, since the updated code is only executed when the CoA is loaded/reloaded. However, users will need to reload the CoA in order to take advantage of the fix. This also ensures that the Swiss Balance Sheet is balanced. Enterprise PR: https://github.com/odoo/enterprise/pull/54941 taskid:3060790
This fix resolves a crash that occurred when decimal fields were displayed in list views with empty or null values. The issue was caused by using an incorrect formatter for float fields, which has now been corrected to properly handle missing data.
Original PR description
Bug === The decimal property crash when added in a list view, if some records have False as a value. Technical ========= Since fe797a03285ec9c81d29ed631839c91e2b9957a4 , we use the wrong Formatter in the Float field. Task-3698415
This fix corrects a validation issue where empty JSON fields were incorrectly being saved even when marked as required. Previously, an empty object was treated as a valid value. Now the system properly rejects empty JSON fields that are marked as required, ensuring data integrity and consistency with how other required fields work.
Original PR description
Steps to reproduce ================== - Enable analytic accounting - Go to customer invoices - Open a record - Open studio - Click on the Invoice lines > Edit list view - Set the analytic field as…
Steps to reproduce ================== - Enable analytic accounting - Go to customer invoices - Open a record - Open studio - Click on the Invoice lines > Edit list view - Set the analytic field as required - Close studio - Create a new record - Add a new line - Click on the analytic field - Close the popup - Save the record => Even though we didn't set a value for the field, it is saved Cause of the issue ================== The actual field value is an empty object. The validity of a field is checked here [0]. An empty object is considered a truthy value. When setting the required attribute directly on the python field declaration, an empty object does not pass the check Solution ======== Add a specific check for json fields. When the value is either false (not set) or an empty object, the field is considered invalid. --- [0]: https://github.com/odoo/odoo/blob/23f01c533512cbfb33e90509e22cd3c3c4f99d40/addons/web/static/src/views/basic_relational_model.js#L284 opw-3659763 Forward-Port-Of: odoo/odoo#150603 Forward-Port-Of: odoo/odoo#149840
This fix resolves a problem where certain email links (like buttons with no URL) were causing browser redirect loops when clicked. The system now properly converts relative links to absolute ones before tracking them, ensuring emails with fragment-only links work correctly and users can access the intended pages.
Original PR description
Install mass_mailing with demo data, send a mailing using the "Thank you for joing us" template. Inside your mail client, click on the LOGIN button, this open your web browser on a link-tracker URL…
Install mass_mailing with demo data, send a mailing using the "Thank you for joing us" template. Inside your mail client, click on the LOGIN button, this open your web browser on a link-tracker URL (`/r/xyz`) but the page fails to load because "The page isn’t redirecting properly". Inside the template of that "Thank you for joing us" mail, the logging button is basically defined as follow: `<a href="#">LOGIN</a>`, an URL with a fragment that is empty, a redirection to the current page. Upon rendering that template and send it to the reciptients, all links are wrapped inside a link-tracker for well tracking purpose, this created a link `/r/xyz` targetting `#`. Upon accessing that `/r/xyz` URL the client would be redirected to `#` which in that context is actually `/r/xyz#`: the link-tracker itself. The browser detects that there is a redirecting loop and show an error instead. The problem is solved by saving an absolute link with the link-tracker instead of a relative one. [Task-3603607](https://www.odoo.com/web#id=3603607&cids=1&menu_id=4720&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#150546 Forward-Port-Of: odoo/odoo#147855
This update fixes a data migration issue in the Swiss localization module that was preventing some databases from properly updating their tax configurations. The fix corrects tax classification data that was previously updated, ensuring the system can now successfully migrate this data without errors.
Original PR description
In a previous commit we fixed Swiss localization's taxes data. We changed two children taxes that had wrong tax_type_use since it depends on their parents. This could raise the python constraint `_check_children_scope()` which is preventing some databases to correctly update their taxes. See https://github.com/odoo/odoo/commit/7b07df873535446f97abc1de9176b9332de5cb07 Forward-Port-Of: odoo/odoo#150386 Forward-Port-Of: odoo/odoo#148724
This fix restores the ability to create model-based forms on websites. A recent system update changed how the form registry works, causing errors when creating these forms. The fix adds proper default values to prevent these errors from occurring.
Original PR description
Since [1] when the legacy registry was replaced for website forms, model-based forms cannot be created anymore because the legacy registry getter returned a falsy value upon missing keys, while the new registry raises an error. This commit specifies a default values on the calls to the registry to avoid the error. [1]: https://github.com/odoo/odoo/commit/2d9f6fb32441b5db386e35200a5aab6b11b840dd#diff-59b3bc5742547152ea8d3248e1bd6606fbace25e572d7ca6c50c61e5847d184fL3-R3 opw-3677790 opw-3683466
This update improves the performance of the HR holidays dashboard by optimizing how data is loaded and processed. Employees and managers will experience faster dashboard load times, making it easier to quickly view leave information and manage time-off requests.
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
This fix resolves a problem where bullet lists were not being created properly in the web editor when users tried to apply bullet formatting. The issue occurred when the cursor was positioned on empty text nodes. The fix ensures bullet lists are created correctly by moving the selection to the parent element, similar to how the editor handles other special elements.
Original PR description
**Current behavior before PR:**
Sometimes applying bulletlist does not produce the expected bullet list formatting .This issue arises when the selection is on an emptyTextNode(""), and the traversal of nodes using getTraverseNodes results in the same emptyTextNode(""). In the toggleList function, we typically remove the emptyTextNode(""), leaving no appropriate node for creating a bullet list.
**Desired behavior after PR is merged:**
Now it will create bullet list because we move the selection to its parent when it is on an emptyTextNode(""), similar to what we have done with the "BR" element.
task-3547574
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#138999This update fixes a bug that prevented the automatic database cleanup feature from working properly. The cleanup function, which helps maintain database performance by removing unnecessary data, had stopped functioning due to a recent change. This fix restores the feature to its intended operation.
Original PR description
The bug was introduced from this commit 72c1a4f This PR fixes the bug. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a crash that occurred in the Discuss app when users tried to fold a category (like "Channels") without having a conversation selected. The issue was caused by missing safeguards in the code that didn't properly handle the case when no conversation was active. This ensures a smoother user experience when managing conversation categories.
Original PR description
Before this commit, when no conversation was selected in the Discuss app, folding a category such as "Channels" results in a crash. This happens because `store.discuss.thread` is `undefined`, so it must be properly guarded in the template of discuss sidebar category.
Fixed an issue where survey administrators were unable to review or print completed survey answers if the deadline had passed. The deadline now only applies to completing new survey responses, not to reviewing existing answers. This allows managers to review survey results at any time without being blocked by past deadlines.
Original PR description
This deadline is about completion, not review Task-3680802 Forward-Port-Of: odoo/odoo#149100
This fix improves the Picking Operations report by correcting layout issues that were causing text to appear too small and the overall design to look odd. The problem was caused by improper HTML structure in the report template and unnecessary placeholder content appearing when fields were empty. Users will now see a properly formatted report with readable text sizes.
Original PR description
Before this commit, the Picking Operation report's texts were small and the layout was somewhat odd. This was because of [1]: - an oe_structure div was added in a bootstrap row that was already filled (all bootstrap cols were used) This did not play nice in wkhtmltopdf and made the texts size very small. - a scalar t-field add a default content which was rendered if the field's value was False (which can happen when the field is unset) opw-3668900 [1]:567b8d676b3b6dc747df4d9bf10e7a91b4cb61bb 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#150813
This fix resolves an issue where payment methods could not be removed from Point of Sale configuration settings. When users tried to remove a payment method and save, the change was not being applied. The fix updates how the system processes payment method changes to work correctly with the latest version of Odoo.
Original PR description
The change introduced in 72f7c0d7d16a1b avoids recomputes when there is nothing that needs to be written on a pos.config. However, starting v17 the way x2many are managed changed and while the command to assign values on x2many from settings was `[(6, 0, ids)]`, in v17 it's `[[4,id],...,[4,id]]`. The `SET` command was replaced by the `LINK` command. This changes the returned value of the `convert_to_cache` method and made it impossible to change pos_config.x2many values in v17 because of the changes in 72f7c0d7d16a1b. To fix that, move the `_keep_new_vals` method from res_config_settings to pos_config and use `_preprocess_x2many_vals_from_settings_view` to change link commands to unlink + link commands. Steps to reproduce: - Install point_of_sale - Go to Settings > Point of Sale - Remove a payment method - Save - The payment method is still set on the pos.config. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where user avatars were not displaying in portal chat messages when users were authenticated using hash and PIN instead of access tokens. The system now recognizes both authentication methods, ensuring avatars appear consistently for all portal users regardless of how they logged in.
Original PR description
In portal chatter, user could be authenticated with `access_token` or `hash and pid`. The problem is that `portal_avatar()` only checks the access_token, so if it doesn't have the access token but the hash and pid, it misses the user's avatar ([PR odoo#141414](https://github.com/odoo/odoo/pull/141414)). This commit adds these two parameters to `portal_avatar` controller to cover all cases of authentication in portal chatter messages. Forward-Port-Of: odoo/odoo#150689 Forward-Port-Of: odoo/odoo#149897