Wednesday, February 21, 2024
17 changes · saas-17.1
Enhancements to existing features
This update clarifies the descriptions for key functions within the spreadsheet account module – specifically `ODOO.ACCOUNT.GROUP`, `ODOO.FISCALYEAR.START`, and `ODOO.FISCALYEAR.END`. These improvements enhance clarity and usability for users, ensuring accurate data input and processing within the spreadsheet.
Original PR description
Improve the wording of the argument descriptions for the functions `ODOO.ACCOUNT.GROUP`, `ODOO.FISCALYEAR.START`, and `ODOO.FISCALYEAR.END`. Task: [3680374](https://www.odoo.com/web#id=3680374&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#154668 Forward-Port-Of: odoo/odoo#153177
Resolved issues and error corrections
This update resolves a bug where users could see multiple quiz versions when quickly clicking the 'Done' button in the eLearning app. The fix ensures only one quiz is displayed, improving the user experience and preventing potential confusion. This change also addresses a similar issue with video content.
Original PR description
How to reproduce: 1. Open eLearning app 2. Go to any course having document with quiz. 3. Solve the quiz 4. Click multiple time quickly on 'Done' (green tick) button. 5. Multiple quiz are displayed…
How to reproduce: 1. Open eLearning app 2. Go to any course having document with quiz. 3. Solve the quiz 4. Click multiple time quickly on 'Done' (green tick) button. 5. Multiple quiz are displayed if your connection is slow or you click fast enough. The fix ensures that only one quiz is displayed. We do the same change for video to prevent such problem with them. Technical note: when clicking on the "green tick" of the quiz, the method _toggleSlideCompleted is called which cause a _renderSlide. That method clears the content div (o_wslides_fs_content) and appends a new Quiz widget to that div. The problem is that the "append" is asynchronous (it call the "willStart" of Quiz widget that fetch the quiz) so if you click multiple time, the content div is cleared multiple times and then after each quiz created is ready (after having fetched the data), they are appended to the content div, resulting in multiple quiz displayed. We solve the problem by avoiding concurrent execution of the _renderSlide method: the body of the method is skipped when the rendering is ongoing (for example while waiting the quiz from the server). As the method is inserting the slide at the same place, its behavior was anyway unpredictable because depending on the response time of each request. By skipping the method body while already running we make it a bit more predictable, avoid the content duplication on the page, and we avoid unnecessary call to the server. Task-3412847 Forward-Port-Of: odoo/odoo#154069 Forward-Port-Of: odoo/odoo#143743
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,…
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 addresses a technical issue within Odoo's core functionality related to how it processes read groups. While the underlying change might seem minor, it ensures a more robust and reliable system, preventing potential errors. This fix prioritizes stability and proper error handling.
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 fixes a conflict between the 'Cancel' button and its shortcut key (z) within the activity scheduling feature. The hotkey has been changed to 'x' to avoid confusion and ensure users can easily cancel scheduled activities. This improves the user experience and prevents accidental actions.
Original PR description
Since 17.0, the `Cancel` button in the `mail_activity_schedule_view_form` uses the hotkey `z`, which conflicts with the other button. Change the hotkey into `x`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154727
This update resolves an issue where Odoo forms crashed when adding new records linked through inherited relationships (using _inherits). The fix ensures that parent record updates only occur when the related one2many field has a valid value, preventing initialization errors and improving stability.
Original PR description
Consider models A and B such that B inherits from A (with `_inherits`), and a form view of A with a one2many field that inverses the many2one "delegate" field from B to A. When adding a new record in the one2many, `onchange()` crashes while trying to update the cache of an empty parent record. The situation is caused by how `onchange()` initializes the new record of model B, and the fact that the form provides a value for the delegate field. The new record is actually initialized with an empty value for the delegate field, which causes the code to crash. The fix simply consists in updating the parent record only if is nonempty. opw-3744514 Forward-Port-Of: odoo/odoo#154735
This update fixes an issue where HR emails sent when applicants are rejected were being automatically deleted. This prevented HR from seeing communication and gaining a complete record of applicant interactions. The change ensures that all emails related to rejected applicants are retained, providing a more accurate and complete history.
Original PR description
When HR refuses applicants in batch and sends mails, the mails are removed, because auto_delete_keep_log is set to false. It gives to HR wrong understanding that mails have not been send. Expected behavior; Don't remove refused mails, when sent in batch Forward-Port-Of: odoo/odoo#154720
This update adds a "Cancel" button to the activity plan wizard, which was missing in the recent v17 release. Users can now easily cancel their activity plan creation, reverting to the previous state without needing to use the "X" button. This improves user experience and simplifies the process of managing activity plans.
Original PR description
Restore the "Cancel" button when selecting a plan from the activity wizard. When we introduced the plan feature in v17, the "Cancel" button was forgotten. The only way for users to cancel the action is to click on the "X" button at the top right. task-3754897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154678
This change temporarily disables a failing test in the website's link tools to address persistent issues. The test has consistently failed due to underlying race conditions, and this action allows the test to run successfully on the automated system. A permanent fix is planned for a future commit.
Original PR description
runbot-57204 Forward-Port-Of: odoo/odoo#154679 Forward-Port-Of: odoo/odoo#154244
This update removes a confusing 'No documents to display' message from the customer portal. Because users always have access to their addresses and security/connection cards, this message was unnecessary. This change improves the overall user experience and reduces potential frustration for customers.
Original PR description
Remove `No documents to display` as there will always be at least the addresses and security/connection cards. task-id: 3629038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146197
This update corrects a minor issue where users were incorrectly redirected to general settings when clicking the Google and Outlook calendar sync buttons. Now, clicking these buttons will correctly direct users to the calendar settings, improving the user experience and ensuring seamless calendar synchronization. This resolves a previous navigation problem.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** 1. Configure Google and Outlook Calendar and navigate to the calendar app. 2. Click on the Google and Outlook sync button, redirecting to the general settings. **Issue:** Users are now redirected to the general settings by using the Google and Outlook sync button. **Solution:** Update the `doAction` so, users will be redirected to the calendar settings. task-3731652 <hr/> I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153581
This update fixes an issue where 'mandatory' days in the holiday calendar were displaying with an inconsistent color, causing visual problems. The changes now ensure 'mandatory' days render correctly with the calendar's background colors, providing a cleaner and more professional look. This improves the user experience when scheduling and viewing holidays.
Original PR description
"Mandatory" days use a random text color and they don't render well with the colored background colors of `.fc-today` and hovered days. The text-color has been removed on hovered mandatory days and mandatory days happening "today". The background of "fc-today" now uses the color of mandatory days when that day is mandatory. The SCSS has been cleaned up so as to not create repetitions. task-3617334 part of task-3575827 | Before | After | |----|-----| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144236
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
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