Monday, March 25, 2024
48 changes · saas-17.2
Enhancements to existing features
This update adds automated checks for how client actions are opened through path-based links in the web interface. It helps reduce the risk of navigation issues reaching users by verifying this behavior during testing.
Original PR description
This commit adds some tests for the path-based routing of client actions commit: https://github.com/odoo/enterprise/commit/ffee7f5191cca060530d3e785328058ed8801dc5
This update improves Odoo's internal web testing tools by allowing tests to run in different orders and strengthening mock server behavior for unusual field types. It also fixes a validation issue in a dialog component, helping reduce false test failures and improve development confidence.
Resolved issues and error corrections
This fix ensures selected client actions receive the information needed to keep the current record reflected in the browser address bar. It helps users maintain the right context when navigating import guidance and website generation screens.
Original PR description
Since [1], it's now possible for a client action to use the resId and update the resId on the URL as a form view will do. To do this two props are given to the client action: resId and updateResId. This commit adds the missing props to existing client actions that were forgotten by the initial commit. [1] https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe
Miscellaneous changes
Importing large winbooks zip files can sometimes lead to a MemoryError. For instance, importing 360 000 account.moves in one go requires 3.1Gb of allocated memory, too much for a 2gb worker. This commit uses the fact that the get_dbfrecords function returns an iterator. The result_iterator yields all the items that pass the BOOKYEAR and DOCNUMBER condition. Also, yielding a frozendict allows to remove duplicate at the time of building the grouped defaultdict instead of when consuming the dbfr
Original PR description
Importing large winbooks zip files can sometimes lead to a MemoryError. For instance, importing 360 000 account.moves in one go requires 3.1Gb of allocated memory, too much for a 2gb worker. This…
Importing large winbooks zip files can sometimes lead to a MemoryError. For instance, importing 360 000 account.moves in one go requires 3.1Gb of allocated memory, too much for a 2gb worker. This commit uses the fact that the get_dbfrecords function returns an iterator. The result_iterator yields all the items that pass the BOOKYEAR and DOCNUMBER condition. Also, yielding a frozendict allows to remove duplicate at the time of building the grouped defaultdict instead of when consuming the dbfrecords iterator. That's because frozendict are hashable. By removing the intermediate recs and result local variables in `_import_move`, the memory peak drops to 1.6Gb, allowing to import the winbooks export on a 2gb worker. Add a more user-friendly error when there is no sub_zips in the main zip container. This can happen if the customer extracts the winbooks archive and tries to import the sub_zip directly. #### Benchmark Customer v17 database importing a 102Mb zip winbooks export containing 357825 moves. ##### Memray stats before PR, peak at 3.1Gb  ##### Memray stats after PR, peak at 1.6Gb  Forward-Port-Of: odoo/enterprise#56059
Duplicating read-only Sign templates now works without causing an error. This helps users reuse existing signing templates reliably instead of being blocked by a traceback.
Original PR description
Before this commit, when duplicating a read-only template a traceback was being triggered since we were passing a single template to the copy method. After this commit, we call the copy function passing a batch of a single element, which will return a list of templates containing a single template. After that, we call the action to open this copied template. task-3790206
This fix prevents the manufacturing Bill of Materials overview from failing when Odoo is used in debug mode. It also improves automated test coverage so this screen is checked more reliably in future updates.
Original PR description
In this [commit](https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR569-R577), the updateResId has been added to the action props. This did not trigger any error as the props are not validated, except if in debug mode. Adding the standardActionServiceProps solves this problem. This bug highlighted another problem: the component does not appear in a tour. opw-3822623 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 recruitment job positions menu is now hidden from demo users and others who do not have the required recruitment permissions. This prevents confusing access errors when navigating employee recruitment settings and keeps menus aligned with user rights.
Original PR description
In https://github.com/odoo/odoo/pull/157014 we make the mark demo rightless. Rightfully so. That change exposed an issue. After that change click_all fails for mark demo. More specifically, when hr_recruitment is installed, now mark demo gets access error when clicking on Employees / Configuration / Recruitment / Job Positions. Indeed, the user that does not have at least group_hr_recruitment_interviewer rights should not be seeing the menuitem that leads to jobs. In this PR we blacklist the menuitem, unless the user has proper rights
Several Odoo app screens now receive the record information they need to keep the browser URL aligned with the item being viewed. This fixes a consistency issue introduced by an earlier change and helps users navigate or share links more reliably.
Original PR description
Since [1], it's now possible for a client action to use the resId and update the resId on the URL as a form view will do. To do this two props are given to the client action: resId and updateResId. This commit adds the missing props to existing client actions that were forgotten by the initial commit. [1] https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe
This fix stops users from selecting certain custom grouping fields that cannot actually be used in reports or list views. It prevents confusing errors later by rejecting unsupported many-to-many fields earlier in the grouping process.
Original PR description
Since https://github.com/odoo/odoo/pull/127353, no-store many2many are considered as groupable (with the `_description_groupable` dry run). This means that users can select an ungroupable field in the custom group selector. Now raise a ValueError if the many2many is not stored in the `_read_group_groupby`.
Uses `product_category_name` instead of `categ_id` when deciding how to sort SMLs in the barcode picking view. Previously, `categ_id` was used for sorting, however there are two issues with that: 1.) This would sort by the ID, not the name, which is probably not expected behavior. 2.) `categ_id` is actually always undefined in the `_sortingMethod` call because it is never passed into the front end in the first place. This fix adds `product_category_name` as a field to be read from the `s
Original PR description
Uses `product_category_name` instead of `categ_id` when deciding how to sort SMLs in the barcode picking view. Previously, `categ_id` was used for sorting, however there are two issues with that: 1.)…
Uses `product_category_name` instead of `categ_id` when deciding how to sort SMLs in the barcode picking view. Previously, `categ_id` was used for sorting, however there are two issues with that: 1.) This would sort by the ID, not the name, which is probably not expected behavior. 2.) `categ_id` is actually always undefined in the `_sortingMethod` call because it is never passed into the front end in the first place. This fix adds `product_category_name` as a field to be read from the `stock.move.line` within the `_get_stock_barcode_data` method of `stock_barcode/models/stock_picking.py`. It also changes `categ_id` to `product_category_name` with the `_sortingMethod` method of `stock_barcode/static/src/models/barcode_model.js` As a final note, I am unsure if `categ_id` should be removed from the [`_get_fields_stock_barcode` method in `stock_barcode/models/product_product.py`](https://github.com/odoo/enterprise/blob/5b2fb8d0f3baf4fdc13e9399061110e06e3c76da/stock_barcode/models/product_product.py#L19). In this context it should be removed, however I'm unsure if other code may use it, and for compatibility sake it would be best to leave it there. opw-3693232 Forward-Port-Of: odoo/enterprise#59169 Forward-Port-Of: odoo/enterprise#56633
Before: when a CFDI wasn't created successfully, the retry button wasn't shown to force the user to go back to the send & print button to generate the invoice PDF. Now: the retry button is shown and the generation of the PDF is done by manually triggering the send and print process. task-3687266 Forward-Port-Of: odoo/enterprise#54835
Original PR description
Before: when a CFDI wasn't created successfully, the retry button wasn't shown to force the user to go back to the send & print button to generate the invoice PDF. Now: the retry button is shown and the generation of the PDF is done by manually triggering the send and print process. task-3687266 Forward-Port-Of: odoo/enterprise#54835
When having an asset beginning at the beginning of a period and having one period, the board values are wrongly computed although the depreciation move lines are good. Steps: - Create an asset with acquisition date set at the first day of a month - Set the period to 1 month - Set the same account as fixed asset account and depreciation account - Compute board and show depreciation moves tab -> Depreciation value, remaining value and cumulated depreciation are wrong The reason is that we en
Original PR description
When having an asset beginning at the beginning of a period and having one period, the board values are wrongly computed although the depreciation move lines are good. Steps: - Create an asset with acquisition date set at the first day of a month - Set the period to 1 month - Set the same account as fixed asset account and depreciation account - Compute board and show depreciation moves tab -> Depreciation value, remaining value and cumulated depreciation are wrong The reason is that we enter in a condition meant for set the value of closing entry when needed, which is not the case here. As there is no way, at the moment we enter this condition, to check if the asset is ment to be closed (state is still set to 'open'), the solution is to add a context key to achieve that. opw-3750254 Forward-Port-Of: odoo/enterprise#58595
Steps to reproduce: - Set up DHL shipping - Create Sale order, add dhl shipping and validate the delivery Bug: the shipper and reciver referrence are empty on the created comercial invoice opw-3775347 Forward-Port-Of: odoo/enterprise#59208
Original PR description
Steps to reproduce: - Set up DHL shipping - Create Sale order, add dhl shipping and validate the delivery Bug: the shipper and reciver referrence are empty on the created comercial invoice opw-3775347 Forward-Port-Of: odoo/enterprise#59208
**Steps to reproduce the bug:** - Create a storable product P1 with BoM: - Workorder: OP1 workcenter: Assembly 1 - Create a MO with P1 and confirm it - Go to the shop floor: - Select “Assembly 1” and “Drill 1” - Go to assembly 1 > select the workorder OP1 - on the right side of the footer in as ": (option)" button, which opens a pop-up window with additional options for the work order - click on “Move to workcenter” - Select “Drill 1” **Problem:** Change is
Original PR description
**Steps to reproduce the bug:** - Create a storable product P1 with BoM: - Workorder: OP1 workcenter: Assembly 1 - Create a MO with P1 and confirm it - Go to the shop floor: - Select “Assembly 1” and…
**Steps to reproduce the bug:**
- Create a storable product P1 with BoM:
- Workorder: OP1 workcenter: Assembly 1
- Create a MO with P1 and confirm it
- Go to the shop floor:
- Select “Assembly 1” and “Drill 1”
- Go to assembly 1 > select the workorder OP1
- on the right side of the footer in as ": (option)" button, which opens a pop-up window with additional options for the work order
- click on “Move to workcenter”
- Select “Drill 1”
**Problem:**
Change is applied in the frontend view (JS side) but not in the backend. If you refresh the page, the change will be lost. This is due to this commit:
https://github.com/odoo/odoo/commit/6bd2c1fdfb5722b1f2d4fc2684f20ed067b93b7d The purpose of this commit is to no longer save the record of an x2many when an autosave field is applied to an update
**Solution:**
Revert the changes made in this commit:
https://github.com/odoo/enterprise/commit/518dcd935094e30c8a39982be9b3ddb161bd03cd#diff-7df14ba8355f342f6f776e8ea293eb97ab75660c0f57245f5941e8d1da9a49bbR42-R45
opw-3816964
Forward-Port-Of: odoo/enterprise#59120# Issue: Data Cleaning App is slow. # Analyze: - There is no check on model duplication to generate subqueries. - For each domain search, the queries have subqueries joined with "UNION" which are slow and can't be optimized by the Planner. # Fix: - Remove duplicated models which generate the same condition. - Avoid subqueries and make one big query with each one of the subqueries. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| |
Original PR description
# Issue: Data Cleaning App is slow. # Analyze: - There is no check on model duplication to generate subqueries. - For each domain search, the queries have subqueries joined with "UNION" which are…
# Issue: Data Cleaning App is slow. # Analyze: - There is no check on model duplication to generate subqueries. - For each domain search, the queries have subqueries joined with "UNION" which are slow and can't be optimized by the Planner. # Fix: - Remove duplicated models which generate the same condition. - Avoid subqueries and make one big query with each one of the subqueries. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 5144 dmr (3 models) | 1,91 s | 0,31 s | | 974 931 dmr (3 models) | 7:09 min | 33,86 s ( Hot cache : 5,62s) | | 8 804 632 dmr (6 models) | Crash after 5:30 min | 1:19 min | # Note: - I tried it with the biggest database I could access, I didn't crash but on big databases with a lot of related model, there would be a bunch of LEFT JOIN and that could have a Memory Limit. (In any case it wouldn't work with current implementation) - The index could help on the planner, but it is not required (while it can't hurt to have an index on a Many2One). # Related task: opw-3696044 Speedscope in attachment in the task Forward-Port-Of: odoo/enterprise#56536
If the departement of the contract template is a parent of the employee's current department, we shouldn't update that value, since contract templates are mostly defined on the super department task-3818437 Forward-Port-Of: odoo/enterprise#59134
Original PR description
If the departement of the contract template is a parent of the employee's current department, we shouldn't update that value, since contract templates are mostly defined on the super department task-3818437 Forward-Port-Of: odoo/enterprise#59134
Steps to reproduce: - Set up DHL shipping - Create Sale order with a currency different than the company one - Add dhl shipping and validate the delivery Bug: the created comercial invoice is in the company currency instead of the SO Fix: apply same logic as 15.0 set currency to SO and fallback to the company currency if no SO is linked to the delivery opw-3775347 Forward-Port-Of: odoo/enterprise#59177
Original PR description
Steps to reproduce: - Set up DHL shipping - Create Sale order with a currency different than the company one - Add dhl shipping and validate the delivery Bug: the created comercial invoice is in the company currency instead of the SO Fix: apply same logic as 15.0 set currency to SO and fallback to the company currency if no SO is linked to the delivery opw-3775347 Forward-Port-Of: odoo/enterprise#59177
Since 39a0542b6505e18e3fdfbefba4210d8ba87bae3c, the value of `l10n_mx_edi_cfdi_to_public` depends on the partner linked to the pos_order. For instance, a mexican partner without VAT will have `l10n_mx_edi_cfdi_to_public` to True by default. The tour `test_mx_pos_invoice_previous_order` is failing undeterministically. The tour proceeds as follows: - create an order without partner, and validate it - later, go the list of paid orders, select the last one and invoice it - the list of partne
Original PR description
Since 39a0542b6505e18e3fdfbefba4210d8ba87bae3c, the value of `l10n_mx_edi_cfdi_to_public` depends on the partner linked to the pos_order. For instance, a mexican partner without VAT will have…
Since 39a0542b6505e18e3fdfbefba4210d8ba87bae3c, the value of `l10n_mx_edi_cfdi_to_public` depends on the partner linked to the pos_order. For instance, a mexican partner without VAT will have `l10n_mx_edi_cfdi_to_public` to True by default.
The tour `test_mx_pos_invoice_previous_order` is failing undeterministically. The tour proceeds as follows:
- create an order without partner, and validate it
- later, go the list of paid orders, select the last one and invoice it
- the list of partners opens to allow setting one
- then, a dialog opens to set the `l10n_mx_edi_usage` and `l10n_mx_edi_cfdi_to_public`
Currently, we simply select the first partner in the list ("(AR) Exento" if l10n_ar is installed...). When selecting this partner, we trigger the compute which will set a value on `l10n_mx_edi_cfdi_to_public`. Then, we can input `l10n_mx_edi_usage` and `l10n_mx_edi_cfdi_to_public` in the dialog. But the values filled in that dialog are not always saved to the database before ending the tour.
This fix uses a new partner to no longer depends on demo data. In addition, we leave the default values in the dialog to make sure the test will not fail no matter if the dialog's values are saved or not in the database (in a proper subsequent fix, we should ensure that we always end the tour after the dialog's values are saved).
runbot build error 60671
Forward-Port-Of: odoo/enterprise#59174The test creates an invoice, then a reversal, then checks the report values on the day of the invoice. But currently, there is no date for the reversal, s o if the invoice is created at 23:59:59 and the reversal at 00:00:01, the reversal won't be in the report values and so, the test will fail. The solution proposed is just to create the reversal at the invoice date Linked to runbot error 59289 Forward-Port-Of: odoo/enterprise#59157 Forward-Port-Of: odoo/enterprise#58644
Original PR description
The test creates an invoice, then a reversal, then checks the report values on the day of the invoice. But currently, there is no date for the reversal, s o if the invoice is created at 23:59:59 and the reversal at 00:00:01, the reversal won't be in the report values and so, the test will fail. The solution proposed is just to create the reversal at the invoice date Linked to runbot error 59289 Forward-Port-Of: odoo/enterprise#59157 Forward-Port-Of: odoo/enterprise#58644
### Steps to reproduce: - Install **l10n_pe_website_sale** module. - Switch to **PE Company**. - While Enabling the debug mode, Go to **Website** > **Configuration** > **Websites** and add a new website for the **PE Company**. - Go to **Website** > **Shop**, Switch to the new website and add a product to the cart. - Checkout the cart. - In the address section, try to choose a state. - An error arises: `Uncaught Javascript Error > this.rpc is not a function` ### Investigation: - `this.
Original PR description
### Steps to reproduce: - Install **l10n_pe_website_sale** module. - Switch to **PE Company**. - While Enabling the debug mode, Go to **Website** > **Configuration** > **Websites** and add a new website for the **PE Company**. - Go to **Website** > **Shop**, Switch to the new website and add a product to the cart. - Checkout the cart. - In the address section, try to choose a state. - An error arises: `Uncaught Javascript Error > this.rpc is not a function` ### Investigation: - `this.rpc` is no longer used in 17.1. It's `undefined`. opw-3793838 Forward-Port-Of: odoo/odoo#158295
Address several design and functional issues in prod. See sub commits, each of them addressing a different issue. Task-3718417 part-of task-3698364 Forward-Port-Of: odoo/odoo#152434
Original PR description
Address several design and functional issues in prod. See sub commits, each of them addressing a different issue. Task-3718417 part-of task-3698364 Forward-Port-Of: odoo/odoo#152434
Versions -------- - 16.0+ Steps ----- 1. Set tax rounding method to global; 2. create a loyalty program offering 100% discount on orders; 3. create a SO with the following line subtotals & 15% tax: 1. $5.60 2. $8.92 3. $44.91 4. $217.26 5. $2400.00 4. apply the 100% discount program. Issue ----- Total comes down to $0.01 instead of $0.00. Cause ----- To calculate the `discountable` amount, the `_discountable_order` method uses the `_compute_taxes` met
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Set tax rounding method to global; 2. create a loyalty program offering 100% discount on orders; 3. create a SO with the following line subtotals & 15% tax:…
Versions
--------
- 16.0+
Steps
-----
1. Set tax rounding method to global;
2. create a loyalty program offering 100% discount on orders;
3. create a SO with the following line subtotals & 15% tax:
1. $5.60
2. $8.92
3. $44.91
4. $217.26
5. $2400.00
4. apply the 100% discount program.
Issue
-----
Total comes down to $0.01 instead of $0.00.
Cause
-----
To calculate the `discountable` amount, the `_discountable_order` method uses the `_compute_taxes` method from `account.tax` for each line, which doesn't check for global rounding method. This can introduce small rounding errors. When calculating the discount factor by dividing the `max_discount` (total amount of the order) by `discountable`, the result will be 0.999... instead of 1 if `discountable` is off by one cent.
Solution
--------
Use the `compute_all` method instead, which factors in the tax rounding method by using increased precision.
opw-3710365
Forward-Port-Of: odoo/odoo#156897Bug: When an irish company without VAT invoices a Norvegian company with a 0% tax, the category of the tax is "K" in the Bis 3 xml, which will raise: "[BR-IC-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Intra-community supply" shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48)." Using code "G" would also raise: "[BR-G-02]-An Invoice that c
Original PR description
Bug: When an irish company without VAT invoices a Norvegian company with a 0% tax, the category of the tax is "K" in the Bis 3 xml, which will raise: "[BR-IC-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Intra-community supply" shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48)." Using code "G" would also raise: "[BR-G-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Export outside the EU" shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63)." Fix: We should only use "G" or "K" when the supplier has a VAT. If a supplier without a VAT invoices with a 0% tax, we should use the tax category "E" (Exempted). opw-3785810 Forward-Port-Of: odoo/odoo#158549
If the 'cancel next move' feature is enabled, canceling a SOL could lead to unexpected picking creation To reproduce the issue: (Debug mode enabled) 1. In Settings, enable "Multi-Step Routes" 2. Edit the warehouse: - Outgoing shipments: 2 steps 3. Edit the delivery route: - For each rule: - Cancel next move: True 4. Confirm a SO with one product 5. Set the SOL quantity to 0 Error: A third picking is created, from customer to output location Step 4, it creates two SM
Original PR description
If the 'cancel next move' feature is enabled, canceling a SOL could lead to unexpected picking creation To reproduce the issue: (Debug mode enabled) 1. In Settings, enable "Multi-Step Routes" 2. Edit…
If the 'cancel next move' feature is enabled, canceling a SOL could
lead to unexpected picking creation
To reproduce the issue:
(Debug mode enabled)
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Outgoing shipments: 2 steps
3. Edit the delivery route:
- For each rule:
- Cancel next move: True
4. Confirm a SO with one product
5. Set the SOL quantity to 0
Error: A third picking is created, from customer to output location
Step 4, it creates two SM:
\- SM_SO: from Stock to Ouput
\- SM_OC: from Output to Customer
Step 5, thanks to the procurement process, we create a stock move:
\- SM_OC_neg, from Output to Customer with a negative qty.
While confirming this SM, and thanks to the same process, we then
create a second stock move :
\- SM_SO_neg, from Stock to Output, with a negative qty.
Both negative SM are linked. While confirming SM_SO_neg, we merge it
with SM_SO. Therefore:
\- Dest moves of SM_SO_neg are given to SM_SO
\- SM_SO_neg is deleted (fully absorbed by SM_SO)
\- SM_SO has now a zero demand, so we cancel it:
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1024-L1025
However, because of step 3, we also cancel its dest moves:
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1740-L1745
i.e., we cancel SM_OC *and* SM_OC_neg. This leads to an inconsistency:
Back to the confirmation of SM_SO_neg. As explained, this SM has
been canceled during the procurement process. Still, we keep
processing its confirmation (we overwrite its state, we assign it to a
picking, and so on). Hence the error.
In `_merge_moves`, when deleting a stock move, we first clean it
(for instance, we disable the cancel propagation):
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1018-L1020
We should do the same with SMs we are going to cancel. That way, we
fix the root cause of the issue: when cancelling SM_SO, we don't
cancel neither SM_OC neither SM_OC_neg, so we don't have any
inconsistency when going back to the confirmation of SM_SO_neg, and
everything will work correctly.
OPW-3753453
Forward-Port-Of: odoo/odoo#158663
Forward-Port-Of: odoo/odoo#158562In https://github.com/odoo/odoo/pull/126065 we introduced the feature, that blacklists providers. The issue with it, is that even if we only provide email_from once we check it's not blacklisted [1], when we call the super method, email_from is still filled in [2] In order to correct it, we also delete blacklisted mail from msg_dict [1] - https://github.com/odoo/odoo/blob/aed0e74462b15085c09d9ab5ff029810f1238aeb/addons/hr_recruitment/models/hr_applicant.py#L615-L616 [2] -https://github
Original PR description
In https://github.com/odoo/odoo/pull/126065 we introduced the feature, that blacklists providers. The issue with it, is that even if we only provide email_from once we check it's not blacklisted [1], when we call the super method, email_from is still filled in [2] In order to correct it, we also delete blacklisted mail from msg_dict [1] - https://github.com/odoo/odoo/blob/aed0e74462b15085c09d9ab5ff029810f1238aeb/addons/hr_recruitment/models/hr_applicant.py#L615-L616 [2] -https://github.com/odoo/odoo/blob/aed0e74462b15085c09d9ab5ff029810f1238aeb/addons/mail/models/mail_thread.py#L1388-L1390 task-3793345 Forward-Port-Of: odoo/odoo#157107
Purpose ======= Lots of tickets (e.g. 3775298) are created because the default menu as been deleted, leading to the impossibility to install a new module, as the parent_id for new menus like /shop or /event are directly referencing the website.main_menu record, or to the impossibility to create a new website. TaskID: 3802440 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed th
Original PR description
Purpose ======= Lots of tickets (e.g. 3775298) are created because the default menu as been deleted, leading to the impossibility to install a new module, as the parent_id for new menus like /shop or /event are directly referencing the website.main_menu record, or to the impossibility to create a new website. TaskID: 3802440 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#158595 Forward-Port-Of: odoo/odoo#158070
Purpose ======= Tremendous amount of support tickets (ex: 3800405) are opened because the user_admin has been removed and is referenced everywhere, leading to tracebacks or the impossibility to install a new application as res.group configurations all relies on this, like: <record id="group_helpdesk_manager" model="res.groups"> <field name="name">Administrator</field> <field name="category_id" ref="base.module_category_services_helpdesk"/> <field name="implied_ids" eval="[(
Original PR description
Purpose ======= Tremendous amount of support tickets (ex: 3800405) are opened because the user_admin has been removed and is referenced everywhere, leading to tracebacks or the impossibility to…
Purpose
=======
Tremendous amount of support tickets (ex: 3800405) are opened because the user_admin has been removed and is referenced everywhere, leading to tracebacks or the impossibility to install a new application as res.group configurations all relies on this, like:
<record id="group_helpdesk_manager" model="res.groups">
<field name="name">Administrator</field>
<field name="category_id" ref="base.module_category_services_helpdesk"/>
<field name="implied_ids" eval="[(4, ref('group_helpdesk_user'))]"/>
<field name="users" eval="[(4, ref('base.user_root')), (4, ref('base.user_admin'))]"/>
</record>
We could adapt all the occurences (severeal hundreds) to ensure robustness but this won't prevent developer from introducing new use cases + the user can be archived instead if we want to remove him from the pricing.
TaskID: 3802440
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#158620
Forward-Port-Of: odoo/odoo#158068_read_group doesn't raise any error when we have a aggregate like `order_id.create_date:min`, instead it silently ignore `.create_date` part. We only add a warning in stable version to avoid any breaking change. Forward-Port-Of: odoo/odoo#158777
Original PR description
_read_group doesn't raise any error when we have a aggregate like `order_id.create_date:min`, instead it silently ignore `.create_date` part. We only add a warning in stable version to avoid any breaking change. Forward-Port-Of: odoo/odoo#158777
When typing in Japanese with Romaji input, a traceback occurred when hitting backspace to remove the only character in the editable while the Japanese character selection menu was open. This is because that case triggers an `insertCompositionText` input event with an empty string, and tries to delete the editable, which is unremovable. Since we called `_applyRawCommand` without wrapping it in `_protect`, the unremovable error caused a traceback instead of a rollback. When fixing that, an other b
Original PR description
When typing in Japanese with Romaji input, a traceback occurred when hitting backspace to remove the only character in the editable while the Japanese character selection menu was open. This is because that case triggers an `insertCompositionText` input event with an empty string, and tries to delete the editable, which is unremovable. Since we called `_applyRawCommand` without wrapping it in `_protect`, the unremovable error caused a traceback instead of a rollback. When fixing that, an other bug appeared, which was the insertion of a `#` character. This was due to the fact that `insertText` was called with empty content, and `insertText` defaulted to the character `#` for no particular reason since the early proof of concept of the editor. task-3134566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158795
Current state: - Company ID field in the Contacts form view is introduced by the base module and it is put into the Purchase tab. - l10n_cz module adds an invisibility attribute to that field which hides it if the current company is not based in CZ. It also adds another instance of the field into the main tab but also adds the same invisibility attribute for the field. - If l10n_sk module is installed next (e.g. in a multicompany setup) it adds another instance of the field into the main ta
Original PR description
Current state: - Company ID field in the Contacts form view is introduced by the base module and it is put into the Purchase tab. - l10n_cz module adds an invisibility attribute to that field which…
Current state: - Company ID field in the Contacts form view is introduced by the base module and it is put into the Purchase tab. - l10n_cz module adds an invisibility attribute to that field which hides it if the current company is not based in CZ. It also adds another instance of the field into the main tab but also adds the same invisibility attribute for the field. - If l10n_sk module is installed next (e.g. in a multicompany setup) it adds another instance of the field into the main tab but changes the visibility attribute of all the instances suit SK-based companies. However this means the field becomes hidden for CZ-based companies (current company). Plus the field is doubled if the current company is a SK-based one. - A similar problem happens if the l10n_sk is installed first and l10n_cz comes after it. Fix: - Remove the invisible attribute so that the Company ID field on the main tab and on Sales and Purchase tab remains untouched and visible whatever the current company's country is. Forward-Port-Of: odoo/odoo#158605
The UUID in the localstorage name was not being used, so it was always the same. All different pos config should have different localstorage. Forward-Port-Of: odoo/odoo#158591
Original PR description
The UUID in the localstorage name was not being used, so it was always the same. All different pos config should have different localstorage. Forward-Port-Of: odoo/odoo#158591
- Create PO - Confirm, delivery and create bill - Confirm and create reverse move via "Add credit note" (Full Refund) - Open portal view of the PO Issue: The credit note payment status display `Waiting Payment` badge instead of `Paid` opw-3806514 Forward-Port-Of: odoo/odoo#158556 Forward-Port-Of: odoo/odoo#158108
Original PR description
- Create PO - Confirm, delivery and create bill - Confirm and create reverse move via "Add credit note" (Full Refund) - Open portal view of the PO Issue: The credit note payment status display `Waiting Payment` badge instead of `Paid` opw-3806514 Forward-Port-Of: odoo/odoo#158556 Forward-Port-Of: odoo/odoo#158108
This data is used in the chart of account definition and could put the end user into a bad situation. Related ticket: 3790614 Forward-Port-Of: odoo/odoo#158367 Forward-Port-Of: odoo/odoo#157571
Original PR description
This data is used in the chart of account definition and could put the end user into a bad situation. Related ticket: 3790614 Forward-Port-Of: odoo/odoo#158367 Forward-Port-Of: odoo/odoo#157571
In a1f32fafa85b300e2d656a57797b8dbde6e3f065, various onchanges from the picking types were changed into computes. However, the compute for the `print_label` field was forgotten and never linked to its field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158869
Original PR description
In a1f32fafa85b300e2d656a57797b8dbde6e3f065, various onchanges from the picking types were changed into computes. However, the compute for the `print_label` field was forgotten and never linked to its field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158869
A traceback was spotted when `unserializeNode` was called as a result of a call to `resetContent`. That traceback could lead to other tracebacks (including one when trying to read a history step's ID in `_historyMakeSnapshot`). A traceback at that moment could remove all the content of the editor before saving. This commit ensures the argument passed to `unserializeNode` is defined, that `unserializeNode` returns `undefined` if it couldn't return anything valid, and that when such is the case
Original PR description
A traceback was spotted when `unserializeNode` was called as a result of a call to `resetContent`. That traceback could lead to other tracebacks (including one when trying to read a history step's ID in `_historyMakeSnapshot`). A traceback at that moment could remove all the content of the editor before saving. This commit ensures the argument passed to `unserializeNode` is defined, that `unserializeNode` returns `undefined` if it couldn't return anything valid, and that when such is the case the caller handles that undefined return value properly. task-3677431 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158009
Resequencing entries that come from payment and non payment raise a UserError, even if the journal has `payment_sequence` set to False Steps to reproduce: 1) Go to "Accounting / Configuration / Accounting / Journals" and create a new journal with type "Bank" and "Dedicated Payment Sequence" in False. 2) Create a "Bank Statement Line" in the journal created in step "1". 3) Create and confirm a customer payment using the journal created in step "1". 4) Go to "Accounting / Acco
Original PR description
Resequencing entries that come from payment and non payment raise a UserError, even if the journal has `payment_sequence` set to False Steps to reproduce: 1) Go to "Accounting / Configuration / Accounting / Journals" and create a new journal with type "Bank" and "Dedicated Payment Sequence" in False. 2) Create a "Bank Statement Line" in the journal created in step "1". 3) Create and confirm a customer payment using the journal created in step "1". 4) Go to "Accounting / Accounting / Journals / Journal Entries". Select journal entries created on step "2" and "3" and then click on Action --> Resequence. Then a User Error is being show "The sequences of this journal are different for Payments and non-Payments but you selected some of both types." it is not correct as the journal created on step "1" has the field "Dedicated Payment Sequence" set to "False". opw-3763500 Forward-Port-Of: odoo/odoo#157988
Before this commit, when using a shipping method with the variable weight*volume for price computation, the price was growing with the square of the ordered quantities. This is because both volume and weight were multiplied by the quantity, before being multiplied with each other in the next step. This commit fixes the issue by introducing the variable weight*volume at the beginning of the computation. In order not to break anything in stable, the new variable is added as a kwarg to the us
Original PR description
Before this commit, when using a shipping method with the variable weight*volume for price computation, the price was growing with the square of the ordered quantities. This is because both volume and weight were multiplied by the quantity, before being multiplied with each other in the next step. This commit fixes the issue by introducing the variable weight*volume at the beginning of the computation. In order not to break anything in stable, the new variable is added as a kwarg to the useful methods. OPW-3802315 Forward-Port-Of: odoo/odoo#158899 Forward-Port-Of: odoo/odoo#158767
Before this commit, clicking on an optional product in the product info popup would cause an error. This was due to the absence of the `setSelectedCategoryId` function, which was removed during the refactor. opw-3815392 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158609
Original PR description
Before this commit, clicking on an optional product in the product info popup would cause an error. This was due to the absence of the `setSelectedCategoryId` function, which was removed during the refactor. opw-3815392 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158609
Steps to reproduce: - Create pricelist with an end date in the past for a stored product - Click on manual replenishement - The created PO will have a price of 0 Bug: if no valid pricelist is found unit price is set to 0 product standard price is a better fallback opw-3692985 Forward-Port-Of: odoo/odoo#158650 Forward-Port-Of: odoo/odoo#157023
Original PR description
Steps to reproduce: - Create pricelist with an end date in the past for a stored product - Click on manual replenishement - The created PO will have a price of 0 Bug: if no valid pricelist is found unit price is set to 0 product standard price is a better fallback opw-3692985 Forward-Port-Of: odoo/odoo#158650 Forward-Port-Of: odoo/odoo#157023
Task ID: 3703643 To reproduce issue: - create a new picking of any operation type - save the picking (so that a name is formed) - edit the picking and change the operation type to another type - save manually Expected result: - new name with matching prefix to the new operation type Actual result: - previous name with prefix from previous operation type is still there This is an issue because then the name doesn't match and this can be confusing to users ---
Original PR description
Task ID: 3703643 To reproduce issue: - create a new picking of any operation type - save the picking (so that a name is formed) - edit the picking and change the operation type to another type - save manually Expected result: - new name with matching prefix to the new operation type Actual result: - previous name with prefix from previous operation type is still there This is an issue because then the name doesn't match and this can be confusing to users --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153147
`BooleanFavoriteField` wasn't translated as the component was using an untranslated variable instead of relying on the translation of the template. Some other translation fixing: - ID Azienda is very generic, the correct name is Numero REA: See: https://www.registroimprese.it/codice-fiscale-p.iva-rea - No one calls a mobile phone "Dispositivo mobile", we already translate it as the more common "Cellulare" even in the same file Task [link](https://www.odoo.com/web#model=project.task&id
Original PR description
`BooleanFavoriteField` wasn't translated as the component was using an untranslated variable instead of relying on the translation of the template. Some other translation fixing: - ID Azienda is very generic, the correct name is Numero REA: See: https://www.registroimprese.it/codice-fiscale-p.iva-rea - No one calls a mobile phone "Dispositivo mobile", we already translate it as the more common "Cellulare" even in the same file Task [link](https://www.odoo.com/web#model=project.task&id=3263708) task-3263708 Forward-Port-Of: odoo/odoo#157949
**Steps to reproduce:** 1- Install Point of sale module 2- Allow shipping later configuration 3- Create a POS order with a shipping date **Current behavior before PR:** The expected shipping date was not printed in the pos receipt. This was happening because it was getting called wrong in xml file where it was called 'props.shippingDate'. By checking the JS file we found that the props object structure as follows https://github.com/odoo/odoo/blob/17.0/addons/point_of_sale/static/src/a
Original PR description
**Steps to reproduce:** 1- Install Point of sale module 2- Allow shipping later configuration 3- Create a POS order with a shipping date **Current behavior before PR:** The expected shipping date was not printed in the pos receipt. This was happening because it was getting called wrong in xml file where it was called 'props.shippingDate'. By checking the JS file we found that the props object structure as follows https://github.com/odoo/odoo/blob/17.0/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.js#L16:L19 **Desired behavior after PR is merged:** The expected shipping date is printed not if exists. As we it is now getting called correctly 'props.data.shippingDate' opw-3746053 Forward-Port-Of: odoo/odoo#158718 Forward-Port-Of: odoo/odoo#155844
As we imported invoices from the IAP proxy we refused files when the same filename was already present in the database. Import invoices sent by Company A to Company B on the same Odoo database was therefore impeded. The CRON would try to import the Company B's vendor bill with the same attachment's filename as the Company A's invoice and reject the file. Now we fill in the `company_id` field on the attachment and we search for attachments which belong to the company we're importing for, so
Original PR description
As we imported invoices from the IAP proxy we refused files when the same filename was already present in the database. Import invoices sent by Company A to Company B on the same Odoo database was therefore impeded. The CRON would try to import the Company B's vendor bill with the same attachment's filename as the Company A's invoice and reject the file. Now we fill in the `company_id` field on the attachment and we search for attachments which belong to the company we're importing for, so the case is covered. An import test has been added. Ticket [link](https://www.odoo.com/web#model=project.task&id=3673508) opw-3673508 Forward-Port-Of: odoo/odoo#157755
Currently, log level error mesage occur when`ValueError` is catched by line [1]. This commit changes 'logger.error' to 'logger.warning' with filename to log message instead of error since this is not an actual error of the codebase. [1]-https://github.com/odoo/odoo/blob/3932c46f914c40be4b0629771d1981cdf289df26/addons/web/controllers/binary.py#L131 sentry-4657682601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: o
Original PR description
Currently, log level error mesage occur when`ValueError` is catched by line [1]. This commit changes 'logger.error' to 'logger.warning' with filename to log message instead of error since this is not an actual error of the codebase. [1]-https://github.com/odoo/odoo/blob/3932c46f914c40be4b0629771d1981cdf289df26/addons/web/controllers/binary.py#L131 sentry-4657682601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158904 Forward-Port-Of: odoo/odoo#158342
Current behavior: When printing a ZPL label for a product without barcode, the label was printed with a barcode containing the "False" value Steps to reproduce: - Install the stock module - Create a product without barcode - Print a ZPL label for this product - The label contains a barcode with the "False" value (You can check the rendering on labelary.com) opw-3797462 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odo
Original PR description
Current behavior: When printing a ZPL label for a product without barcode, the label was printed with a barcode containing the "False" value Steps to reproduce: - Install the stock module - Create a product without barcode - Print a ZPL label for this product - The label contains a barcode with the "False" value (You can check the rendering on labelary.com) opw-3797462 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158668 Forward-Port-Of: odoo/odoo#158386
That is how states are (might be?) exported, so it should be possible to find them the same way. Task-Id: 3644762 Forward-Port-Of: odoo/odoo#159001 Forward-Port-Of: odoo/odoo#157428
Original PR description
That is how states are (might be?) exported, so it should be possible to find them the same way. Task-Id: 3644762 Forward-Port-Of: odoo/odoo#159001 Forward-Port-Of: odoo/odoo#157428
## Context: During the refactor 68fbdc964038ef6a1cf0d3df773db101ca81794a, expense rights were improved but two cases were forgotten. ## Before this commit: 1. sudo would not work as the rights were checking the groups 2. system admins were considered as being expense admins too, which may not be the case if the system admin user changes and the correct group `group_hr_expense_manager` is not given. System admins should always be able to edit expenses when it make sense. #
Original PR description
## Context: During the refactor 68fbdc964038ef6a1cf0d3df773db101ca81794a, expense rights were improved but two cases were forgotten. ## Before this commit: 1. sudo would not work as the rights were checking the groups 2. system admins were considered as being expense admins too, which may not be the case if the system admin user changes and the correct group `group_hr_expense_manager` is not given. System admins should always be able to edit expenses when it make sense. ## After this commit: Sudoed and group_system users are considered as expense admins (thx @jepbarasgarov for raising the issue ) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158583
Issue 1: ====== The icons does match the direction of the move but it doesn't match the label in the ltr language. Steps to reproduce the issue: ============================= - Install arabic - Go to notes and insert a table - write something in a column in the middle - Click on the top of the column on the 3 points. - The first item of the dropdown have the label in arabic meaning `Move to left` but the direction of the icon and clicking on it will move it to the right. Origin of
Original PR description
Issue 1: ====== The icons does match the direction of the move but it doesn't match the label in the ltr language. Steps to reproduce the issue: ============================= - Install arabic - Go to…
Issue 1: ====== The icons does match the direction of the move but it doesn't match the label in the ltr language. Steps to reproduce the issue: ============================= - Install arabic - Go to notes and insert a table - write something in a column in the middle - Click on the top of the column on the 3 points. - The first item of the dropdown have the label in arabic meaning `Move to left` but the direction of the icon and clicking on it will move it to the right. Origin of the issue: ==================== - The icon is being flipped because we are in rtl but in realtity left is the same for rtl or ltr direction. - We need to call `_onTableMoveLeftClick` when we are moving to the right in rtl because the left of rtl direction is the visible right. Issue 2 : ====== resizing columns doesn't work properly in rtl direction. Steps to reproduce the issue: ============================= - Install arabic - Go to notes - insert a table - Try to resize columns Solution: ========= We will handle the cases one by one: Start: We need to update the `marginRight` prop instead of `marginLeft` and calculate `sizeDelta` correctly which `clientX - (rect.x + rec.width)`. Middle: We will handle this the same as ltr direction, since it's the reverse direction, we swap `previous` with `next` and `next` with `previous`. Columns are sorted from right to left so we need to swap columns when we recalculate them from the columns array so `item` will be the one on the left and `neighbor` the one on the right. last: We calculate correctly `sizeDelta` which is `rect.x - clientX` task-3721794 Forward-Port-Of: odoo/odoo#157508