Thursday, October 10, 2024
103 changes
Enhancements to existing features
This update tightens the spacing in the inventory overview screens, making dashboard information fit more compactly on the page. It helps users see more stock-related information at once without changing workflows or business logic.
Original PR description
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
Resolved issues and error corrections
This fixes internal website test scripts so they continue to work after a recent change removed an older text-matching method. It helps keep automated checks reliable without changing what users see in the product.
Original PR description
This PR replaces the uses of ":text" by ":contains", following the recent changes that removed the ":text" pseudo-class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The error occurred when the user was going to check in but didn't find any employee. Steps to reproduce: - Install ``hr_attendance`` module(without demo) - Employees > click on employee and remove ``Related User`` in ``HR Settings`` - Click on the ``systray`` button and ``Check-in`` Traceback: ``Expected singleton: hr.employee()`` The error occurred at [1] because we couldn't find an employee. This commit resolves the above error by disabling the button if there is no employee.
Original PR description
The error occurred when the user was going to check in but didn't find any employee. Steps to reproduce: - Install ``hr_attendance`` module(without demo) - Employees > click on employee and remove ``Related User`` in ``HR Settings`` - Click on the ``systray`` button and ``Check-in`` Traceback: ``Expected singleton: hr.employee()`` The error occurred at [1] because we couldn't find an employee. This commit resolves the above error by disabling the button if there is no employee. [1]- https://github.com/odoo/odoo/blob/b05e203aa8f6956d5bc6606d7df53d74442d727a/addons/hr_attendance/controllers/main.py#L164 sentry-5616192792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173829
The color picker now displays RGBA color values with proper spacing between the blue and alpha values. This small formatting fix makes color information easier for users to read and understand.
Original PR description
Before this commit, the value of the RGBA in the colorpicker display was missing a spacing after the value for blue. This commit add the spacing after this value to make the text more readable by the user. task-4242209
This fixes an issue where generated dates could be distributed incorrectly when a very large number of values was requested. The change improves the reliability of Odoo's internal data generation tools, reducing the risk of skewed or missing test data.
Original PR description
Before this commit `total_days/factor` could return 0 because PG truncates integer division. Casting total_days to a float and moving the floor's position fixes this issue, providing a correct date spread for `factors > (MAX_DATETIME-MIN_DATETIME).days` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale payment method settings now clear terminal-specific values when a user switches the integration type away from terminal payments. This prevents hidden or outdated terminal fields from blocking users from saving payment method changes.
Original PR description
[FIX] point_of_sale: ensure values are cleared when switching away from terminal payment method Problem: After a terminal provider is selected in "Integrate with" option, if the user change "Integration" option away from 'Terminal', the fields from terminal are still visible and getting validate. This makes record's changes cannot be saved if the fields are empty. Steps to Reproduce: 1. Install Point of Sale app. 2. Go to Configuration > Settings. Enable any "Payment Terminals". 3. Go to Configuration > Payment Methods. Click new or edit a record. 4. Select a journal 5. Select an "Integration" option "Terminal" 6. Select a terminal in "Integrate with" option 7. Switch an "Integration" option to None 8. Observe that the added fields does not disappear and is still getting validate when you save the record. Move from #182548: renaming branch --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Selected avatar tags now appear in bold within the dropdown list, making current choices clearer at a glance. This small visual fix helps users avoid confusion when reviewing or changing tag selections.
Original PR description
opw-4212924
The project burndown chart was adjusted to avoid an incorrect translation call. This reduces the risk of display or localization issues while keeping the chart behavior unchanged for users.
Original PR description
This PR removes a call to _t with a dynamic argument.
Merging accounts now keeps the translated account names from the accounts being combined. This prevents translated names, such as customer-facing labels in different languages, from being lost during account cleanup.
Original PR description
At the moment, when we merge accounts, we don't merge the account name's translations. This is a bit annoying since one account might have been called 'Account Receivable' in English, and another one might have been called 'Clientes' in Spanish. At the moment, the translations of the other accounts are lost. This commit makes us merge the translations when merging the accounts. taskid: 4210775
Repair order status badges now use distinct colors that better match each order state. This makes it easier for users to quickly identify whether a repair is draft, confirmed, under repair, done, or cancelled in list views.
Original PR description
Before: In list view, repair orders state badge is green when the state is 'done'. Otherwise, it is always blue. After: No change for state 'done'. Badge color is more adapted to other states: - blue remain for 'confirmed' - yellow is used for 'under_repair' - white/black is used for 'draft' - red is used for 'cancel' Task 4237694 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes an automated website event ticket sales test run more reliably by checking page elements sooner and waiting for them in the right order. It helps reduce false test failures without changing the customer-facing ticket purchase experience.
Original PR description
Decrease checkDelay to 100ms instead of 750ms by default. Add intermediate steps to ensure elements are in DOM before to continue the tour. Modify steps that are not logicals. 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 country information to HR work entries so country-specific fields and groups display correctly. It helps ensure HR teams see the right payroll or work-entry details based on the employee's country setup.
Original PR description
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
Inventory forecast reports now show formatted help text correctly instead of exposing raw HTML. The Replenishments side panel now starts collapsed, reducing visual clutter and making the screen easier to navigate.
Original PR description
Various v18 bugfixes for MRP before the feature freeze. Current behaviour: 1. HTML help string markup for empty reports don't get parsed in some cases (such as the forecasted inventory report). 2. Replenishments sidepanel is expanded by default. Desired behaviour: 1. HTML help string markup gets parsed for every report view. 2. Replenishments sidepanel is collapsed by default. Task ID: [4154879](https://www.odoo.com/odoo/966/tasks/4154879)
The aim of this commit is to prevent test from failing when the error is coming from a missing CoA. We used this opportunity to add a docstring and a new assert. task-id: None Runbot-build-error: 100531 Forward-Port-Of: odoo/odoo#182571
Original PR description
The aim of this commit is to prevent test from failing when the error is coming from a missing CoA. We used this opportunity to add a docstring and a new assert. task-id: None Runbot-build-error: 100531 Forward-Port-Of: odoo/odoo#182571
Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file Forward-Port-Of: odoo/odoo#182412 Forward-Port-Of: odoo/odoo#181129
Original PR description
Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file Forward-Port-Of: odoo/odoo#182412 Forward-Port-Of: odoo/odoo#181129
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531 Forward-Port-Of: odoo/odoo#182084
Original PR description
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531 Forward-Port-Of: odoo/odoo#182084
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182988 Forward-Port-Of: odoo/odoo#180758
Original PR description
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182988 Forward-Port-Of: odoo/odoo#180758
Steps to reproduce: - Project > New Task > Set 'Deadline' to today - 'Repeat Every' 1 week Until tomorrow - Save > Change task state to 'Done' A recurring task is created with a deadline beyond the limit date, this can be repeated indefinitely. This happens because we check he limit date against today instead of comparing it to the task deadline. This is most likely an artifact of 85e9290711c5376660941122dffb3b335b223091, where we allowed immediate recurring task creation (Which would have
Original PR description
Steps to reproduce: - Project > New Task > Set 'Deadline' to today - 'Repeat Every' 1 week Until tomorrow - Save > Change task state to 'Done' A recurring task is created with a deadline beyond the limit date, this can be repeated indefinitely. This happens because we check he limit date against today instead of comparing it to the task deadline. This is most likely an artifact of 85e9290711c5376660941122dffb3b335b223091, where we allowed immediate recurring task creation (Which would have previously been handled by the CRON at the appropriate date). opw-4210251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183054 Forward-Port-Of: odoo/odoo#182365
Problem: When sub-categories are sorted by ID in the PoS app, the order from the server is lost, which disrupts the intended category hierarchy. The expected behavior is that sub-categories appear immediately next to their parent, while preserving the server-defined order for all child categories. Steps to reproduce: - Create PoS categories with multiple levels of sub-categories. - Sort them in the backend list. - The same order should be preserved in the PoS app. opw-4212470 --- I
Original PR description
Problem: When sub-categories are sorted by ID in the PoS app, the order from the server is lost, which disrupts the intended category hierarchy. The expected behavior is that sub-categories appear immediately next to their parent, while preserving the server-defined order for all child categories. Steps to reproduce: - Create PoS categories with multiple levels of sub-categories. - Sort them in the backend list. - The same order should be preserved in the PoS app. opw-4212470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182268
This commit removes the ":text" pseudo class as it is redundant with ":contains", and is a left-over from the development of Hoot-DOM. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182932
Original PR description
This commit removes the ":text" pseudo class as it is redundant with ":contains", and is a left-over from the development of Hoot-DOM. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182932
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the `/website/demo/snippets` page. - Try to enter in edit mode. -> The system never enters in edit mode. The problem is that the Facebook snippet on this page does not have the `href` data attribute. Due to it, the public widget is started without creating `this.resizeObserver`. When the user tries
Original PR description
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the…
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the `/website/demo/snippets` page. - Try to enter in edit mode. -> The system never enters in edit mode. The problem is that the Facebook snippet on this page does not have the `href` data attribute. Due to it, the public widget is started without creating `this.resizeObserver`. When the user tries to enter in edit mode, the `FacebookPageWidget` public widget is destroyed and the system tries to disconnect `this.resizeObserver`. As it is not defined, the system fails in the `destroy()` method. Steps to reproduce the second bug: - Add an "Image-Text" snippet on the website. - Add a "Text-Image" snippet under the "Image-Text" one. - Save and edit. - Drop a "Facebook" snippet on the "Image-Text" snippet. - Move the "Facebook" snippet on the "Text-Image" snippet. - Click on the undo button. -> Two iframes are on the Facebook snippet. The problem is that since [1], the editor observer is not deactivated when removing the iframe in the `destroy()` method of the `FacebookPageWidget` widget. Finally, this commit also adds back the `frameborder` and `allowTransparency` attributes on the iframe (removed due to [1]) and sets the width and height in the style attribute. Although the `frameborder` and `allowTransparency` attributes are deprecated, this commit adds them back in case a potential customization relies on it. [1]: https://github.com/odoo/odoo/commit/707dd91d1e83342a328e50b5ad38e6ec1064ec25 task-4220972 Forward-Port-Of: odoo/odoo#182899 Forward-Port-Of: odoo/odoo#182134
Before this PR: slides_tour is broken maybe due to some recent changes in tour mechanisms After this PR: Tour is now working properly. Task-4161261 Forward-Port-Of: odoo/odoo#180296
Original PR description
Before this PR: slides_tour is broken maybe due to some recent changes in tour mechanisms After this PR: Tour is now working properly. Task-4161261 Forward-Port-Of: odoo/odoo#180296
When a point of sale has more than one rescue session and the user tries to open the rescue sessions, a traceback will appear. Steps to reproduce the error: - Make 2 or more rescue sessions for one point of sale - Click on the outstanding rescue session Traceback: ``` ValueError: Expected singleton: pos.session(22, 21) File "odoo/http.py", line 2383, in __call__ response = request._serve_db() File "odoo/http.py", line 1913, in _serve_db return self._transactioning(
Original PR description
When a point of sale has more than one rescue session and the user tries to open the rescue sessions, a traceback will appear. Steps to reproduce the error: - Make 2 or more rescue sessions for one…
When a point of sale has more than one rescue session and the user tries to open
the rescue sessions, a traceback will appear.
Steps to reproduce the error:
- Make 2 or more rescue sessions for one point of sale
- Click on the outstanding rescue session
Traceback:
```
ValueError: Expected singleton: pos.session(22, 21)
File "odoo/http.py", line 2383, in __call__
response = request._serve_db()
File "odoo/http.py", line 1913, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1976, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1943, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2187, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 757, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 40, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/point_of_sale/models/pos_config.py", line 669, in open_opened_rescue_session_form
'res_id': self.session_ids.filtered(lambda s: s.state != 'closed' and s.rescue).id,
File "odoo/fields.py", line 5215, in __get__
raise ValueError("Expected singleton: %s" % record)
```
https://github.com/odoo/odoo/blob/7638f1bdd6be52554ac4266291941ef0953edfd9/addons/point_of_sale/models/pos_config.py#L669
Here, ```session_ids``` have multiple records, so when it tries to access the ```id```,
It will lead to the above traceback.
sentry-5916215733
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182352This commit fixes an issue that requires a very specific scenario to be reproduced: Go to Settings > Technical > Server Actions Add a Server Action on the "Contact" model with type "Execute Existing Actions" Add a child action on the "Contact" model and set a domain using the "country" field Save the dialog and save the record. Before this commit, it crashed. Indeed, we generated an update command (1) with a virtualId as record id. This happened because of the ReferenceField that was use
Original PR description
This commit fixes an issue that requires a very specific scenario to be reproduced: Go to Settings > Technical > Server Actions Add a Server Action on the "Contact" model with type "Execute Existing…
This commit fixes an issue that requires a very specific scenario to be reproduced: Go to Settings > Technical > Server Actions Add a Server Action on the "Contact" model with type "Execute Existing Actions" Add a child action on the "Contact" model and set a domain using the "country" field Save the dialog and save the record. Before this commit, it crashed. Indeed, we generated an update command (1) with a virtualId as record id. This happened because of the ReferenceField that was used in the dialog. When the record was saved, it was also reloaded (via web_save), and the `update_related_model_id` field was unset (the business logic unsets it, I don't know why). This field being the `modelField` for the reference field (`resource_ref`), the latter was unset by the ReferenceField (via useRecordObserver), which called record.update. This produced an update command on a record that had been saved meanwhile but was still referenced as a new record (hence the virtual_id). This commit fixes the issue by not reloading the record with web_save, as we're closing the dialog anyway, and that record is loaded for the x2many list view anyway. Moreover, we also ensure that if an update occurs on a record that was initially new but that has been saved meanwhile, the command is associated with the correct resId, not the virtualId. Closes #178541 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#183042 Forward-Port-Of: odoo/odoo#182929
**Steps to reproduce:** - Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice for a Portugese customer: * Customer: [a Portugese customer] * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"] - Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization" - Confirm the invoice - Process the invoice by E-invoicing service: TicketBAI (ES) - Check the generated EDI document *
Original PR description
**Steps to reproduce:** - Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice for a Portugese customer: * Customer: [a Portugese customer] * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"] - Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization" - Confirm the invoice - Process the invoice by E-invoicing service: TicketBAI (ES) - Check the generated EDI document **Issue:** The value of "Causa" in "NoSujeta" section is "RL". It should be "IE" for OSS taxes. opw-4034659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182730 Forward-Port-Of: odoo/odoo#179289