Daily updates from Odoo
Thursday, February 1, 2024
6 changes
1 change
Enhancements to existing features
Planning shifts are changed to represent the exact working periods rather than broad multi-day blocks that are later adjusted against schedules. This makes planning clearer and overlap checks more reliable, with a new split option to turn long shifts into schedule-based working segments.
Original PR description
Currently, it is possible to create a shift for, say, a whole week. When your shift expands from su 00:00 to sa 23:59, we find its intersection with your schedule and deduce the allocated time.…
Currently, it is possible to create a shift for, say, a whole week. When your shift expands from su 00:00 to sa 23:59, we find its intersection with your schedule and deduce the allocated time. Typically, 40h. In my opinion, a planning app should be used to know exactly when you will be working on what. So, in an overall functional perspective, it doesn't make a lot of sense to have a 168h long shift when you work 40h a week. Now, from a technical perspective, I also think the current state complexifies the code. Say that you want to check if 2 shifts are overlapping (which, obviously, is one of the main questions you ask yourself when planning) -for now, let's forget about `allocated_percentage`. In theory, it should be trivial. However, when the start/end to consider is in fact the start/end of the work interval that is inside the shift (let alone the lunch break), what could have required 1 LOC now requires to search in other tables, asking again, essentially, "when is the resource actually working?". And if you have to do it in a SQL query (see `_compute_overlap_slot_count`), well you just don't because it is too complex, and you end up with an uncorrect result. The same question is asked and answered not very elegantly when trying to assign shifts automatically (see `auto_plan_ids`). My sense is that we should keep it simple and stupid: `allocated_hours = (end_datetime-start_datetime) * allocated_percentage` Now, in order not to force the user to create 10 shifts for a week where is used to only create one of them, I suggest adding a button "scissors" on the from view that instead of saving one big shift, would fragment it once and for all into the 10 desired shifts, taking into account the resource's schedule. Technical downsides: - (Way) more records in DB. Functional downsides: - I think Odoo consultants are used to creating, say, 3 one-week shifts whose sum of percentages is 100%. With this commit, their gantt view will be clogged with 6 shifts per day. But again, my point is: it doesn't sound like the proper way to use a planning app. - If you have a one week shift, and you fall sick on tuesday, we now have to reassign all the following shft, rather than splitting it and reassigning the 2nd part. task-?
5 changes
Enhancements to existing features
This update significantly speeds up the confirmation process for large purchase orders in manufacturing operations. Previously, confirming orders with over 50 lines would take several minutes or timeout; now the same orders complete in seconds. The improvement optimizes how the system processes order data, making it practical for users to work with large orders containing hundreds of line items.
Original PR description
### Current behavior: Confirming a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client, they had PO with more than 200 lines which makes it impossible for them to confirm them. ### Step to reproduce: - Install mrp and mrp_subcontracting - Create PO with more than 50 order lines or more - Try to confirm it - Take a long time or timeout ### Benchmark (made in 16): | No. of PO lines | Before | After | |-----------------|:-------:|:------:| | 9 | 1s30 | 1s30 | | 91 | 1min | 16s | | 273 | 4min | 50s | | 405 | 4min30s | 1min6s | ### Fix: Batch more actions and records to reduce the number of queries generated by the ORM. opw-3625892 Forward-Port-Of: odoo/odoo#149383 Forward-Port-Of: odoo/odoo#146442
Resolved issues and error corrections
This fix resolves a critical error that occurred when the website helpdesk module was installed and website menu items lacked URLs. The system was incorrectly processing null URL values, causing 500 internal server errors when accessing the database. The fix ensures only menu items with valid URLs are processed, restoring normal website functionality.
Original PR description
If website_menu don't have a url and website_helpdesk module is installed, hence, we checked particular website_menu's url as a result we got the false value for url if it's null, that's why while…
If website_menu don't have a url and website_helpdesk module is installed, hence, we checked particular website_menu's url as a result we got the false value for url if it's null, that's why while connecting the database
"500 internal server error" is raised as below.
To resolve this issue, This PR will help to fetch only those records which have
url in website_menu.
```
500: Internal Server Error
[Traceback](https://43.test.upgrade.odoo.com/en#error_traceback)
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1722, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1749, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1866, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/17.0/addons/website/controllers/main.py", line 97, in index
top_menu = request.website.menu_id
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2886, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1206, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1388, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4858, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 101, in determine
return needle(*args)
File "/home/odoo/src/odoo/17.0/addons/website/models/website.py", line 181, in _compute_menu
menus.mapped('is_visible')
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6066, in mapped
recs = recs._fields[name].mapped(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1280, in mapped
self.__get__(first(remaining), type(remaining))
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1206, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1388, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4858, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 101, in determine
return needle(*args)
File "/home/odoo/src/enterprise/17.0/website_helpdesk/models/website.py", line 26, in _compute_visible
helpdesk_menus = self.filtered(lambda menu: menu.url[:9] == "/helpdesk")
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6089, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6089, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/enterprise/17.0/website_helpdesk/models/website.py", line 26, in <lambda>
helpdesk_menus = self.filtered(lambda menu: menu.url[:9] == "/helpdesk")
TypeError: 'bool' object is not subscriptable
```This fix resolves a critical issue that prevented users from generating return labels when using UPS shipping. The problem occurred because the return label function wasn't properly updated during a previous system upgrade, causing errors when users tried to validate deliveries with the return label option enabled. This fix updates the code to work correctly with the current system.
Original PR description
This commit fixes some issues that prevented the user from generating a return label in UPS REST module. To reproduce: Create a new shipping method with UPS. Enable "generate return label" toggle, and attempt to validate a delivery. There are a few issues as `ups_rest_get_return_label` was not adapted when forward porting from 15 to 16: + `_prepare_shipping_data` is changed, so it does not return `package_names` + `label_binary_data` from `_send_shipping` is changed from a dictionary to a list + as `package_names` no longer is there, the log message needs to be adapted. This PR fixes these issues, so that the return label could be generated. opw-3689861 Forward-Port-Of: odoo/enterprise#55328
This update significantly speeds up the job kanban view in the recruitment module by optimizing how application counts are calculated. The improvement reduces loading time from 800 milliseconds to just 6 milliseconds, making the recruitment interface much more responsive for users managing job applications.
Original PR description
Purpose ======= From 800ms to 6ms to execute _compute_new_application_count on odoo.com 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 update adds validation to prevent users from saving record rules with incorrect domain syntax. Previously, a typo in a record rule domain could lock users out of the system entirely. Now, the system will catch and reject invalid domains before they're saved, protecting system stability and user access.
Original PR description
**steps to reproduce:** - create an ir.rule on res.users and write a domain with a typo **before this commit:** - users can't log into odoo **after this commit:** - an error is raised to prevent saving a bad domain opw-3653746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151640 Forward-Port-Of: odoo/odoo#147763