Wednesday, November 22, 2023
8 changes · 17.0
Resolved issues and error corrections
The Time Off setup now keeps leave types without a company from incorrectly receiving a default project or task. This prevents the task field from appearing unexpectedly on leave type forms, keeping configuration screens clearer and consistent.
Original PR description
Description of the bug:
task field is displayed in leave type form when company field is False
Steps to reproduce:
- install time off app
- open a leave type form
Source:
When installling time off app,
_compute_{timesheet_project_id, timesheet_task_id, timesheet_generate} work perfectly, when company = False => project/task = False and timesheet_generate = True
Then, the post_init is executed. it will set the project and task according to env.company when company is False. so now project and task can have values even that the leave company is False. Then in the xml, we hide project if company is null and task if project is null, that's why project is not displayed but not task
Solution:
- In post_init method, we only get leaves types without a company set and stop using env.company to be coherent with the compute methods.
X-original-commit: e647374Archiving an employee with a departure description now completes successfully instead of showing an Odoo error. The departure note is still recorded in the employee chatter, preserving the audit trail without relying on unsupported tracking for HTML content.
Original PR description
Step to reproduce the bug: -Go to the employee app -Go to an employee form view -Click on the archive button -Put a description -Click on the archive button -> Odoo error Bug explaination: The tracking is not implemented for the html field, so when we archive an employee the tracking cannot work. Expected behavior: The employee is archived and the tracking is done without errors. Bug resolution: The tracking has been removed from the html field. The tracking is now replaced by a message in the chatter in the write method. Behavior after this commit: The employee is archived and the tracking is done without errors with a mesage in the chatter if a value is entered for the departure_description field has a value. task-3576659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The IoT system now checks whether a database is connected to the IoT box before starting its communication client. This prevents needless background processing and avoids errors when no database is linked.
Original PR description
Add a condition that check if the DB is connected to the iot box before the start of the websocket client, before, if no DB was connected the Thread was lauched for nothing and an exeption was thrown --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now delete multiple employee work locations without triggering an error. The fix corrects how related employee location records are checked, preventing a crash during routine HR configuration cleanup.
Original PR description
This traceback arises when the user tries to delete `Work Locations`. To reproduce this issue: 1) Install `hr_homeworking` 2) Open `Employees/Configuration/Work Locations` 3) Try to delete multiple…
This traceback arises when the user tries to delete `Work Locations`.
To reproduce this issue:
1) Install `hr_homeworking`
2) Open `Employees/Configuration/Work Locations`
3) Try to delete multiple records
Error:-
```
ValueError: too many values to unpack (expected 3)
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "odoo/models.py", line 4160, in unlink
func(self)
File "addons/hr_homeworking/models/hr_work_location.py", line 17, in _unlink_except_used_by_employee
exceptions_using_location = self.env['hr.employee.location'].search(('work_location_id', 'in', self.ids))
File "odoo/models.py", line 1604, in search
return self.search_fetch(domain, [], offset=offset, limit=limit, order=order)
File "odoo/models.py", line 1627, in search_fetch
query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
File "odoo/models.py", line 5366, in _search
query = self._where_calc(domain)
File "odoo/models.py", line 5081, in _where_calc
return expression.expression(domain, self).query
File "odoo/osv/expression.py", line 788, in __init__
self.expression = domain_combine_anies(domain, model)
File "odoo/osv/expression.py", line 597, in domain_combine_anies
domain_any = _anyfy_leaves(domain, model)
File "odoo/osv/expression.py", line 371, in _anyfy_leaves
left, operator, right = item = tuple(item)
```
An invalid domain format is used when searching for the record in `hr.employee.location`.
See:
https://github.com/odoo/odoo/blob/def16f3725f8005874a18eb28b171523af1a0ecf/addons/hr_homeworking/models/hr_work_location.py#L17
sentry-4644429734Point of Sale receipt printing now hides the on-screen receipt while generating the print preview, preventing duplicate receipt content from appearing. This makes receipt previews and printed receipts look correct for users printing through the browser without a connected printer.
Original PR description
To reproduce ============ on POS (without having a connected print), make an order and print the receipt, the preview will show the receipt not well rendered Problem ======= we add the element that contains the receipt to the page, so we have two copies of the receipt (the page using CSS `@media print` and the added element) Solution ======== hide the original element on the page while printing, and bring it back after opw-3596341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now open the messaging menu even when the messaging system has not fully initialized yet. This prevents a frustrating access issue and makes the mail interface more dependable during loading or startup delays.
Users connecting to Codabox will now see a clear message if Odoo's IAP service is unavailable, instead of being sent to an incorrect web page. This helps businesses understand the issue quickly and avoid confusion during setup or connection attempts.
Original PR description
Currently, if IAP is down, we'll get no confirmation url when connecting to Codabox. Therefore, a null fallback was being used which would lead to an incorrect Odoo web page. Now, instead, we'll let the user know with a proper message that something is wrong with IAP. task-id: none
A test in the spreadsheet documents module was failing in certain timezones due to improper date handling. The fix adjusts the test date to noon (12PM) to ensure consistent results across different timezone regions. This is a temporary solution until the underlying date library is updated to use a more robust time handling system.
Original PR description
The test `list with a contextual domain` was failing on some timezone because the date isn't well patched. We cannot correctly patch the date at the moment, because PyDate doesn't use luxon but new Date(). Fix the issue by setting the date to 12PM, so the test will work in most timezones. We should properly fix the issue once PyDate make the switch to luxon.