Monday, July 3, 2023
22 changes · master
Enhancements to existing features
Dashboard filters now have more spacing between them, making the dashboard easier to read and use. This small visual improvement reduces crowding and helps users scan filter options more comfortably.
Original PR description
**Description of the issue/feature this PR addresses:** Previously, the global filters on the dashboard appeared crowded. This PR aims to address this issue by increasing the gap between the filters using the CSS `gap` property. **Current behavior before PR:** The global filters on the dashboard appear crowded. **Desired behavior after PR is merged:** The gap between the global filters will increase. Task: [3378155](https://www.odoo.com/web#id=3378155&menu_id=4720&cids=2&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project tasks can no longer be selected as their own parent task. This avoids confusing task hierarchies and helps keep project structures accurate.
Original PR description
Before this commit In the task's form view, the parent field shows the other task and also shows the current task. In this commit, the domain is applied, ensuring that the parent_id is not the same as the current id. As a result, the parent field of the task does not include itself task-3330841
The redirect warning dialog now labels its dismiss button as "Close" instead of "Cancel." This makes the action clearer for users by indicating they are simply closing the message, not cancelling a business operation.
Original PR description
"Cancel" button in the RedirectWarning is renamed to "Close" task-3339621
The Studio tests were updated to reflect clearer wording for filter operators: "in" now appears as "is in" and "not in" as "is not in". This keeps automated checks aligned with the user interface wording and helps maintain reliable quality assurance.
Original PR description
With https://github.com/odoo/odoo/pull/126350, the label of the operator "in" ("not in") is now "is in" (resp. "is not in"). Here we adapt a studio test to that change.Resolved issues and error corrections
This fix improves the reliability of an automated restaurant point of sale test by making sure order deletion is fully completed before the test ends. It helps prevent false failure reports in the validation system without changing the user-facing point of sale behavior.
Original PR description
The pos_restaurant first test (test_01_pos_restaurant) has an assertion that failed due to the fact that the deleteion of an order is not awaited in the frontend. This led to the tour finishing very fast after the orm call and the assertion done just after that. We add steps in this test to see if the orm call has been done propely before ending the tour. Runbot Error: 22613, 22614 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This change simplifies the internal handling of date and time fields so they can react more reliably to upcoming interface updates. It also consolidates duplicate comparison logic, reducing maintenance effort and the risk of inconsistent behavior.
Original PR description
## [REF] web,*: Centralize shallowEqual Before this commit, 2 implementations of a "shallowEqual" function coexisted, one in 'web/core/utils/objects.js' and another in 'web/core/utils/arrays.js'.…
## [REF] web,*: Centralize shallowEqual Before this commit, 2 implementations of a "shallowEqual" function coexisted, one in 'web/core/utils/objects.js' and another in 'web/core/utils/arrays.js'. This commit only keeps the one in objects.js and makes the other simply import and export it as well (easier to maintain while also easier to find for those who want to work with arrays), while also taking an optional comparison function argument in case the comparison needs to be more specific (e.g. compare DateTime objects). ## [REF] web: Make datetime hook independant from props This commit makes the datetime hook independant from the props update mechanism it previously relied on (onWillStart & onWillUpdateProps) to update its internal value. This was an incoming issue as the future relational model will rely on fine-grained reactivity to update the fields rather than updating the model and re-rendering all child components (effectively calling 'onWillUpdateProps'). Now, the hook relies on an internal state that tracks whether the props given by its caller changed from one render to another, which is check at render time (= 'onWillRender'). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
## Current behaviour When creating a new record with a many2many widget, in the modal window, any modification done after record creation (for example clicking on the status bar buttons) aren't being saved once we "Save & Close" the modal window. ## Expected behaviour All changes should be saved, regardless if we clicked the status button that trigger *some* action. ## Steps to reproduce - Install Project - Settings > Sub-tasks or Task Dependencies - In a task on a project, add a subt
Original PR description
## Current behaviour When creating a new record with a many2many widget, in the modal window, any modification done after record creation (for example clicking on the status bar buttons) aren't being…
## Current behaviour When creating a new record with a many2many widget, in the modal window, any modification done after record creation (for example clicking on the status bar buttons) aren't being saved once we "Save & Close" the modal window. ## Expected behaviour All changes should be saved, regardless if we clicked the status button that trigger *some* action. ## Steps to reproduce - Install Project - Settings > Sub-tasks or Task Dependencies - In a task on a project, add a subtask > New - Set the title to "Title 1" > Change the stage > Set the title to "Title 2" > Save & Close - Observe the title of the task is "Title 1", not "Title 2". ## Reason for the problem When we click on a status button, since it can trigger *some* action in the backend, it forces the creation of the record front-end side, which generates a `resId`. Upon saving & closing the modal window, the record is not saved, only it's resId is appended to the list of `many2many` records. ## Fix Before appending the record to the list, we save the record if it's dirty. ## Affected versions - 16.0 - saas-16.1 - saas-16.2 - saas-16.3 - master --- opw-3289908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#125227
Channel names in Discuss suggestions now stay within the available space instead of spilling over the interface. A character limit also helps keep channel names manageable and prevents display issues for users.
Original PR description
Before this commit: The channel name used to overflow in the channel suggestion section and also there was also no limit on the lenght of how long the name of the channel can be. After this commit: The name will not overflow in the channnel suggestion section and the user will also have a certain limit on the length of channel name: Task id: 3366608
This update tidies the payment and Stripe onboarding setup after a previous change. It helps keep the payment configuration flow easier to maintain, with minimal expected impact for users.
This commit allows another module to force a new order when a refund order is done. This is mandatory in certification context. A pos order cannot sell refunded products and new products. To use this feature, the module have to use this function: doNotAllowRefundAndSales() --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#125978 Forward-Port-Of: odoo/odoo#125723
Original PR description
This commit allows another module to force a new order when a refund order is done. This is mandatory in certification context. A pos order cannot sell refunded products and new products. To use this feature, the module have to use this function: doNotAllowRefundAndSales() --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#125978 Forward-Port-Of: odoo/odoo#125723
Description of the issue/feature this PR addresses: Currently, the ZATCA tab is visible on all journals provided the country is Saudi. Visibility should also depend on the journal type (only sales) Current behavior before PR: ZATCA tab on the journals' form view is visible for non-sales journals Desired behavior after PR is merged: ZATCA tab on the journals' form view is visible only for sales journals --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
Description of the issue/feature this PR addresses: Currently, the ZATCA tab is visible on all journals provided the country is Saudi. Visibility should also depend on the journal type (only sales) Current behavior before PR: ZATCA tab on the journals' form view is visible for non-sales journals Desired behavior after PR is merged: ZATCA tab on the journals' form view is visible only for sales journals --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#125781
…most reloads) Before, when you click the Reload button at the chart template in the accounting settings on an already installed CoA that has no changes in the taxes, it will delete the tax mappings in the fiscal positions. Apparently the values['tax_ids'] == [] was interpreted by the ORM as remove all tax mappings instead of do nothing, so we remove the key from the dictionary when there is nothing to change. Description of the issue/feature this PR addresses: Current behavior befor
Original PR description
…most reloads) Before, when you click the Reload button at the chart template in the accounting settings on an already installed CoA that has no changes in the taxes, it will delete the tax mappings in the fiscal positions. Apparently the values['tax_ids'] == [] was interpreted by the ORM as remove all tax mappings instead of do nothing, so we remove the key from the dictionary when there is nothing to change. 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#126830
**Summary** Currently, if you create a credit note/refund and reconcile it directly with a statement line (_without creating a payment_), the credit note/refund ends up in the "reversed" payment state, whereas it should be "paid". **Setup** - Install `account_accountant` **Steps to reproduce** - create a credit note/refund and confirm it - create the corresponding bank statement line - reconcile those two Go back to the credit/refund not, you should see that its payment state
Original PR description
**Summary** Currently, if you create a credit note/refund and reconcile it directly with a statement line (_without creating a payment_), the credit note/refund ends up in the "reversed" payment state, whereas it should be "paid". **Setup** - Install `account_accountant` **Steps to reproduce** - create a credit note/refund and confirm it - create the corresponding bank statement line - reconcile those two Go back to the credit/refund not, you should see that its payment state is "reversed", instead of "paid". opw-3328830 Forward-Port-Of: odoo/odoo#123272
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#126832 Forward-Port-Of: odoo/odoo#123264
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#126832 Forward-Port-Of: odoo/odoo#123264
task-3374783 Forward-Port-Of: odoo/odoo#126881 Forward-Port-Of: odoo/odoo#126776
Original PR description
task-3374783 Forward-Port-Of: odoo/odoo#126881 Forward-Port-Of: odoo/odoo#126776
before this commit, on clicking the sales kanban view, it allows the quick adding from the kanban view and entered value is going to the name field of sale.order model. after this commit, quick adding will be disabled before commit: [sale_quick_add.webm](https://github.com/odoo/odoo/assets/99093808/23812660-0e8b-4630-820d-bca23931519b) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#127055 Forward-Port-Of: odoo
Original PR description
before this commit, on clicking the sales kanban view, it allows the quick adding from the kanban view and entered value is going to the name field of sale.order model. after this commit, quick adding will be disabled before commit: [sale_quick_add.webm](https://github.com/odoo/odoo/assets/99093808/23812660-0e8b-4630-820d-bca23931519b) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#127055 Forward-Port-Of: odoo/odoo#127020
Before this commit, if you have a discount promotion on the order, adding a free product reward would change the discount incorrectly. The problem is that in the `_getDiscountableOnSpecific` function the non-discount rewards weren't excluded from `discountLinesPerReward`. opw-3276337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126927 Forward-Port-Of: odoo/odoo#120635
Original PR description
Before this commit, if you have a discount promotion on the order, adding a free product reward would change the discount incorrectly. The problem is that in the `_getDiscountableOnSpecific` function the non-discount rewards weren't excluded from `discountLinesPerReward`. opw-3276337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126927 Forward-Port-Of: odoo/odoo#120635
*: account,event_sale,fleet,hr_attendance,hr_contract,hr_timesheet, im_livechat,point_of_sale,project When the user tries to delete a record(s) from the reporting views, this traceback will be generated. Steps to produce (Example only): - Settings > Technical > Actions > Window Actions - Search for the Work Entries Analysis. Open it and add a 'tree' as view_mode in that action. - Payroll > Reporting > Work Entries Analysis menu and select the tree view. - Select one or more records
Original PR description
*: account,event_sale,fleet,hr_attendance,hr_contract,hr_timesheet, im_livechat,point_of_sale,project When the user tries to delete a record(s) from the reporting views, this traceback will be…
*: account,event_sale,fleet,hr_attendance,hr_contract,hr_timesheet,
im_livechat,point_of_sale,project
When the user tries to delete a record(s) from the reporting views, this traceback will be generated.
Steps to produce (Example only):
- Settings > Technical > Actions > Window Actions
- Search for the Work Entries Analysis. Open it and add a 'tree' as view_mode in that action.
- Payroll > Reporting > Work Entries Analysis menu and select the tree view.
- Select one or more records and try to delete these records.
Error: A traceback appears: "cannot delete from view "hr_work_entry_report"
Handled the unlink/create access by using their model access of the reporting models. similarly, this issue resolves in other reporting models.
Sentry Traceback:
```
HINT: To enable deleting from the view, provide an INSTEAD OF DELETE trigger or an unconditional ON DELETE DO INSTEAD rule.
File "odoo/http.py", line 2115, in __call__
response = request._serve_db()
File "odoo/http.py", line 1698, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1725, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1922, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 234, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 715, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 28, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 24, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "odoo/models.py", line 3649, in unlink
cr.execute(query, (sub_ids,))
File "odoo/sql_db.py", line 311, in execute
res = self._obj.execute(query, params)
```
Sentry-3975590063
Enterprise: https://github.com/odoo/enterprise/pull/42488
Forward-Port-Of: odoo/odoo#124847A TypeError is thrown when an AST node is passed to `literal_eval` because a string is expected and the object has no len(). Check the type of the expression and make sure it's a string before calling len() on it. Forward-Port-Of: odoo/odoo#126551 Forward-Port-Of: odoo/odoo#126520
Original PR description
A TypeError is thrown when an AST node is passed to `literal_eval` because a string is expected and the object has no len(). Check the type of the expression and make sure it's a string before calling len() on it. Forward-Port-Of: odoo/odoo#126551 Forward-Port-Of: odoo/odoo#126520
*: hr_appraisal,hr_contract_reports,hr_payroll,hr_recruitment_reports,industry_fsm, project_timesheet_forecast,sale_subscription When the user tries to delete a record(s) from the reporting views, this traceback will be generated. Steps to produce (Example only): - Settings > Technical > Actions > Window Actions - Search for the Work Entries Analysis. Open it and add a 'tree' as view_mode in that action. - Payroll > Reporting > Work Entries Analysis menu and select the tree view. -
Original PR description
*: hr_appraisal,hr_contract_reports,hr_payroll,hr_recruitment_reports,industry_fsm, project_timesheet_forecast,sale_subscription When the user tries to delete a record(s) from the reporting views,…
*: hr_appraisal,hr_contract_reports,hr_payroll,hr_recruitment_reports,industry_fsm,
project_timesheet_forecast,sale_subscription
When the user tries to delete a record(s) from the reporting views, this traceback will be generated.
Steps to produce (Example only):
- Settings > Technical > Actions > Window Actions
- Search for the Work Entries Analysis. Open it and add a 'tree' as view_mode in that action.
- Payroll > Reporting > Work Entries Analysis menu and select the tree view.
- Select one or more records and try to delete these records.
Error: A traceback appears: "cannot delete from view "hr_work_entry_report"
Handled the unlink/create/write access by using their model access of the reporting models. similarly, this issue resolves in other reporting models.
Sentry Traceback:
```
HINT: To enable deleting from the view, provide an INSTEAD OF DELETE trigger or an unconditional ON DELETE DO INSTEAD rule.
File "odoo/http.py", line 2115, in __call__
response = request._serve_db()
File "odoo/http.py", line 1698, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1725, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1922, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 234, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 715, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 28, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 24, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "odoo/models.py", line 3649, in unlink
cr.execute(query, (sub_ids,))
File "odoo/sql_db.py", line 311, in execute
res = self._obj.execute(query, params)
```
Sentry-3975590063
Community: https://github.com/odoo/odoo/pull/124847
Forward-Port-Of: odoo/enterprise#42488Ticket en Adhoc: 62246 Task en latam: 1039 **Impacted versions**: 16 **Steps to reproduce**: 1) Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing) and then "l10n_ar_reports" (Argentinean Accounting Reports). 2) Take position on Argentinian company (AR) (Responsable Inscripto) . 3) Create a journal with field "l10n_latam_use_documents" (Use documents) on False and "type" Purchase.  Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing) and…
Ticket en Adhoc: 62246 Task en latam: 1039 **Impacted versions**: 16 **Steps to reproduce**: 1) Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing) and then "l10n_ar_reports" (Argentinean Accounting Reports). 2) Take position on Argentinian company (AR) (Responsable Inscripto) . 3) Create a journal with field "l10n_latam_use_documents" (Use documents) on False and "type" Purchase.  4) Create a vendor bill with journal with field "l10n_latam_use_documents" on False and Confirm.  5) Go to Tax Report (configuration: Tax Type: Purchases, Report: Argentinean VAT book, Options: Posted Entries Only, This Month) and see the invoice created on step 2. But that invoice should not be shown on Tax Report.  **Current behavior**: Invoices with journal with field l10n_latam_use_documents on False are being shown on Tax Report. **Expected behavior**: Invoices with journal with field l10n_latam_use_documents on False not shown on Tax Report. **Video**: https://drive.google.com/file/d/19Z284AEGmuLcAJYTgSKFLBJj-91wi2BT/view Forward-Port-Of: odoo/enterprise#41940
Set up a journal group Go to General Ledger Apply created journal group Error odoo.addons.base.models.ir_qweb.QWebException: Error while render the template TypeError: sequence item 0: expected str instance, NoneType found Template: account_reports.filter_info_template Path: /t/div/div/div[1]/t/t[3]/t Node: <t t-out="\', \'.join(journal_value)"/> opw-3359611 Forward-Port-Of: odoo/enterprise#42501
Original PR description
Set up a journal group Go to General Ledger Apply created journal group Error odoo.addons.base.models.ir_qweb.QWebException: Error while render the template TypeError: sequence item 0: expected str instance, NoneType found Template: account_reports.filter_info_template Path: /t/div/div/div[1]/t/t[3]/t Node: <t t-out="\', \'.join(journal_value)"/> opw-3359611 Forward-Port-Of: odoo/enterprise#42501