Monday, September 4, 2023
21 changes
Enhancements to existing features
This update lets the mail enterprise push notification component continue working on Ubuntu 20.04 systems that use an older approved cryptography package. It avoids forcing some internal systems to upgrade the operating system or install non-standard packages just to receive this module update.
Original PR description
A few internal systems are still running ubuntu 20.04 (focal) which ships with cryptography 2.8. The `backend` parameter was made optional (automatically falling back to the default backend) [in 3.1]. Provide a backend explicitly so the module can be updated without needing to upgrade the system (or install a non-distro package). [in 3.1]: https://cryptography.io/en/3.4.2/changelog.html#v3-1
The system’s date and time library was updated to a newer version, with related adjustments in scheduling and timer areas. This helps keep the platform current and reduces the risk of issues from outdated internal components, without introducing a major visible change for users.
Original PR description
This commit contains adaptations regarding this change. See community counterpart.
Resolved issues and error corrections
Code cleanup and technical improvements
This update refines internal automated tests across several Odoo Enterprise areas by replacing a slower waiting method with a more meaningful check. It should help keep test runs faster and more dependable without changing customer-facing functionality.
Original PR description
\* = account_online_synchronization, test_mail_enterprise, voip, web_studio Follow up of https://github.com/odoo/odoo/pull/130451 `contains` is faster and functionally more significant. https://github.com/odoo/odoo/pull/134025
Miscellaneous changes
Step: - Install contract app - Create user with payroll manger access and None Employees - Login with new user and create contract - Click on employee field and click on Search More Issue: When the user does not have access to the employee app and the search dialog accesses the employee during search more, so the traceback come. Fix: If the user does not have access to the Employee application, public employee will be used in the search more dialog. task-3366443 Forw
Original PR description
Step:
- Install contract app
- Create user with payroll manger access and None Employees - Login with new user and create contract - Click on employee field and click on Search More Issue: When the user does not have access to the employee app and the search dialog accesses the employee during search more, so the traceback come.
Fix: If the user does not have access to the Employee application, public employee will be used in the search more dialog.
task-3366443
Forward-Port-Of: odoo/enterprise#46661
Forward-Port-Of: odoo/enterprise#44774This fix updates automated walkthrough tests so their final steps no longer trigger unnecessary warning messages. It improves test reliability and reduces noise for teams maintaining quality across multiple Odoo apps, without changing day-to-day product behavior.
Original PR description
When we haven't provided a custom action, the tour step runs the default action. In the final step of the tour, when there is no `run` or `isCheck` provided, It shows warnings of 'ignoring action (auto) of last step' as it can lead to a race condition. This commit resolves the warnings: `ignoring action (auto) of last step` task-3429500 PR Community: https://github.com/odoo/odoo/pull/129239
This fixes a small naming issue in the Sign app by using the correct search action wording. It helps keep the signing template interface consistent and avoids confusion for users working with custom sign items.
The update fixes a validation rule for disallowed expense category codes that was not being applied in some cases. This helps prevent duplicate or incorrect category codes and improves consistency across companies.
Original PR description
This commit is a complement to this PR : https://github.com/odoo/enterprise/pull/46505 We are simply fixing the constraint that was never triggered since `company_id` is not required and has no default value. So we decided to make the constraint global instead of company dependent. opw-3463858
…maining_value and asset_depreciated_value Steps to reproduce the bug: - Create an automated action AA on model account.move triggered on creation & update - Create an asset model AM with method "straight line", duration 200 months and a fixed asset account FAA - Edit FAA and enable allow reconciliation and set automate asset with create in draft - Create a vendor bill VB with one line set with FAA as account and 5000€ as unit price - Confirm VB, an asset A will be automatically gener
Original PR description
…maining_value and asset_depreciated_value Steps to reproduce the bug: - Create an automated action AA on model account.move triggered on creation & update - Create an asset model AM with method…
…maining_value and asset_depreciated_value Steps to reproduce the bug: - Create an automated action AA on model account.move triggered on creation & update - Create an asset model AM with method "straight line", duration 200 months and a fixed asset account FAA - Edit FAA and enable allow reconciliation and set automate asset with create in draft - Create a vendor bill VB with one line set with FAA as account and 5000€ as unit price - Confirm VB, an asset A will be automatically generated - Go to A, set AM as asset model and confirm Bug: RecursionError: maximum recursion depth exceeded while calling a Python object From the traceback, we noticed that: - the base automation reads the field asset_remaining_value; - because the field is not in cache, the compute method of this field is invoked; - it assigns a new field asset_depreciated_value to compute on a record that is not part of 'self'; - as this unexpected assignment is not part of the computation, it triggers an call to write() (the assignments that are part of the computation do not invoke write); - the call to write() triggers the base automation; - go back to the first step, opw:3422406 Forward-Port-Of: odoo/enterprise#46382 Forward-Port-Of: odoo/enterprise#45344
…isabled https://github.com/odoo/enterprise/pull/39890 introduced an auto-ordering feature when sending sign requests. However, it will set an order even if the set_sign_order is disabled. This commit fixes that and adds tests to prevent this feature from breaking in the future. task-3420937 Forward-Port-Of: odoo/enterprise#43956
Original PR description
…isabled https://github.com/odoo/enterprise/pull/39890 introduced an auto-ordering feature when sending sign requests. However, it will set an order even if the set_sign_order is disabled. This commit fixes that and adds tests to prevent this feature from breaking in the future. task-3420937 Forward-Port-Of: odoo/enterprise#43956
Current behavior: Kitchen preparation display would always show all the orders from all the PoS. This happens because here (https://github.com/odoo/enterprise/blob/saas-16.2/pos_preparation_display/models/preparation_display_order.py#L123) we get all the orders that do not have a `pos_order_id` set. And it is always the case because when using `_pushOrdersToServer` nothing was actually done because `ordersToUpdateSet` was empty. Steps to reproduce: - Install the module `pos_preparation_disp
Original PR description
Current behavior: Kitchen preparation display would always show all the orders from all the PoS. This happens because here (https://github.com/odoo/enterprise/blob/saas-16.2/pos_preparation_display/models/preparation_display_order.py#L123) we get all the orders that do not have a `pos_order_id` set. And it is always the case because when using `_pushOrdersToServer` nothing was actually done because `ordersToUpdateSet` was empty. Steps to reproduce: - Install the module `pos_preparation_display` - Have 2 PoS restaurants - Configure 2 preparation displays, one for each PoS with all categories - Make an order in one PoS, and go to the preparation display of the other PoS. You will see the order from the other PoS. opw-3346282 Forward-Port-Of: odoo/enterprise#46665 Forward-Port-Of: odoo/enterprise#44571
We now detect the move type of an invoice, i.e. whether it is an invoice or a refund. Task #3102251 Community PR: odoo/odoo/pull/132969 Forward-Port-Of: odoo/enterprise#46700 Forward-Port-Of: odoo/enterprise#46200
Original PR description
We now detect the move type of an invoice, i.e. whether it is an invoice or a refund. Task #3102251 Community PR: odoo/odoo/pull/132969 Forward-Port-Of: odoo/enterprise#46700 Forward-Port-Of: odoo/enterprise#46200
Steps to reproduce: ------------------- - go to an appointment based on resources (for example: "Tennis Court"); - click on the "Add a Leave" button; - submit the leave. Issue: ------ A traceback appears. Cause: ------ We are trying to use a non-existent `end` field in the `appointment.manage.leaves` model to set the end date. Solution: --------- Use the `leave_end_dt` field to receive the end date of the leave. opw-3459844 Forward-Port-Of: odoo/enterprise#46015
Original PR description
Steps to reproduce: ------------------- - go to an appointment based on resources (for example: "Tennis Court"); - click on the "Add a Leave" button; - submit the leave. Issue: ------ A traceback appears. Cause: ------ We are trying to use a non-existent `end` field in the `appointment.manage.leaves` model to set the end date. Solution: --------- Use the `leave_end_dt` field to receive the end date of the leave. opw-3459844 Forward-Port-Of: odoo/enterprise#46015
The tax report tests with caba fail very rarely on runbot. It fails when the date changes during the execution of a test. We define the date to avoid changing during the test. Linked to runbot error 24422, 24093 Forward-Port-Of: odoo/enterprise#46685 Forward-Port-Of: odoo/enterprise#46553
Original PR description
The tax report tests with caba fail very rarely on runbot. It fails when the date changes during the execution of a test. We define the date to avoid changing during the test. Linked to runbot error 24422, 24093 Forward-Port-Of: odoo/enterprise#46685 Forward-Port-Of: odoo/enterprise#46553
Steps to reproduce: - Install `account_disallowed_expenses_fleet` and `l10n_be`. - Go to: Accounting > Configuration > Disallowed Expenses Categories. - Duplicate category with code 1205. - Set an account and a rate for both 1205 categories. - Create and post a Vendor Bill using both accounts. - Go to: Accouting > Reporting > Disallowed Expenses. --> Traceback. The issue comes from the fact that in `account_disallowed_expenses_fleet`, the query is modified and the group by is overrid
Original PR description
Steps to reproduce: - Install `account_disallowed_expenses_fleet` and `l10n_be`. - Go to: Accounting > Configuration > Disallowed Expenses Categories. - Duplicate category with code 1205. - Set an account and a rate for both 1205 categories. - Create and post a Vendor Bill using both accounts. - Go to: Accouting > Reporting > Disallowed Expenses. --> Traceback. The issue comes from the fact that in `account_disallowed_expenses_fleet`, the query is modified and the group by is overridden to use only the category name instead of both category id AND name. opw-3463858 Forward-Port-Of: odoo/enterprise#46505
The `Id` is a very technical id not really understandable by the end users, like a UUID. Instead, we should use the reference used by the bank for more uniformity between platforms. We chose the `LegalSequenceNumber <LglSeqNb>` > Legal sequential number of the statement, as assigned by the > account servicer . It is increased incrementally for each statement > sent. [opw-3464080](https://www.odoo.com/web#id=3464080&model=project.task) Forward-Port-Of: odoo/enterprise#46533
Original PR description
The `Id` is a very technical id not really understandable by the end users, like a UUID. Instead, we should use the reference used by the bank for more uniformity between platforms. We chose the `LegalSequenceNumber <LglSeqNb>` > Legal sequential number of the statement, as assigned by the > account servicer . It is increased incrementally for each statement > sent. [opw-3464080](https://www.odoo.com/web#id=3464080&model=project.task) Forward-Port-Of: odoo/enterprise#46533
Have a prod [TEST] set up as follows: - Recurring: True - Sales Price: 100 - Taxes: 15% not included in price - In Timed-based pricing tab, set Period: Monthly, Price 100.00 € Publish [TEST] in web shop Create a fiscal position [FP]: - Mapping 15% tax to 0% tax - Detect automatically - Country group: Belgium Without being logged in (public user) check the shop page Issue: [TEST] price is $115, if the product is added to cart, in the cart page it will show $100 This occurs beca
Original PR description
Have a prod [TEST] set up as follows: - Recurring: True - Sales Price: 100 - Taxes: 15% not included in price - In Timed-based pricing tab, set Period: Monthly, Price 100.00 € Publish [TEST] in web shop Create a fiscal position [FP]: - Mapping 15% tax to 0% tax - Detect automatically - Country group: Belgium Without being logged in (public user) check the shop page Issue: [TEST] price is $115, if the product is added to cart, in the cart page it will show $100 This occurs because the product price is updated twice. First via geoip the country group is detected correctly, the fiscal position is retrieved and price updated. Then, the fiscal position is checked only with the partner record (public user has no country). The fiscal position is not detected and original tax is kept opw-3446242 Forward-Port-Of: odoo/enterprise#46659
… properly Before this commit, when the action_update_prices action was called, all the prices were not properly computed if the line already had a parent_line_id. As calling this action should recompute completely the prices regarless of parent prices, we force the price to 0 first to break link to parent_line_id and we let the normal logic determine the price of the line. Forward-Port-Of: odoo/enterprise#46674
Original PR description
… properly Before this commit, when the action_update_prices action was called, all the prices were not properly computed if the line already had a parent_line_id. As calling this action should recompute completely the prices regarless of parent prices, we force the price to 0 first to break link to parent_line_id and we let the normal logic determine the price of the line. Forward-Port-Of: odoo/enterprise#46674
Steps to reproduce: ------------------- - create an employee without related user; - add documents without owner; - click on "Send HR Documents Access Link" action. Note: Can be trigger during archiving employee using "Send Access Link" checkbox. Issue: ------ With the sent link, we have access to all the documents that don't have an owner. Cause: ------ Without `user_id` on the employee, we create a `documents.share` with the domain `[('owner_id', '=', False)]`. Solution:
Original PR description
Steps to reproduce:
-------------------
- create an employee without related user;
- add documents without owner;
- click on "Send HR Documents Access Link" action.
Note:
Can be trigger during archiving employee using
"Send Access Link" checkbox.
Issue:
------
With the sent link, we have access to all the documents that don't have an owner.
Cause:
------
Without `user_id` on the employee, we create a `documents.share` with the domain `[('owner_id', '=', False)]`.
Solution:
---------
Use the "Send HR Documents Access Link" action only if a user is linked to the employee.
Recreate another `documents.share` if the user changes.
opw-3462259
Forward-Port-Of: odoo/enterprise#46662
Forward-Port-Of: odoo/enterprise#46489Issue introduced by #44356 where the variable transport_mode_car would be set to false for new cars in the salary configurator, which would in turn not let it's related advantage be computed correctly task-3476476 Forward-Port-Of: odoo/enterprise#46473 Forward-Port-Of: odoo/enterprise#46145
Original PR description
Issue introduced by #44356 where the variable transport_mode_car would be set to false for new cars in the salary configurator, which would in turn not let it's related advantage be computed correctly task-3476476 Forward-Port-Of: odoo/enterprise#46473 Forward-Port-Of: odoo/enterprise#46145
PR #43215 updated the filtering domain to a `parent_of` relationship, leading a parent_of to be computed on every iteration thanks to the per-iteration `_where_calc`. `parent_of` can be quite expensive to compute when it receives a dozen of companies, and that's amplified by some reports having batches of >100 prefixes to compute, yielding to an enormous overhead: in saas-16.2, `test_open_all_reports` takes 2 minutes to run, in master it takes 8 minutes, which is almost entirely down to this
Original PR description
PR #43215 updated the filtering domain to a `parent_of` relationship, leading a parent_of to be computed on every iteration thanks to the per-iteration `_where_calc`. `parent_of` can be quite…
PR #43215 updated the filtering domain to a `parent_of` relationship, leading a parent_of to be computed on every iteration thanks to the per-iteration `_where_calc`. `parent_of` can be quite expensive to compute when it receives a dozen of companies, and that's amplified by some reports having batches of >100 prefixes to compute, yielding to an enormous overhead: in saas-16.2, `test_open_all_reports` takes 2 minutes to run, in master it takes 8 minutes, which is almost entirely down to this issue. The community PR odoo/odoo#133436 changes the `_check_company_domain` to pre-resolve the `parent_of` relationship, but that's really only helpful if that resolution is also moved out of the loop do it's done only once per batch. This is what this PR does. At the end of the day, `test_open_all_reports` goes down from 8 to 3mn runtime, and the overall effect on the `test_l10n` step is a gain of ~7mn (42 to 35). Profiles using the report l10n_gr_pl_accounting_report (Profit and Loss (Model B.2.1)) as it accounted for several seconds of the total runtime of `test_open_all_reports` (in reality that'd the wrong report I wanted "Balance sheet (Model B.1.1)" which takes ~25s but the problem is the same in both). <details> <summary>Profile Before</summary>  </details> <details> <summary>Profile after</summary>  </details> The relevant bit is the "get_report_information" block on the right third, the right is script overhead, you'll have to download the PNG to get the active bits to play around with the zoom. On the first profile it takes 34% of samples, with `parent_of_domain` accounting for 6+3 = 9% of samples. On the second profile it takes 21% of samples, with `check_company_domain_parent_of` accounting for <1% of samples. Forward-Port-Of: odoo/enterprise#46464
Before this commit: - When adding text/bg-danger class to grid cells, they're not displayed in red as excpected. Technically, the used css classes for black color (with its different variants) like `text-800`, `text-bg-700` ... are using !important. After this commit: - The bug is fixed. X-original-commit: 3512aa7 Forward-Port-Of: odoo/enterprise#46453
Original PR description
Before this commit: - When adding text/bg-danger class to grid cells, they're not displayed in red as excpected. Technically, the used css classes for black color (with its different variants) like `text-800`, `text-bg-700` ... are using !important. After this commit: - The bug is fixed. X-original-commit: 3512aa7 Forward-Port-Of: odoo/enterprise#46453