Monday, December 18, 2023
26 changes · 17.0
Resolved issues and error corrections
The accounting onboarding tour now shows a more relevant instruction when users reach the invoice confirmation step. This helps users understand that they should confirm the invoice once it is ready, reducing confusion during setup or training.
Original PR description
Problem --------- In the accounting tour, during the invoice creating step, the message asking to confirm the invoice was irrelevant. Landed in 17.0 with this commit:cc6f85af2aac31816b51a0b39c9b119049f9954f Objective --------- Change the message into "Once your invoice is ready, confirm it." Solution --------- Change the relevant message in the tour JS file. task-3619638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how website editor buttons behave when users duplicate a button or insert one between existing buttons. The copied or newly placed button now preserves the expected nearby styling, reducing unexpected design changes while editing pages.
Original PR description
[FIX] website: fix button snippet The commit [1] of this PR [2] has been merged requesting some changes to be made later, which are fixes to the button that can now be dropped onto the page from the…
[FIX] website: fix button snippet The commit [1] of this PR [2] has been merged requesting some changes to be made later, which are fixes to the button that can now be dropped onto the page from the snippet menu. This commit makes the following changes requested: - Before this commit, when we duplicated a button (by clicking on the "duplicate" button), the style of the new button was generated again in Javascript in the "_adaptButtons" function even though it is not necessary since we duplicate the HTML of the copied button. That is why this commit adds the "adaptAppearance" parameter for the "_adaptButtons" function. - Prior to this commit, when a button was dropped between two buttons, the style of the next button was copied as a priority. After this commit , the style of the previous button is now copied as a priority. [1]: https://github.com/odoo/odoo/commit/507b80a12574ce19bcb925d88868fb377b1c4b06 [2]: https://github.com/odoo/odoo/pull/126717 task-3555413
This update corrects how visibility rules are applied in the Public Holidays view. It helps ensure users see the right fields at the right time when managing time off and public holiday settings.
Original PR description
This attribute was not correctly updated with the big attribute revamp. This commit fixes that.
The mail app now avoids an inefficient lookup step when finding message-related records. This should make the experience slightly faster and smoother in areas that rely on mail records, without changing user-facing behavior.
Original PR description
This is a slow process that is better avoided.
The automated Sales Planning walkthrough was adjusted so it no longer keeps the "Shifts planned" filter active. This prevents inherited planning steps from failing and helps ensure the guided test flow remains reliable.
Original PR description
The fact that we let the filter causes issues in sale_planning, where the tour is inheritted.
This update corrects a display issue in financial reports for companies using the Anglo-Saxon accounting method. Previously, totals were automatically shown below sections by default. This change ensures that totals are only displayed when specifically requested, aligning with the requirements of the Anglo-Saxon accounting standard.
Original PR description
`totals_below_sections` should not be `True` by default if the company uses `anglo_saxon_accounting`. task-3612866
A merge conflict was incorrectly resolved during a code update, which accidentally changed the default currency exchange rate provider for India. This fix restores xe.com as the default provider for India, ensuring users in that region get the correct currency conversion service they expect.
Original PR description
During the forward-port of [1] to 17.0 [2], I resolved a merge conflict in the `res_config_settings.py` file incorrectly, which made it so that xe.com is not the default provider for India anymore (like in previous versions). This change fixes that and makes it again the default provider for India. [1] 24012f9db268a7722275a508374498bb18bbebdc [2] 40d62fb3ce62a22e455ec98f2fe692286138786e
Documentation and clarification updates
This pull request records that contributor vivekpabari1894 has signed Odoo's Contributor License Agreement. It supports legal compliance for accepting contributions and has no direct impact on product features or users.
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
Miscellaneous changes
This pull request appears to make a small update to the repository documentation, based on the README file being changed. No product behavior or customer-facing Odoo functionality is described, so the business impact is expected to be minimal.
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
The `test_01_multi_domain_assets_generation` was introduced in PR [1]. But afterward, the commit [2] introduced a unique constraint on the `domain` field. With this additional constraint, this test broke when run with multiple existing websites as it assigns the same domain for each of them. This commit made the dummy domain assigned in this test non-unique, which doesn't alter the original meaning of the test but, allows to run it with multiple existing websites. [1]: https://github
Original PR description
The `test_01_multi_domain_assets_generation` was introduced in PR [1]. But afterward, the commit [2] introduced a unique constraint on the `domain` field. With this additional constraint, this test broke when run with multiple existing websites as it assigns the same domain for each of them. This commit made the dummy domain assigned in this test non-unique, which doesn't alter the original meaning of the test but, allows to run it with multiple existing websites. [1]: https://github.com/odoo/odoo/pull/118526 [2]: https://github.com/odoo/odoo/commit/507db4e179514d171ec82e8ea0cbaf2323a6c30d runbot-20848 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145370
4424 VAT to be recovered should be liability_current. 4426 VAT deductible should be asset_current. 4427 VAT collected should be liability_current. Enterprise PR: https://github.com/odoo/enterprise/pull/52603 taskid: 3634044 Forward-Port-Of: odoo/odoo#146368 Forward-Port-Of: odoo/odoo#145947
Original PR description
4424 VAT to be recovered should be liability_current. 4426 VAT deductible should be asset_current. 4427 VAT collected should be liability_current. Enterprise PR: https://github.com/odoo/enterprise/pull/52603 taskid: 3634044 Forward-Port-Of: odoo/odoo#146368 Forward-Port-Of: odoo/odoo#145947
Before this commit, columns in list views could be manually resized only if there were records in the table. For the ungrouped case it makes sense, as the table is empty anyway. However, for the grouped case (either with empty groups, or with all groups being folded), the list contains no records, but resizing could make sense as there could be aggregate values displayed on group headers. Technically speaking, there's no reason to restrict the resize feature if the table is empty. Functionall
Original PR description
Before this commit, columns in list views could be manually resized only if there were records in the table. For the ungrouped case it makes sense, as the table is empty anyway. However, for the…
Before this commit, columns in list views could be manually resized only if there were records in the table. For the ungrouped case it makes sense, as the table is empty anyway. However, for the grouped case (either with empty groups, or with all groups being folded), the list contains no records, but resizing could make sense as there could be aggregate values displayed on group headers. Technically speaking, there's no reason to restrict the resize feature if the table is empty. Functionally wise, a user could get confused if the feature is sometimes available, and sometimes not. For that reason, this commit simply removes the isEmpty condition, meaning that resizing columns is now always available, even if the table is empty. Task 3621490 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#144767
After the previous fix introducing a deepcopy, the pregenerate of the assets became slower because of the many call to get_manifest (in loop, recursively) Since the manifest is immutable here and won't go outside of the call, we can use the lower level version. Forward-Port-Of: odoo/odoo#145965 Forward-Port-Of: odoo/odoo#144723
Original PR description
After the previous fix introducing a deepcopy, the pregenerate of the assets became slower because of the many call to get_manifest (in loop, recursively) Since the manifest is immutable here and won't go outside of the call, we can use the lower level version. Forward-Port-Of: odoo/odoo#145965 Forward-Port-Of: odoo/odoo#144723
On device which are primarily recognized as "touch", when using a mouse-like pointer, the tooltip can't be opened both on "touch" and on "hover" (withe the mouse). This commit fixes it by removing the escaping that prevented the mouse events' listeners from being registered on touch-enabled devices. Steps to reproduce: 1. Using Chrome, open the developer tools and click on "Toggle device toolbar" 2. Install Contacts 3. Go to Contacts and open the form view of any contact 4. Now
Original PR description
On device which are primarily recognized as "touch", when using a mouse-like pointer, the tooltip can't be opened both on "touch" and on "hover" (withe the mouse). This commit fixes it by removing the escaping that prevented the mouse events' listeners from being registered on touch-enabled devices. Steps to reproduce: 1. Using Chrome, open the developer tools and click on "Toggle device toolbar" 2. Install Contacts 3. Go to Contacts and open the form view of any contact 4. Now click again on "Toggle device toolbar" to disable it but do not reload the page: touch device capabilities will be loaded but you will be able to use a mouse 5. Click on the question mark next to "Tax ID", nothing happens opw-3493571 Forward-Port-Of: odoo/odoo#140263
### Summary Currently, when you send an invoice, every recipient receives the link including the access token. Only the invoice's customer and manually added recipients should receive the token. ### Steps to reproduce * Create and validate an invoice * Add a follower `F `to the invoice * Click on the Send & Print button, then add a recipient `R` who is not the customer associated with the invoice * Proceed to send the invoice. * Access the emails that were sent * Using an incogn
Original PR description
### Summary Currently, when you send an invoice, every recipient receives the link including the access token. Only the invoice's customer and manually added recipients should receive the token. ###…
### Summary Currently, when you send an invoice, every recipient receives the link including the access token. Only the invoice's customer and manually added recipients should receive the token. ### Steps to reproduce * Create and validate an invoice * Add a follower `F `to the invoice * Click on the Send & Print button, then add a recipient `R` who is not the customer associated with the invoice * Proceed to send the invoice. * Access the emails that were sent * Using an incognito or private browsing window, open the `View Invoice` link for each of the 3 recipients. You should see that all the links give access to the invoice. What should happen is that only partner `R` and the invoice's customer should haveaccess to the invoice. `F` should be asked to login. ### Cause Issue was introduced by https://github.com/odoo/odoo/commit/95c585f67bd37e1202c57b3e9eed09b0a964472c ### Fix Add a new notification group for partners that were manually added as recipients, and give that group access to the invoice. opw-3385302 Forward-Port-Of: odoo/odoo#146496 Forward-Port-Of: odoo/odoo#142473
This traceback arises when the user tries to click on 'Lot/ serial Number' in Create Move Line To reproduce this issue: 1. install `stock` 2. Open `inventory>products>Lots/Serial Numbers` 3. create a product `A` in the current serial number 4. Try to save the record `operations>transfers>deliveries` 5. Create a new record in current product `A` try to save the record and click on `Mark as Todo` 6. In the stock picking view open stock move 7. Add a line from the current produc
Original PR description
This traceback arises when the user tries to click on 'Lot/ serial Number' in Create Move Line To reproduce this issue: 1. install `stock` 2. Open `inventory>products>Lots/Serial Numbers` 3. create a…
This traceback arises when the user tries to click on 'Lot/ serial Number' in Create Move Line
To reproduce this issue:
1. install `stock`
2. Open `inventory>products>Lots/Serial Numbers`
3. create a product `A` in the current serial number
4. Try to save the record `operations>transfers>deliveries`
5. Create a new record in current product `A` try to save the record and click
on `Mark as Todo`
6. In the stock picking view open stock move
7. Add a line from the current product `A`
8. Click on new and give the value of `Lot/serial Number` in Create Move Line
ValueError:
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5830, in ensure_one
_id, = self._ids
ValueError: Expected singleton: stock.quant(5, 24)
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 "addons/web/models/models.py", line 1062, in onchange
record._apply_onchange_methods(field_name, result)
File "odoo/models.py", line 6884, in _apply_onchange_methods
res = method(self)
File "addons/stock/models/stock_quant.py", line 920, in _onchange_location_or_product_id
self.quantity = quant.filtered(lambda q: q.lot_id == self.lot_id).quantity
File "odoo/fields.py", line 1147, in __get__
record.ensure_one()
File "odoo/models.py", line 5833, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
when the user tries to click on 'Lot/serial Number' in Create Move Line
a value error occurs because getting many values excepted single value
Which leads to the traceback from here
https://github.com/odoo/odoo/blob/230b680bf92583c9f5e4a3739be1d8602df44331/addons/stock/models/stock_quant.py#L905-L929
After applying this commit will resolve the issue of getting a sum of quantity mapped with the quant
sentry-4715604118
Forward-Port-Of: odoo/odoo#146152### After this PR You can override _prepare_move_line_finished_write_vals to add other value to write on move line vals before the post iventory Use case examples: - You want to update the owner by custom logic after the produce - You want to put a result_package_id to put_in_pack at the same time you produce (i need the prepare because i'm in this situation) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144340
Original PR description
### After this PR You can override _prepare_move_line_finished_write_vals to add other value to write on move line vals before the post iventory Use case examples: - You want to update the owner by custom logic after the produce - You want to put a result_package_id to put_in_pack at the same time you produce (i need the prepare because i'm in this situation) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144340 Forward-Port-Of: odoo/odoo#139420
**Steps to reproduce:** - open kanban view of department from employee module. - click on 'Allocation Requests' and 'Time Off Requests'. --- **Issue:** - When viewing the department's allocation and time-off requests in the employee module, all department data is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate
Original PR description
**Steps to reproduce:** - open kanban view of department from employee module. - click on 'Allocation Requests' and 'Time Off Requests'. --- **Issue:** - When viewing the department's allocation and time-off requests in the employee module, all department data is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate department-specific request information. Task-3541358 Forward-Port-Of: odoo/odoo#145334 Forward-Port-Of: odoo/odoo#138992
Steps to reproduce: ------------------- - in a second company, giving leave to an employee; - go to reporting in Time Off app; - remove all filters. Issue: ------ We see leaves of the other company's employees. Cause: ------ The global rule which allows a domain to be added to manage the multi-company case on the `hr.leave` model takes account the company of the type of leave. Solution: --------- As types of leave can be shared between different companies, it is also necessary
Original PR description
Steps to reproduce: ------------------- - in a second company, giving leave to an employee; - go to reporting in Time Off app; - remove all filters. Issue: ------ We see leaves of the other company's employees. Cause: ------ The global rule which allows a domain to be added to manage the multi-company case on the `hr.leave` model takes account the company of the type of leave. Solution: --------- As types of leave can be shared between different companies, it is also necessary to filter on the employee's company. In fact, even a time off administrator is not supposed to see the holidays of employees in companies that are not activated for him. opw-3594737 Forward-Port-Of: odoo/odoo#142665
This commit ensures the production backorder moves are created in draft state. When the default state was 'confirmed', splitting a manufacturing order in draft, will create mo in draft with finished product already in confirm state. the `_compute_move_finished_ids()` method will try to delete a confirmed move and thus raise a UserError Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have sign
Original PR description
This commit ensures the production backorder moves are created in draft state. When the default state was 'confirmed', splitting a manufacturing order in draft, will create mo in draft with finished product already in confirm state. the `_compute_move_finished_ids()` method will try to delete a confirmed move and thus raise a UserError 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#146355
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#146314
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 Forward-Port-Of: odoo/odoo#146314
Steps ===== - Install module project - Open the form view of a project - Add an end date (x)OR a start date - Click anywhere on the page to remove the focus from the date picker Issue ===== The chosen date disappeared without any explanation to the user Cause ===== https://github.com/odoo/odoo/pull/123268 introduced some changes related to the planned dates of projects. 1. the write method is modified to avoid the write of only a start/end date (both date should be set or none of
Original PR description
Steps ===== - Install module project - Open the form view of a project - Add an end date (x)OR a start date - Click anywhere on the page to remove the focus from the date picker Issue ===== The…
Steps ===== - Install module project - Open the form view of a project - Add an end date (x)OR a start date - Click anywhere on the page to remove the focus from the date picker Issue ===== The chosen date disappeared without any explanation to the user Cause ===== https://github.com/odoo/odoo/pull/123268 introduced some changes related to the planned dates of projects. 1. the write method is modified to avoid the write of only a start/end date (both date should be set or none of them) 2. a required is added on the start date field in the form view of project 3. an onchange is added to avoid to have one of both field set and not the other This last change is problematic as it overrides the required behavior of the date fields. Fix === The onchange being only useful in form view, it is deprecated as the required attribute is sufficient for this use case and provide the user warnings if he forget a field. On top of that a required attribute is also set on the end date field. task-3628069 Forward-Port-Of: odoo/odoo#145158
Since [1] when website was moved to backend, with the introduction of the iframe, the preset previews are replicating the CSS of the page. In [2] the mechanism was adapted to make it faster, but in the new replication the `border-color` of buttons was wrongly copied from the `background-color` of the buttons. This commit uses the right variable instead. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b [2]: https://github.com/odoo/odoo/commit/7f5a9d04034804
Original PR description
Since [1] when website was moved to backend, with the introduction of the iframe, the preset previews are replicating the CSS of the page. In [2] the mechanism was adapted to make it faster, but in the new replication the `border-color` of buttons was wrongly copied from the `background-color` of the buttons. This commit uses the right variable instead. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b [2]: https://github.com/odoo/odoo/commit/7f5a9d040348048990b25c271875c77d2c314e4d task-3642550 Forward-Port-Of: odoo/odoo#146510
This commit fixes 2 issues with the domain in field tooltips, in debug mode. 1) it only displayed the domain defined on the field in the model, not the domain set in attrs in the view, if any. 2) when the domain was the empty array, `domain: ` was displayed. opw 3455119 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/sub
Original PR description
This commit fixes 2 issues with the domain in field tooltips, in debug mode. 1) it only displayed the domain defined on the field in the model, not the domain set in attrs in the view, if any. 2) when the domain was the empty array, `domain: ` was displayed. opw 3455119 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#146488 Forward-Port-Of: odoo/odoo#146443
Before this PR: Since the record marked as archived, the allowed_records does not stores that particular record which ultimately results in lost activites. After this PR: Activities made on the archived record are allowed and shown in the system-tray activity menu. task-3458597 Forward-Port-Of: odoo/odoo#138783
Original PR description
Before this PR: Since the record marked as archived, the allowed_records does not stores that particular record which ultimately results in lost activites. After this PR: Activities made on the archived record are allowed and shown in the system-tray activity menu. task-3458597 Forward-Port-Of: odoo/odoo#138783
Forward-Port-Of: odoo/enterprise#52788
Original PR description
Forward-Port-Of: odoo/enterprise#52788