Monday, March 13, 2023
6 changes · master
Resolved issues and error corrections
The picking "To do" filter now shows only pickings that still require action, instead of including completed or cancelled records. This helps users focus on relevant warehouse work and reduces confusion in stock and batch picking views.
Original PR description
Description of the issue/feature this PR addresses: The 'To do' picking filter made no sense as it used to check the pickings that are not assigned or assigned to the user. The new behavior corrects it by checking if the previously selected pickings are not in a 'done' or 'cancel' state. Current behavior before PR: picking filter wrong, returns done or cancelled pickings Desired behavior after PR is merged: picking filter does not return done or cancelled pickings --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Portal user deletion now runs in a dedicated scheduled process that handles large databases more reliably and avoids repeated work after timeouts. The change also removes related nonessential records automatically where appropriate, while preserving linked business contacts when they cannot safely be deleted.
Original PR description
Purpose ======= Improve the portal user deletion by preventing timeouts and avoiding several rollbacks causes. Specifications ============== - Move the portal users deletions from autovacuum to its own cron. On big databases such as odoo.com, deleting a res.users takes more than 1 minute. Move the whole process into its own scheduled tasks. - Commit the deletion at each user. As said previously the deletion can be expensive, so commit what has been done to avoid having to delete the same user again in case of rollbacks or timeout. - Delete the user and the partner separately. If the partner is used in a sales order for instance, the unlink is possible for the user and not the parner. It allows to unlink the user and keep the partner in case it cannot be deleted. - Re-call the cron into another transaction in case there are too many users to delete, instead of waiting next call, that is supposed to occur the day after. TaskID: 3222941
This fix prevents users working from the backend website editor from being unexpectedly redirected to the public frontend when clicking items like blog tags, course tags, pagers, or shop snippets. It keeps navigation in the current editing context while preserving the needed exception for creating a page from a backend 404 page.
Original PR description
Since [the merge of the frontend into the backend] and more precisely since [this commit], clicks on some elements makes the user switch from the backend view to the frontend view. Steps to reproduce…
Since [the merge of the frontend into the backend] and more precisely since [this commit], clicks on some elements makes the user switch from the backend view to the frontend view. Steps to reproduce (just an example): - Go to /blog from the backend (/@/blog) - Click on a tag (eg: adventure) => users are redirected to the frontend view, we do not want that. This commit makes the user stay in the backend. For some scenarios (like the one above), we create a fake form and submit it. The forms have a target attribute that specifies where the form response should be displayed. This commit set back the default value for the target attribute when a user clicks on a blog tag, a course tag, the pager, ... so that the response is displayed in the current context (the iframe when the user is in the backend). Note that [this commit] introduced the target attribute change to fix two issues: 1. The opening of the payment gateways in the iframe. 2. The create page from a 404 page in the backend. After [this other commit] has been merged, to prevent the first issue so here we just remove the target attribute change except for the case of the second issue. [the merge of the frontend into the backend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b [this commit]: https://github.com/odoo/odoo/commit/2d44f2792dec0b2f205475a22dbedc97e9c54a64 [this other commit]: https://github.com/odoo/odoo/commit/3a32b9e1efa6277b345dc9239334680651690df7 task-3054970
A small issue in the Planning app was fixed by using the correct source for a date range helper. This helps prevent related planning timeline behavior from breaking due to an incorrect internal dependency.
Original PR description
Before this commit: computeRange was imported from a wrong source "@web/core/l10n/dates". In this commit: computeRange is now imported from gantt_model as it should be.
Fixes an issue where adding property fields to article items in a Knowledge kanban could cause the embedded article view to fail. The required field data is now loaded so users can return to the main article without seeing an error placeholder.
Original PR description
To display the property fields, we need to load in the view the field storing the definition of the property field. Currently, we forgot to load that field for the kanban view showing the article items of the active article. As a result, the view can not properly load the property fields and the embedded view ends up crashing. This commit will fix that issue by simply loading the required field in the kanban view. Steps to reproduce the error: 1. Open an article 2. Use the /kanban command 3. Create a new article item 4. Add new property fields 5. Go back on the main article => The embedded view shows the error placeholder. => The following error occurred in onWillStart: "parent is undefined" Related: https://github.com/odoo/enterprise/pull/37004 task-3218435
Knowledge property field inputs now always show an underline, making it clearer to users that they can be edited. The fields also better use the available panel width, improving readability and consistency in the Knowledge interface.
Original PR description
For the property fields of Knowledge, we would like to always underline the property field inputs to indicate that they are editable. Currently, some inputs get an underline only when the user focuses or hovers the element. This PR will ensure that the underline will always be visible. It will also add some css tweaks to ensure that all inputs take the full width of the panel. Related: https://github.com/odoo/enterprise/pull/37299 task-3221040