Daily updates from Odoo
Wednesday, February 21, 2024
20 changes
5 changes
Resolved issues and error corrections
This update resolves an issue where users couldn't edit content after undoing a column command in the web editor. The fix ensures that the editor correctly recalculates and re-establishes the unique identifier (ouid) for elements after reverting changes, allowing for seamless editing.
Original PR description
Issue: ===== When you undo a column command, you won't be able to write on that line anymore. Steps to reproduce the issue: ============================= - Go knowledge - Use column command to add…
Issue: ===== When you undo a column command, you won't be able to write on that line anymore. Steps to reproduce the issue: ============================= - Go knowledge - Use column command to add columns - Do ctrl+z - Try to write anything Origin of the issue: ==================== When we apply a columns operations , it will use the current block and insert it under the first column so the `ouid` of the block will change to the `oid` of the div (the column) so will will have 2 mutations : one to remove the block from the root and one to add the block under the column. Reverting history will do the operations in reverse order, so it will remove the block from under the column and the add it under the root but the `block.ouid` is already set to `oid` of the column which is different from the actual `ouid` which is `root` so adding any text to the block will first add a textnode with `getOuid(node,true) = block.ouid) != "root"` and `getOuid(node,false) = "root"` so it will mark `this._toRollBack` as true and the operation is rolled back that's why we can't add anything anymore. Soltuion: ========= Mark the `ouid` of the removed elements as undefined so when we insert them again we can recalculate it correctly. task-3693076 Forward-Port-Of: odoo/odoo#150431
This update addresses a potential issue where new modules automatically grant the Default Template User's permissions to existing employees. Now, administrators can disable this automatic propagation through a simple setting, giving companies greater control over user access rights. This prevents unintended escalation of permissions and aligns with company security policies.
Original PR description
When installing a new module, the access of the Default Template User is propagated to any existing employee (introduced at aefb05eb497a8a16a). This can be problematic in companies that don't want all their employees to become manager by default. Allow to disable this behaviour in a settings. This is the version of the patch targetting stable version that is not configurable through the interface, manually creating an ICP base_setup.default_user_rights_minimal=True as the way to change the behaviour. Closes odoo/odoo#149224 Task-id 3685856 Forward-Port-Of: odoo/odoo#150391
This update fixes an issue where the stock move date in the traceability reports incorrectly displayed the scheduled production date instead of the actual completion date. The fix ensures that the reports accurately reflect the date the production was finished, improving inventory reporting accuracy. This resolves a discrepancy impacting inventory valuation and reporting.
Original PR description
Issue: ===== The stock move date is the scheduled date of the production and not the date the production is done. Steps to reproduce the issue: ============================= - Create a manufacturing order with any product (large desk) - Assign a date in the past for scheduled date (5 days before) - Confirm the order. - Added quantity produced and mark as done - Go to traceability , you will see the date here is the scheduled date and not the production date. - You can see also the inventory at date in inventory/reporting/locations will have the product they after the scheduled date. Solution: ========= Use the value of `date_finished` in `date_planned_finished` because it's responsible for calculation of `date` of `move_finished_ids`. opw-3640708 Forward-Port-Of: odoo/odoo#154745 Forward-Port-Of: odoo/odoo#149358
This update ensures that payment method configurations are correctly applied, allowing overriding modules to control payment method availability. Additionally, the system now automatically archives payment tokens when a payment method is disabled or no longer supports tokenization, preventing future payments through outdated tokens.
Original PR description
[FIX] payment, sale: forward kwargs to `_get_compatible_payment_methods` The keyword arguments of the callees were never forwarded to the `payment.method::_get_compatible_payment_methods` method,…
[FIX] payment, sale: forward kwargs to `_get_compatible_payment_methods` The keyword arguments of the callees were never forwarded to the `payment.method::_get_compatible_payment_methods` method, preventing overriding modules from controlling which payment method should be available depending on the kwargs. task-3640488 --- [FIX] payment: archive tokens of payment methods blocking tokenization When a payment method was updated in a way that prevented creating tokens with it, that is, by either disabling it, unchecking the "Tokenization Supported" field, or unlinking it from providers, only the latter would automatically archive the related tokens after showing a warning to the user. The two first actions prevented the creation of future tokens with that payment method, but existing tokens could still be used. This commit fixes that behavior by adding the warning and the automatic archiving of related tokens where they were missing. Preventing further tokenization with a payment method now consistently blocks payments through existing tokens, too. --- See also: - https://github.com/odoo/enterprise/pull/54700 Forward-Port-Of: odoo/odoo#150120
This update fixes an issue where the Peppol endpoint could not handle special characters, ensuring data integrity. It also updates the system to always check the commercial partner ID for Peppol verification, resolving a previous limitation that prevented users from sending invoices to specific contacts. This enhancement improves the reliability of Peppol invoice processing.
Original PR description
### [FIX] account_peppol: add endpoint constraint The Peppol endpoint must not contain special characters. This commit adds a constraint, where the input is being sanitized. If the endpoint is not…
### [FIX] account_peppol: add endpoint constraint The Peppol endpoint must not contain special characters. This commit adds a constraint, where the input is being sanitized. If the endpoint is not filled in, we already throw an error when creating an edi user, so that should be fine. task-3718573 ### [FIX] account_peppol: check commercial partner instead of partner When checking a partner's validity on Peppol network, we should always check the `commercial_partner_id` to get the right eas & endpoint. Also, the Peppol verification check should not occur if the current company does not have an active peppol registration. Currently, if a user wants to send an invoice to a specific contact of a partner, they cannot as `_need_ubl_cii_xml` evaluates to False because the contact is not a valid Peppol participant. opw-3748720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154823 Forward-Port-Of: odoo/odoo#152654
15 changes
Resolved issues and error corrections
Fixed an issue in the Partner Ledger report where searching for a partner by email would incorrectly display unrelated partners in the PDF output. The search filter was matching against multiple partner fields instead of just the partner name, causing incorrect results. This fix ensures that only the intended partner appears in filtered reports.
Original PR description
Steps to reproduce: - create a partner with a random name; set the email as "deco@test.com" - create and confirm an invoice for this partner - On partner ledger, search for "deco" -> the report filters out all partners except Deco Addict - print the pdf Issue: The new partner appears on the pdf report Cause: We set on the domain only "partner_id". The `where_calc` returns as the where clause `res_partner.display_name ilike text_search and res_partner.email ilike text_search and etc.` By not specifying the field on the domain, we query on multiple field from res_partner Solution: Specify the field that intereses us when defining the domain opw-3712980 Forward-Port-Of: odoo/enterprise#56910 Forward-Port-Of: odoo/enterprise#56516
A variable naming issue in the cohort analysis feature was causing incorrect data to be displayed in reports. The problematic variable was being reused in multiple places, contaminating the calculations. This fix renames the variable to prevent the collision and adds tests to ensure the issue doesn't happen again.
Original PR description
The code for web_cohort runs several read_group calls with domains that are dynamically generated. It appears that a name collision found its way into this code at its inception and has survived undetected until now, despite affecting the returned data significantly. The problematic variable is named `domain` and is meant to indicate the domain used for a specific cell of the cohort, but its generic name made it leak to the base of the computation, polluting it entirely. This commit renames the problematic variable and adds a test to avoid regression on that front. Forward-Port-Of: odoo/enterprise#43917
This update fixes the Belgian HR payroll 281.10 tax declaration form to comply with 2023 regulations. Changes include updating car exemption rules, ensuring bike travel kilometers and amounts are properly declared even when below taxable thresholds, and adding mandatory information fields required by Belgian tax authorities.
Fixed a formatting issue in the Field Service worksheet report where tables with multiple products and assignees were incorrectly breaking across pages, causing table headers and content to overlap. The fix removes an unnecessary CSS class that was preventing proper page layout, allowing reports to display correctly across multiple pages when needed.
Original PR description
Issue: - in the Field Service module when a task includes multiple products with detailed sales descriptions and is assigned to more than one person, the generated worksheet report table is too big to fit the first page so it starts on the 2nd page.the page break is off and the table content on the 2nd page is mixed with the table heading Steps To Reproduce: - Create a task in field service - Have products added to the task with some sales description - Have 2 assignees - Try to print the worksheet - Notice It'll space to the next page if there's too many lines instead of it adjusting to two pages accordingly Solution: - Adjust the worksheet template by removing the 'div class="table-responsive-sm"' it seems removing the class, or having "table" seems to fix the issue it would be better to remove the class since the direct child is already a .table opw-3701917 Forward-Port-Of: odoo/enterprise#56363
Fixed an issue in Colombia's withholding tax reports where empty line items (with zero tax base amounts) were incorrectly appearing in the Certificado de Retención en IVA report and being included in totals. The fix ensures that only transactions with actual amounts are reported, making tax documents cleaner and more accurate.
Original PR description
Create a Vendor Bill with a Colombia Partner and withholding tax Accounting > Reporting > Certificado de Retención en IVA Print PDF Issue: Currently the lines in the report are being generated despite the balance in “tax_base_amount” (“Monto Total Operacion) being 0.00. Expected behavior: If the “tax_base_amount is 0.00 do not consider this balance neither in the report lines nor in the SUM of the Report total. opw-3704972 Forward-Port-Of: odoo/enterprise#56849 Forward-Port-Of: odoo/enterprise#56308
This update fixes scrollbar behavior problems in the online store's product category filters that were caused by recent browser updates. The scrollbar now displays and functions correctly across different browsers (Chrome, Firefox) and devices, including better support for touchscreen devices where the hover effect is now disabled.
Original PR description
In commit https://github.com/odoo/odoo/commit/bdede43e1ea4587185a9f37f051cee87a61cf488 an improvement was made to increase the scrollbar height on hover to make it easier to scroll. However chromium…
In commit https://github.com/odoo/odoo/commit/bdede43e1ea4587185a9f37f051cee87a61cf488 an improvement was made to increase the scrollbar height on hover to make it easier to scroll. However chromium updated the way ::webkit-scrollbar works breaking the behavior on recent browser. On firefox the margin was applied without the change of height on the scrollbar creating a visual glitch on hover. On chromium >121 the `scrollbar` property takes priority over the `::webkit`-x to keep the scrollbar styling with height change on webkit browser we have to apply the `scrollbar` property only on Firefox. The mixin was used only on `website_sale` filter offcanvas and category horizontal scrollbar, this commit removes the mixin and customization on the offcanvas vertical scroll to make it consistent with the other offcanvas across website. This PR also disables the scrollbar hover effect on touchscreens. The transform was causing an issue on some devices displaying the scrollbar behind the items, thus it's now applied on the container. Note: We use not `.o_wsale_filmstip_fancy_disabled` to avoid the `scrollbar` property being set when the Javascript is not loaded yet. Otherwise the scrollbar would be invisible until a hover from the user. task-3718501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that automatically generated invoices link to the correct website where the original sales order was placed, rather than defaulting to the primary website. Previously, invoice preview links would always open the main website regardless of which website the customer used to make their purchase, creating a confusing experience in multi-website setups.
Original PR description
### Steps to Reproduce - Install **E-Commerce** app - Add Demo payment provider in Test mode - Go to **Settings** > **Website** > **Invoicing** and activate **Automatic Invoice** - Go to **Settings**…
### Steps to Reproduce - Install **E-Commerce** app - Add Demo payment provider in Test mode - Go to **Settings** > **Website** > **Invoicing** and activate **Automatic Invoice** - Go to **Settings** > **Website** and set the domain for: - My Website -we'll refer to it as **website_1**- as http://[IP_address]:[port] such as http://127.0.0.1:8069 - My Website 2 -we'll refer to it as **website_2**- as http://[IP_address]:[port] such as http://127.0.0.2:8069 - Create a new product with **Invoicing Policy** as **Ordered quantities** - Go to **website_2** and add the new product to the cart and checkout - With Debug mode on, Check the Emails sent via **Settings** > **Technical** > **Email** > **Emails** ### Current Behavior Two emails are automatically sent: - An SO email that opens **website_2** when clicking on **View Sales Order** button which is correct as we purchased the product through **website_2** - An Invoice email that opens **website_1** when clicking one **View Invoice** button which is **_WRONG_** as it should follow its originating SO and opens **website_2** as well ### Expected Behavior Both SO and invoice emails should refer to the website where the SO was created -**website_2** in our use case- ### Observations The automatic invoice always refer to **website_1** regardless of the website where the SO was originally created. ### Investigation The `website_id` of the invoice is decided by the corresponding field https://github.com/odoo/odoo/blob/322889ea0a24c5eff2e3289502a2f606cb4048d0/addons/website_sale/models/account_move.py#L10-L13 - As noticed it's a related field to the `partner_id.website_id` which is **False** - That's why the invoice `website_id` is also **False** leading to the preview button to fall back to **website_1** - The `partner_id.website_id` is always False unless you manually added the field to the view and then set the `website_id`. Our case will work correctly if you set the `website_id` for the user/customer to **website_2** - I also tried to sign up at **website_2** to see if the website_id will be set accordingly but it stayed as **False** ### Proposed Solution make the invoice `website_id` relates to the **_originating_** SO instead of the partner ### Drawbacks 1. I am not sure if depending on the `website_id` of the partner is crucial other parts! 2. In case the invoice has more than one SO associated with, the `website_id` relates to the website_id of the most recent SO. However, I don't think it will lead to a bug as the automatic invoice -to my knowledge- will always relate to one SO. ### Other solutions I thought of 1. Always set the website_id to the website_id sending the request via a default attribute. 2. Set the `website_id` to the website_id sending the request if the automatic invoice option is active other wise set to False. -Same as 1 but more conservative- 3. Enhance the current solution by adding a **default** and a **compute** attribute to set the `website_id` to **False** if the invoice has more than one SO and at least one SO has a different `website_id` than the rest. - Not sure if it worths the complexity tho- opw-3685742 Forward-Port-Of: odoo/odoo#153691 Forward-Port-Of: odoo/odoo#151070
When setting up Stripe payment processing for multiple companies, the system was incorrectly copying website information from one company's configuration to another, causing errors or misconfigurations. This fix ensures that website settings are properly cleared when creating a new Stripe payment provider for a different company, allowing smooth multi-company payment setup without conflicts.
Original PR description
Description: In a multi-company environment, `payment.provider` records are specific to each company. After activating Stripe on Company 1, you can set a Website for the record if you wish. If you…
Description: In a multi-company environment, `payment.provider` records are specific to each company. After activating Stripe on Company 1, you can set a Website for the record if you wish. If you wish to activate Stripe for Company 2, Odoo will use `.copy()` to create a new `payment.provider` record for Company 2. However, this will lead to differing incorrect behavior depending on the version. On 16, a new `payment.provider` record will be created, but will be connected to the Website set on Company 1's provider. On 17, Odoo will throw an error after a `check_company` call reveals that the Website set on the new record is for the wrong company, preventing the record from being created. In both cases, the `.copy()` grabs the optional Website set on the existing `payment.provider` record to be used incorrectly for the new record. Desired behavior after PR is merged: The Website relation is always neutralized when Odoo creates a new Stripe `payment.provider` record using the `.copy()` method opw-3683338 Forward-Port-Of: odoo/odoo#154280
This update significantly improves the speed of filtering operations in Odoo forms, particularly when working with large lists of items. For example, when adding automated actions and filtering available models, the system now processes these changes in milliseconds instead of several seconds, making the user experience much smoother.
Original PR description
Before this commit, calling _applyCommands with a lot of commands DELETE or UNLINK on a StaticList already containing a lot of commands was very slow. This happened for instance in the Automated Rule…
Before this commit, calling _applyCommands with a lot of commands DELETE or UNLINK on a StaticList already containing a lot of commands was very slow. This happened for instance in the Automated Rule form view, click on "Add an action", and in the dialog form view, select a "mail" type, e.g. "Add followers". In that form view there's a many2many field "available_model_ids" which contains at first almost all models of the database (LINK commands). Switching to a "mail" model restricts those models to the ones inheriting from the thread mixin, i.e. it generates a lot of UNLINK commands. On runbot, in represents 1000+ LINK and UNLINK commands. This could take several seconds. With this commit, we no longer iterate over all commands when applying a DELETE or UNLINK command. Instead, we simply push the command, store somewhere the information that we applied such a command, and after having processed all commands, we iterate (once) over this._commands, this.records and this._currentIds to do the necessary cleanups. task 3599674 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a problem where formatted numbers in shared spreadsheets were displaying incorrectly. When users shared a spreadsheet containing formatted large numbers (like 1.23 million), the shared link would show incorrect values (like 123 million). The fix ensures that the actual numeric values are exported correctly instead of relying on formatted text that could be misinterpreted.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153912 Forward-Port-Of: odoo/odoo#153704
This fix resolves an issue where users couldn't type or edit text after using the undo function (Ctrl+Z) on column layout changes in the web editor. The problem occurred because the system wasn't properly recalculating text block positions when reverting column operations. Now the system correctly resets block references during undo, allowing users to continue editing normally.
Original PR description
Issue: ===== When you undo a column command, you won't be able to write on that line anymore. Steps to reproduce the issue: ============================= - Go knowledge - Use column command to add…
Issue: ===== When you undo a column command, you won't be able to write on that line anymore. Steps to reproduce the issue: ============================= - Go knowledge - Use column command to add columns - Do ctrl+z - Try to write anything Origin of the issue: ==================== When we apply a columns operations , it will use the current block and insert it under the first column so the `ouid` of the block will change to the `oid` of the div (the column) so will will have 2 mutations : one to remove the block from the root and one to add the block under the column. Reverting history will do the operations in reverse order, so it will remove the block from under the column and the add it under the root but the `block.ouid` is already set to `oid` of the column which is different from the actual `ouid` which is `root` so adding any text to the block will first add a textnode with `getOuid(node,true) = block.ouid) != "root"` and `getOuid(node,false) = "root"` so it will mark `this._toRollBack` as true and the operation is rolled back that's why we can't add anything anymore. Soltuion: ========= Mark the `ouid` of the removed elements as undefined so when we insert them again we can recalculate it correctly. task-3693076 Forward-Port-Of: odoo/odoo#150431
This update fixes two issues with Peppol electronic invoice sending. First, it adds validation to prevent special characters in Peppol endpoints, ensuring data integrity. Second, it corrects how the system identifies valid invoice recipients by checking the main company partner instead of individual contacts, allowing users to send invoices to specific contacts of a partner when the company has active Peppol registration.
Original PR description
### [FIX] account_peppol: add endpoint constraint The Peppol endpoint must not contain special characters. This commit adds a constraint, where the input is being sanitized. If the endpoint is not filled in, we already throw an error when creating an edi user, so that should be fine. task-3718573 ### [FIX] account_peppol: check commercial partner instead of partner When checking a partner's validity on Peppol network, we should always check the `commercial_partner_id` to get the right eas & endpoint. Also, the Peppol verification check should not occur if the current company does not have an active peppol registration. Currently, if a user wants to send an invoice to a specific contact of a partner, they cannot as `_need_ubl_cii_xml` evaluates to False because the contact is not a valid Peppol participant. opw-3748720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152654
Fixed an issue where manufacturing orders were showing the originally scheduled date instead of the actual date when production was completed. This ensures that product traceability records and inventory reports accurately reflect when items were actually produced, not when they were planned to be produced.
Original PR description
Issue: ===== The stock move date is the scheduled date of the production and not the date the production is done. Steps to reproduce the issue: ============================= - Create a manufacturing order with any product (large desk) - Assign a date in the past for scheduled date (5 days before) - Confirm the order. - Added quantity produced and mark as done - Go to traceability , you will see the date here is the scheduled date and not the production date. - You can see also the inventory at date in inventory/reporting/locations will have the product they after the scheduled date. Solution: ========= Use the value of `date_finished` in `date_planned_finished` because it's responsible for calculation of `date` of `move_finished_ids`. opw-3640708 Forward-Port-Of: odoo/odoo#154745 Forward-Port-Of: odoo/odoo#149358
This update fixes a bug that caused the system to crash when using the read_group function with groupby=['id']. While this operation is uncommon, the system now handles it gracefully instead of throwing an error, improving overall stability and reliability.
Original PR description
Use read_group with groupby=['id'] raise a Exception:
```
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 2386, in _read_group_format_result
m2x_records = self.env[field.comodel_name].browse(ids).union()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 521, in __getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/Documents/dev/odoo/odoo/modules/registry.py", line 190, in __getitem__
return self.models[model_name]
KeyError: None
```
While if it doesn't make much sense to do this (it's mostly equivalent to search_read), it's preferable to handle the case properly.
Forward-Port-Of: odoo/odoo#154748
Forward-Port-Of: odoo/odoo#153505This update improves the speed of message loading in the mail system by optimizing how instant messaging status is tracked. The change reorganizes how the system calculates status information, reducing message insertion time by approximately 50% (from 60ms to 30ms in testing). Users will experience faster message delivery and loading times when using the messaging features.
Original PR description
Move compute of `imStatusTrackedPersonas` to its inverse field. Doing the compute on the "One" side of the relation prevents from looping and computing all values whenever there is a change in any of them. In practice, this reduces the "compute" time of the message fetch (which also fetch persona as authors of messages), reducing by approximately half the time it takes to insert these messages (depending on the number of persona it had to loop through). For example from 60ms to 30ms on my machine for message insert in "partner_1_125" (populate medium).