Saturday, August 31, 2024
4 changes · 17.0
Resolved issues and error corrections
Fixed an issue where users were unexpectedly redirected away from the barcode scanning interface to the backend system when a manufacturing backorder was automatically created. Now users remain in the barcode module to continue their work, improving workflow efficiency and reducing unnecessary navigation steps.
Original PR description
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a…
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a product P (no need for a bom) - Create and confirm a manufacturing order for 2 units of the product - Go to the barcode module > operations > manufacturing > the MO - Register only one unit of P and produce #### > A backorder is automatically created but you are redirected to the backend. ### Note: If you were in "ask" on create backorder or if your product had a bom and you did not register the quantities of consumed components, a pop up would appear and resolving the pop up would redirect you to the kanban view of mrp.production in the barcode module. ### Cause of the issue: The issue was originally solved by commit d90acab by overriding the `action_backorder` however, since commit 1e5c82f the action_backorder is no more part of the flow in "always" flows. opw-3890886
This update corrects a test that verifies portal users can create and edit knowledge articles. The test was passing incorrectly because it wasn't properly checking access permissions. The fix ensures the test now correctly validates that portal users have the right permissions to perform these actions.
Original PR description
Since odoo/enterprise#38575, portal users can create/edit knowledge articles. However, the test that checks that feature is not correct: - it does not call `check_access_rights()` (for ACLs); - it uses a `res.partner` instead of a `res.users` in `with_user()`. Because the test only checks access rules with a non-existing user, no rules are found, and the check is therefore trivial. In other words, the test passes by accident :-( The fix consists in creating a portal user for the corresponding "customer" contact, and add the expected calls to `check_access_rights()`.
This update resolves multiple access permission issues in the timesheet system that were preventing users from creating timesheets and validating entries. Users with standard project access can now start timesheets from tasks without encountering permission errors, FSM projects are properly restricted from quick creation, and timesheet validation now works correctly for employees without assigned managers.
Original PR description
When a user with 'user' access rigths on the project module that is also assigned to a task of an internal project, it will prevent the user from creating a new timesheet from the timesheet grid.…
When a user with 'user' access rigths on the project module that is also assigned to a task of an internal project, it will prevent the user from creating a new timesheet from the timesheet grid. This bug is due to the fact that when a user clicks on the line of the task, some rpc's call are made on the 'project' model. Since the user does not have access rigth to the internal project on which the call are made, an access rigth error is raised. Step to reproduce: - create a db with hr_timesheet installed - have a user with 'user' access rights on project and 'own timesheet' on timesheet - create an internal project - create a task inside that internal project and assigned the user on it - connect with the other user - open timesheet app - select the task from the internal project to start a new timesheet timer - an error access right on 'project' is triggered Solution: Add a sudo inside the python method 'check can start timer'. Give the project name to the timerHeaderM2O, to prevent the call to the name_get on the project. task - 3922511 affected version 16.0 - master Forward-Port-Of: odoo/enterprise#63159
The Knowledge module was missing required dependencies (web_cohort and web_gantt) in its configuration file, which caused the system to crash when installing the module. This fix adds these missing dependencies to ensure the Knowledge module installs and functions properly without errors.
Original PR description
In my enterprise db for some reason i didn't have the web_cohort installed and when installing Knowledge module my db crashed because knowledge module used web_cohort dependency but that dependency was not installed and was not listed on the manifest.py, the simple fix is to add to web_cohort as a dependency 