Monday, July 11, 2022
16 changes · master
Enhancements to existing features
This update restores clearer reporting for automated test results, making it easier for teams to monitor quality and spot problem areas. It also improves the accuracy of database activity measurements during tests, helping developers investigate performance issues more reliably without affecting end users.
Original PR description
Uses a dedicated logger (for easier filtering / silencing) for results output, and provides rough (module-level) stats in INFO but detailed (test-level) in DEBUG. Also modifies the global query counter (`odoo.sql_db.query_counter`) to update after each query rather than on close: with test cursors the actual underlying counter is only rarely flushed. This allows using the global query count to track query counts using tests, under the assumption that the tests themselves don't run concurrently. This is both much simpler and more precise than trying to find the current test's cursor and messing about with it, especially during the class setup phase.
Account setup was adjusted to avoid a conflict that could interfere with choosing the right account type. This makes creating accounts smoother and reduces the chance of confusing behavior for accounting users.
Original PR description
Needed for task 2888204 _onchange_user_type_id in account_disallowed_expenses overwrites _onchange_user_type_id in account_account. Renaming it to avoid that.
Resolved issues and error corrections
This fixes an internal testing issue in the Accounting app where invoice tests could fail because a required unit-of-measure field was hidden for the test user. The change helps keep accounting invoice validation reliable during module builds without affecting day-to-day user workflows.
Original PR description
For a non well identified reason, the user doesn't have the uom group to see the field during the single module build. This commit adds the group to the user to make it visible during the test as a simple fix.
Code cleanup and technical improvements
Email scheduling now stores scheduled send times using a proper date and time format in mail records and preview screens. This improves consistency and future maintainability while keeping templates flexible where dynamic expressions are still needed.
Original PR description
- Change schedule_date data type from char to Datetime. - The field should accept DateTime format in both models mail_mail and mail_template_preview - The reason for this change is to have more code consistency since storing date in a char format is deprecated. - The model mail_template was excluded and it will be kept as Char for the reason that it needs to support dynamic expressions. - Task id: #2826699 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Problem: Have a pivot view in some state. Toggle a favorite with a context in which a key "pivot_row_groupby" is defined. The pivot view should be grouped (on rows) by that pivot_row_groupby but it is not always the case. The basic problem is that the key "pivot_row_groupby" is never considered after the first load (see method load in pivot_model.js). Solution: We make the search model used by the pivot view send as groupby for the favorite its pivot_row_groupby instead of its groupBy
Original PR description
Problem: Have a pivot view in some state. Toggle a favorite with a context in which a key "pivot_row_groupby" is defined. The pivot view should be grouped (on rows) by that pivot_row_groupby but it is not always the case. The basic problem is that the key "pivot_row_groupby" is never considered after the first load (see method load in pivot_model.js). Solution: We make the search model used by the pivot view send as groupby for the favorite its pivot_row_groupby instead of its groupBy (which can be different). We do something similar for the graph view that presents a similar problem. OPW: 2837428 Forward-Port-Of: odoo/odoo#95633 Forward-Port-Of: odoo/odoo#95105
This fixes display issues in the website editor's media selection window after a recent framework upgrade. Users should see the file selector and media search controls align correctly again, improving the editing experience without changing functionality.
Original PR description
Since BS5 migration [1], `form-inline` and `custom-control` classes are no more available. So we use `row` and `col` instead. Also, we have unwrapped `input-group-append` has it's not more required in BS5. [2] Refs: [1] odoo/odoo#95450 [2] https://getbootstrap.com/docs/5.1/migration/#forms -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the expected text coloring in striped tables after the Bootstrap 5 update. It ensures list views keep their visual cues and remain easy to read for users.
Original PR description
In BS4 text color wasn't defined for `table-striped`. In BS5 color text decorations in list views was broken because of BS5 sets the color of all `td` in a stripped table. Now we simply override the value of the variable to inherit. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoice OCR processing has been restored for users who do not have full accounting feature visibility. This prevents invoice extraction from failing when the system needs to update hidden accounting lines behind the scenes, keeping the OCR workflow working as it did before.
Original PR description
This follows revision odoo/odoo@5ccc32fcf72cbfb6bb077d99a7657416c502aac1 Before the above revision, the invoice OCR extraction was working even for a user which did not have the accounting features…
This follows revision
odoo/odoo@5ccc32fcf72cbfb6bb077d99a7657416c502aac1
Before the above revision,
the invoice OCR extraction was working
even for a user which did not have the
accounting features group
(at least Show Accounting Features - Readonly)
The code is editing the invoice move lines even
if they are invisible, which is not possible
in a real form view.
However, as here the goal is not to test the form view
behavior, we can bypass this invisible mecanism
so the code works as before,
able to edit the move lines even if they are invisible
to the user executing the code.
```
odoo.addons.account_invoice_extract.tests.test_invoice_extract:285
FAIL: TestInvoiceExtract.test_multi_currency
Traceback (most recent call last):
File "/data/build/enterprise/account_invoice_extract/tests/test_invoice_extract.py", line 285, in test_multi_currency
invoice.with_user(test_user)._check_status()
File "/data/build/enterprise/account_invoice_extract/models/account_invoice.py", line 737, in _check_status
self._save_form(ocr_results)
File "/data/build/enterprise/account_invoice_extract/models/account_invoice.py", line 869, in _save_form
with move_form.line_ids.edit(i) as line:
File "/data/build/odoo/odoo/tests/common.py", line 2619, in edit
self._assert_editable()
File "/data/build/odoo/odoo/tests/common.py", line 2540, in _assert_editable
assert not self._parent._get_modifier(self._field, 'invisible'),\
AssertionError: field line_ids is not visible
```The payroll dashboard display has been adjusted so batch payslip counts stay on one line and notes have clearer spacing. This improves readability and keeps the dashboard looking consistent after the interface framework update.
Original PR description
task-2908993
The interviewer field was added by #78622, and adds access control for `hr.applicant` based on whoever was assigned as the interviewer. Due to the access control implications, it's useful to track the value of this field in the applicant history. Forward-Port-Of: odoo/odoo#95395
Original PR description
The interviewer field was added by #78622, and adds access control for `hr.applicant` based on whoever was assigned as the interviewer. Due to the access control implications, it's useful to track the value of this field in the applicant history. Forward-Port-Of: odoo/odoo#95395
Reproduction: 1. Install recruitment 2. Create a new job position with an extra-long title 3. Save and the title of this record is exceed the kanban card Reason: CSS style doesn’t take account of long title Fix: Backported the overflow changes in V15 and added o_text_overflow to the title of the job's kanban view, so the title does not exceed the border of the kanban card opw-2849601 overflow change in V15: https://github.com/odoo/odoo/commit/a0ebb4609848a65f9b6a14a94030ad3144a
Original PR description
Reproduction: 1. Install recruitment 2. Create a new job position with an extra-long title 3. Save and the title of this record is exceed the kanban card Reason: CSS style doesn’t take account of long title Fix: Backported the overflow changes in V15 and added o_text_overflow to the title of the job's kanban view, so the title does not exceed the border of the kanban card opw-2849601 overflow change in V15: https://github.com/odoo/odoo/commit/a0ebb4609848a65f9b6a14a94030ad3144a95038 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#95525 Forward-Port-Of: odoo/odoo#91757
When iot switch between 2 version of odoo we must clean correctly the branch. Now -dfx erases each and every file in git directory which is not part of repository. (like drivers and interfaces) 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#95659
Original PR description
When iot switch between 2 version of odoo we must clean correctly the branch. Now -dfx erases each and every file in git directory which is not part of repository. (like drivers and interfaces) 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#95659
Steps to follow: - Go to a crm.lead - Schedule an activity - Click on edit - Click on mark as done in the popup - Move the lead to a new stage -> A missing record error is displayed for the activity Cause of the issue: Once the activity has been mark as done (deleted), The crm.lead record is not updated. The old activity is then passed to the server where an error is thrown Solution: Update the main view after editing an activity opw-2878984 Forward-
Original PR description
Steps to follow: - Go to a crm.lead - Schedule an activity - Click on edit - Click on mark as done in the popup - Move the lead to a new stage -> A missing record error is displayed for the activity Cause of the issue: Once the activity has been mark as done (deleted), The crm.lead record is not updated. The old activity is then passed to the server where an error is thrown Solution: Update the main view after editing an activity opw-2878984 Forward-Port-Of: odoo/odoo#95399 Forward-Port-Of: odoo/odoo#94877
**Description of the issue/feature this PR addresses:** Steps to reproduce (tested in v14, but I suppose also happens in v13 because the code is the same): - Delivery module is installed. - User_1 is stock_manager and sale_manager. - User_1 creates sale_order and confirms it. Automatically is created a picking P. - User_2 is stock user/manager but doesn't have sale rights. - User_2 open picking P and validates it. => Error: cannot validate due to access rules. : - Delivery module is installed. - User_1 is…
**Description of the issue/feature this PR addresses:** Steps to reproduce (tested in v14, but I suppose also happens in v13 because the code is the same): - Delivery module is installed. - User_1 is stock_manager and sale_manager. - User_1 creates sale_order and confirms it. Automatically is created a picking P. - User_2 is stock user/manager but doesn't have sale rights. - User_2 open picking P and validates it. => Error: cannot validate due to access rules.  The problem is due because at some point, it tries to read the linked sale order. See the debug process: - at the end of button_validate() of stock.picking (module stock):  -at the end of _action_done() of stock.picking (module stock):  - in _send_confirmation_email() method of stock.picking (module delivery):  - in send_to_shipper() of stock.picking (module delivery):  - in _compute_amount_total_without_delivery() of sale.order (module delivery):  It's in that place, when doing `self.order_line`, that a read access error is produced. **Current behavior before PR:** Stock user without sale rights cannot validate a picking coming from a sale order. **Desired behavior after PR is merged:** Stock user without sale rights can validate a picking coming from a sale order. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93468 Forward-Port-Of: odoo/odoo#92870
When in multilocalization using latam countries: - The credit note wizard is always showing the Peruvian field "Credit Reason" (l10n_pe_edi_refund_reason). - The debit note wizard is always showing the Peruvian field "Debit Reason" (l10n_pe_edi_charge_reason). The solution is to hide peruvian field in the wizard when creating a credit note or debit note in another country other than Peru. Forward-Port-Of: odoo/enterprise#29009
Original PR description
When in multilocalization using latam countries: - The credit note wizard is always showing the Peruvian field "Credit Reason" (l10n_pe_edi_refund_reason). - The debit note wizard is always showing the Peruvian field "Debit Reason" (l10n_pe_edi_charge_reason). The solution is to hide peruvian field in the wizard when creating a credit note or debit note in another country other than Peru. Forward-Port-Of: odoo/enterprise#29009
Before this commit, the views were not properly defined on the action and a traceback occured: UncaughtPromiseError > TypeError Uncaught Promise > action.views is not iterable TypeError: action.views is not iterable at _preprocessAction (https://15784459-master-all.runbot63.odoo.com/web/assets/2060-69cbe8d/web.assets_backend.min.js:2291:67) at Object.doAction (https://15784459-master-all.runbot63.odoo.com/web/assets/2060-69cbe8d/web.assets_backend.min.js:2366:170)
Original PR description
Before this commit, the views were not properly defined on the action and
a traceback occured:
UncaughtPromiseError > TypeError
Uncaught Promise > action.views is not iterable
TypeError: action.views is not iterable
at _preprocessAction (https://15784459-master-all.runbot63.odoo.com/web/assets/2060-69cbe8d/web.assets_backend.min.js:2291:67)
at Object.doAction (https://15784459-master-all.runbot63.odoo.com/web/assets/2060-69cbe8d/web.assets_backend.min.js:2366:170)
taskid: 2860773
Forward-Port-Of: odoo/enterprise#27661