Wednesday, February 21, 2024
8 changes · saas-17.1
Resolved issues and error corrections
Fixed an issue that caused Studio to crash when adding a website form from the Website tab. Users can now complete the website form setup flow as expected, reducing interruptions when building or editing website pages.
Original PR description
In the website tabl, try to add a website form Before this commit, there was a crash because of some callback that was not bound. After this commit, the flow works as expected. opw-3735624
The Sign app no longer crashes when a user clicks Resend after uploading and sending a document. This restores the ability to resend signature requests, reducing disruption in document signing workflows.
Original PR description
Cureently when sending a document through the sign app, when selecting the resend button, a traceback error occurs.
**Traceback:**
TypeError: Cannot read properties of undefined (reading 'context')
at HTMLButtonElement.onClickResend (https://58003451-saas-17-1-design_theme.runbot168.odoo.com/web/assets/52d3ed5/web.assets_web.min.js:22102:916)
Steps to reproduce:
-------------------
* Go to the **Sign** app
* Select **Upload a PDF & Sign**
* Upload a pdf
* Send it
* Select **Resend**
Observations: Traceback error
Why the fix:
------------
Commit 1 adapted the enterprise codebase to adapt to the changes made in community (Commit 2) where the user service has been removed. User can be imported/accessed directly.
**Commits:**
1. https://github.com/odoo/enterprise/pull/52372/commits/1fd42adcd09f5169602969eee49a6bffacd0a467
2. https://github.com/odoo/odoo/pull/145362/commits/ae6604318bfbea4c389808b51d0cbf2546dc7373
opw-3717911This 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
Code cleanup and technical improvements
This update streamlines how currency information is loaded for spreadsheets, reducing the number of requests needed to format monetary values. By combining currency data with the main list data, the process is faster and more efficient, leading to quicker spreadsheet calculations. This change also lays the groundwork for future improvements in data loading reliability.
Original PR description
With this commit, list data is loaded using `web_search_read` instead of `search_read`. The goal is to fetch the currency (symbol, decimal places, etc.) of monetary fields in a single request,…
With this commit, list data is loaded using `web_search_read` instead of `search_read`. The goal is to fetch the currency (symbol, decimal places, etc.) of monetary fields in a single request, instead of 2 RPCs. Pros: - less code - one evaluation saved - one network request saved - easier future refactoring (see below) Cons: - overhead of data transferred over network (from 4.5MB to 6.5MB, unzipped, to fetch a list of 20K crm leads). Before this commit, here is what it looked like: 1. the list data is fetch (with the currency_field) 2. the cells are evaluated with the new data 3. we realize we want to format a currency amount. We already have the currency name but not the symbol, etc. So we fetch the currency data 4. evaluate the cells again with the new currency format Now: 1. fetch the list data with everything we need for the currency 2. evaluate the cells This commit also serves another goal for a future refactoring: in the hope of avoiding throwing "loading errors", I'd like to have an easy way to know if a data source is fully loaded or not (the data and the format). With this commit, everything is centralized in the list data source with a single RPC. The goal is therefore achieved with this commit. Task: 3730232 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#153434