Wednesday, December 18, 2024
27 changes · saas-17.4
Resolved issues and error corrections
Point of Sale order synchronization now records clearer activity logs when orders are sent to the backend. This helps support teams investigate duplicate orders or cases where a customer has a receipt but the order cannot be found in the system.
Original PR description
Before this commit PoS orders synchronisation can sometime happen in parallel. When it is the case, we can end up with situation of duplicated PoS orders stored in the backend. This can also be…
Before this commit
PoS orders synchronisation can sometime happen in parallel. When it is the case, we can end up with situation of duplicated PoS orders stored in the backend. This can also be useful to cases where "there is a receipt for the order XXX-YYY-ZZZ, but it does not appear in the backend!"
After this commit:
To ease the investigation of such cases, logs are added with various information to better understand customer flows and tracability when a PoS order is synced.
The main idea was added to the "PoS order" capture PR: https://github.com/odoo/odoo/pull/174562
But this one is waiting for other PR to be deployed due to the heavy PoS refactoring in 17.4. In the mean time, the logs part can be easily pushed in 17.4
Logs example:
New PoS order logs:
```
2024-12-16 16:55:32,254 49677 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #89627943 started for PoS orders references: [{'name': 'Order 00007-003-0001', 'uuid': '838043cb-8324-4b52-a45e-c8707f8975ff'}]
2024-12-16 16:55:32,413 49677 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #89627943 order {'name': 'Order 00007-003-0001', 'uuid': '838043cb-8324-4b52-a45e-c8707f8975ff'} created pos.order #38
2024-12-16 16:55:32,414 49677 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #89627943 finished
2024-12-16 16:55:32,434 49677 INFO oes_17.4_pos werkzeug: 127.0.0.1 - - [16/Dec/2024 16:55:32] "POST /web/dataset/call_kw/pos.order/sync_from_ui HTTP/1.1" 200 - 90 0.070 0.114
```
Updated PoS restaurant order:
```
2024-12-16 16:36:27,190 43869 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #99444056 started for PoS orders references: [{'name': 'Restaurant/00004', 'uuid': '9653201c-1c04-4679-99b8-61d2ae91fc87'}]
2024-12-16 16:36:27,331 43869 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #99444056 order {'name': 'Restaurant/00004', 'uuid': '9653201c-1c04-4679-99b8-61d2ae91fc87'} updated pos.order #12
2024-12-16 16:36:27,331 43869 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #99444056 finished
2024-12-16 16:36:27,348 43869 INFO oes_17.4_pos werkzeug: 127.0.0.1 - - [16/Dec/2024 16:36:27] "POST /web/dataset/call_kw/pos.order/sync_from_ui HTTP/1.1" 200 - 101 0.059 0.425
```
opw-3650239The time off overview has been corrected so it no longer includes leave entries that should be outside the viewed scope. This helps HR users and managers rely on the overview for accurate planning and absence tracking.
Original PR description
backport of odoo/odoo#189628 fixing bug introduced in odoo/odoo#188393
Miscellaneous changes
The import origin of `json` will be changed to `odoo.tools.safe_eval` for 2 reasons: 1. From 18.0 onwards, it refers to the `json.py` file, not the intended `json` module. This leads to an `AttributeError` when we're calling `json.loads(...)` method. 2. The `json` module from `safe_eval` is, from a security perspective, the intended way to load a json string (rather than the usual `json` from `import json`). follow up of: https://github.com/odoo/odoo/pull/187708 more info: https://git
Original PR description
The import origin of `json` will be changed to `odoo.tools.safe_eval` for 2 reasons: 1. From 18.0 onwards, it refers to the `json.py` file, not the intended `json` module. This leads to an `AttributeError` when we're calling `json.loads(...)` method. 2. The `json` module from `safe_eval` is, from a security perspective, the intended way to load a json string (rather than the usual `json` from `import json`). follow up of: https://github.com/odoo/odoo/pull/187708 more info: https://github.com/odoo/odoo/commit/5ef4c07ada1b47cd08a0fc7a2dd626f92d79b715#diff-6e39afafc5c2078cdfdc27335b7cf8b0867853dc34b5b907a0190f6453949bb2R21 opw-4187186 Forward-Port-Of: odoo/odoo#190955
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive "Replenish on Order (MTO)" - Create a storable product P with routes: MTO, Buy and a set vendor - Create and confirm a sale order with one line: - 2 x product P > A delivery has been created. - Cancel the SO, set it back to quotation and confirm it once more. > The first delivery has been cancelled and a new one has been created - Decrease the quantity of the SOL from 2 to 1 and save ####
Original PR description
### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive "Replenish on Order (MTO)" - Create a storable product P with routes: MTO, Buy and a set vendor - Create…
### Steps to reproduce:
- In Settings, enable "Multi-Step Routes"
- In the Routes, unarchive "Replenish on Order (MTO)"
- Create a storable product P with routes: MTO, Buy and a set vendor
- Create and confirm a sale order with one line:
- 2 x product P
> A delivery has been created.
- Cancel the SO, set it back to quotation and confirm it once more.
> The first delivery has been cancelled and a new one has been created
- Decrease the quantity of the SOL from 2 to 1 and save
#### > Issue: The delivery from stock to customer was not updated but an incoming picking was created from customer to stock.
### Cause of the Issue:
When confirming the SO, `_run_pull` will be called and will create an outgoing move SM01 based on our rule. Initially and because of the rule used for its creation, the `procure_method` of this move is `make_to_order`. However, once the SO is cancelled, this move `procure_method` will be updated to be `make_to_stock`: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_move.py#L1794-L1798 Once the SO is reset to draft and confirmed once more, a new outgoing move SM02 will be created by the `_run_pull` using the same rule as SM01 Then, when the quantity of the SOL is decreased from 2 to 1, a negative outgoing move SM03 will be created by the `_run_pull` and is expected to be absorbed by SM02 during the `_merge_move` of its `action_confirm`: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_move.py#L1397
However, the merging process will fail for 2 reasons:
1. Negative moves are merged based on a reduced set of comparaison keys: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_move.py#L1046-L1047 Which is expected to exculde the created sale order lines: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/purchase_stock/models/stock_move.py#L28 However, the field name `created_purchase_line_id` has been renamed to `created_purchase_line_id"s"` in 17.0 and this update has been reased by mistake during a forward port: b40bd15c9ce43b60a8993afbe61c56a3bb9f782f
2. While the `procure_method` is a valid comparaison key for negative moves, it is a tricky field to use as the `procure_method` present on the move we want to merge with might not correspond to the `procure_method` set by our rule (`make_to_order` for SM03). The purpose of these lines is therefore to update the `procure_method` of negative moves to match valid merging candidates:
https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_rule.py#L260-L269 However, SM01 is not a valid merging candidtes as it was cancelled and its `procure_method` has changed during its cancellation so that it will wrongly update the `procure_method` of SM03 to `make_to_stock`: https://github.com/odoo/odoo/blob/ef161136fe2034752c2cc923cb892e933b78d4c0/addons/stock/models/stock_rule.py#L267-L268 and will therefore not match its only valid merging candidate: SM02.
opw-4368599
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#190820**[FIX] account: fix empty string and False/None inconsistencies** When empty, the `name` field of `account.move.line` could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as `label->not set` and `label == ""` yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is an empty string, standa
Original PR description
**[FIX] account: fix empty string and False/None inconsistencies** When empty, the `name` field of `account.move.line` could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as `label->not set` and `label == ""` yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior. opw-4167139 [Enterprise PR](https://github.com/odoo/enterprise/pull/73256) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187135 Forward-Port-Of: odoo/odoo#186079
When clicking on a product that is linked to multiple loyalty programs you are prompted to select one of them everytime you add one item via the ui. Steps to reproduce: ------------------- * Create 2 loyalty programs activated when buying a certain product * Open PoS and click on the product > Observation: You will get a prompt everytime you click on the product Why the fix: ------------ The variable `selected_program` is actually only usefull if the program selected is gift card or
Original PR description
When clicking on a product that is linked to multiple loyalty programs you are prompted to select one of them everytime you add one item via the ui. Steps to reproduce: ------------------- * Create 2 loyalty programs activated when buying a certain product * Open PoS and click on the product > Observation: You will get a prompt everytime you click on the product Why the fix: ------------ The variable `selected_program` is actually only usefull if the program selected is gift card or an eWallet program. So we filter it before and only prompt when the output will be usefull. opw-4187037 Forward-Port-Of: odoo/odoo#188435
Description of the issue this commit addresses: Due to the covid's economical impact, Luxembourg's government decided to apply a 1% diminished rate to some taxes to help companies recover from the crisis. Now that this period is over, those rates aren't right anymore and should be brought back to their original value in the OSS mapping. --- Desired behavior after this commit is merged: Rates that had been diminished by 1% are back to their original value. 16% -> 17% 7% -> 8% ---
Original PR description
Description of the issue this commit addresses: Due to the covid's economical impact, Luxembourg's government decided to apply a 1% diminished rate to some taxes to help companies recover from the crisis. Now that this period is over, those rates aren't right anymore and should be brought back to their original value in the OSS mapping. --- Desired behavior after this commit is merged: Rates that had been diminished by 1% are back to their original value. 16% -> 17% 7% -> 8% --- Enteprise PR: https://github.com/odoo/enterprise/pull/75650 task-[4369658](https://www.odoo.com/odoo/project/967/tasks/4369658) Forward-Port-Of: odoo/odoo#190816 Forward-Port-Of: odoo/odoo#189444
The logic to calculate pre-work time, working time, and post-work time has been extracted to a new method `_get_pre_post_work_time`. This refactor does not alter the existing logic but makes it reusable and easier to override in custom modules. This makes it easier to customize the calculation for specific use cases, such as only considering overtime hours worked after the scheduled end of the day. This adjustment is necessary to meet client requirements that exclude overtime before the st
Original PR description
The logic to calculate pre-work time, working time, and post-work time has been extracted to a new method `_get_pre_post_work_time`. This refactor does not alter the existing logic but makes it reusable and easier to override in custom modules. This makes it easier to customize the calculation for specific use cases, such as only considering overtime hours worked after the scheduled end of the day. This adjustment is necessary to meet client requirements that exclude overtime before the start of the working day. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189983
Steps to reproduce the bug: - Create “route 1”: - applicable on: product - Rule: - Pull from - Operation type: internal transfer - Source Location: WH/Stock/Shelf 1 - Destination Location: WH/Stock/Shelf 2 - Supply Method: Take from stock - Create a storable product “P1”: - Orderpoint: - Location: WH/Stock/Shelf 2 - Min qty: 0 - route: “route 1” - create a repair order: - product to repair: selec
Original PR description
Steps to reproduce the bug: - Create “route 1”: - applicable on: product - Rule: - Pull from - Operation type: internal transfer - Source Location: WH/Stock/Shelf 1 - Destination Location:…
Steps to reproduce the bug:
- Create “route 1”:
- applicable on: product
- Rule:
- Pull from
- Operation type: internal transfer
- Source Location: WH/Stock/Shelf 1
- Destination Location: WH/Stock/Shelf 2
- Supply Method: Take from stock
- Create a storable product “P1”:
- Orderpoint:
- Location: WH/Stock/Shelf 2
- Min qty: 0
- route: “route 1”
- create a repair order:
- product to repair: select any one
- Part: Add one unit of P1
- Go to miscellaneous:
- source location: WH/Stock/Shelf 2
- Confirm the MO
Problem:
The order point will be triggered, and a stock move will be created
but not linked to a picking. This occurs because the product to be
repaired is storable and out of stock. As a result, the wizard
indicating insufficient quantity for the product is launched, and
default_repair_id is added to the context. Consequently, the move will
be created with the repair order field set and does not need to be
assigned.
https://github.com/odoo/odoo/blob/17.0/addons/repair/models/stock_move.py#L179-L182
opw-4224710
Forward-Port-Of: odoo/odoo#190582
Forward-Port-Of: odoo/odoo#188280## Description When the `product.template.attribute.value` (PTAV) are edited and the respective `product.template.attribute` (PTA) variant creation config is set to `Instantly`, all existing variants for that template are unlinked and all the combinations possible of variants are recreated. This can be slow, specially for templates that already have a lot of variants. ## Patch Main bottleneck is the hot loop in `product.product:unlink`, rewriting it a bit to pre-compute what is possible, be
Original PR description
## Description When the `product.template.attribute.value` (PTAV) are edited and the respective `product.template.attribute` (PTA) variant creation config is set to `Instantly`, all existing variants…
## Description When the `product.template.attribute.value` (PTAV) are edited and the respective `product.template.attribute` (PTA) variant creation config is set to `Instantly`, all existing variants for that template are unlinked and all the combinations possible of variants are recreated. This can be slow, specially for templates that already have a lot of variants. ## Patch Main bottleneck is the hot loop in `product.product:unlink`, rewriting it a bit to pre-compute what is possible, before looping. - Lift `exists` check outside the loop, it does 1 query. - Batch the `search` in the main loop body of `product.product`'s `unlink` with a `_read_group`. - Replace usage of `recordset`'s `union` with `set`'s `add`, due to the loop, complexity goes from `O(n^2)` -> `O(n)` for `n := len(self)`. ## Benchmark On a DB with 1.2M `product.product`, adding a new PTAV to a `product. template` with 39k+ variants takes: | | Before | After | |---------|--------------------|--------| | Timings | timeout (ETC 3h+)* | 2.2min | \* - ETC was calculated by extrapolating the search query in the loop, which was taking ~300ms, times the number of variants to be unlinked which was 39k+ variants. ## Reference opw-4383294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190739
In odoo/odoo#180856, a new version of the Estonian tax report is added with the xmlid tax_report, in order to not overwrite the tax report for users in stable who didn't update their modules. When upgrading the module, to avoid dropping and recreating the report, we add this upgrade script to rename the xmlid of the tax report. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190718
Original PR description
In odoo/odoo#180856, a new version of the Estonian tax report is added with the xmlid tax_report, in order to not overwrite the tax report for users in stable who didn't update their modules. When upgrading the module, to avoid dropping and recreating the report, we add this upgrade script to rename the xmlid of the tax report. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190718
### [FIX] account_edi_ubl_cii,l10n_ro_edi: Allow NO VAT tax scheme ID Rule [BR-CO-09] enforce the VAT number to start with a country code if the tax scheme id is "VAT". In some countries (RO, HU, non-EU countries, ...) it is perfectly valid to have a VAT that doesn't follow this format. To avoid the rule to raise, we should set the tax scheme ID to something else than "VAT". ### [FIX] account_edi_ubl_cii: only set BIS3 format by default on restricted countries BIS3 is an electronic for
Original PR description
### [FIX] account_edi_ubl_cii,l10n_ro_edi: Allow NO VAT tax scheme ID Rule [BR-CO-09] enforce the VAT number to start with a country code if the tax scheme id is "VAT". In some countries (RO, HU,…
### [FIX] account_edi_ubl_cii,l10n_ro_edi: Allow NO VAT tax scheme ID Rule [BR-CO-09] enforce the VAT number to start with a country code if the tax scheme id is "VAT". In some countries (RO, HU, non-EU countries, ...) it is perfectly valid to have a VAT that doesn't follow this format. To avoid the rule to raise, we should set the tax scheme ID to something else than "VAT". ### [FIX] account_edi_ubl_cii: only set BIS3 format by default on restricted countries BIS3 is an electronic format closely related to Peppol. It therefore only make sense to enable it by default on partners that are in countries where it's actively used or will become mandatory soon. ### [FIX] account_edi_ubl_cii,base_vat,l10n_hu: VAT conversion to EU format Hungary may have different format of VAT number. It is possible to convert their local format (xxxxxxxx-y-zz) to the EU format (HUxxxxxxxx). We should use this converted format when computing the Peppol Endpoint. Enterprise: https://github.com/odoo/enterprise/pull/75671 task-4374458 Forward-Port-Of: odoo/odoo#189421
In January 2025, Indonesia is increasing their tax rate from 11% to 12%. This commit adds a new 12% tax as well as the upgrade script to load it into existing databases. task id # 4409300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190748 Forward-Port-Of: odoo/odoo#190693
Original PR description
In January 2025, Indonesia is increasing their tax rate from 11% to 12%. This commit adds a new 12% tax as well as the upgrade script to load it into existing databases. task id # 4409300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190748 Forward-Port-Of: odoo/odoo#190693
Steps to reproduce ================== - Archive default "Projects" workspace - Create a new Project - Create a task and attach a file - Click on the smart button to view the document - Go back to the home menu and open the documents app => `Cannot read properties of undefined (reading 'id')` Solution ======== Prevent the archiving of the projects workspace opw-4308132 Forward-Port-Of: odoo/enterprise#75659
Original PR description
Steps to reproduce ================== - Archive default "Projects" workspace - Create a new Project - Create a task and attach a file - Click on the smart button to view the document - Go back to the home menu and open the documents app => `Cannot read properties of undefined (reading 'id')` Solution ======== Prevent the archiving of the projects workspace opw-4308132 Forward-Port-Of: odoo/enterprise#75659
Steps: - Go to the Rewards page - Buy a reward - Breadcrumb and navigation menu were disappearing after the purchase Cause of the issue: - Page reload was resetting the breadcrumb and navigation Fix: - Used a soft reload instead of a full page reload to prevent the reset and preserve the breadcrumb and navigation menu task-4266538 Forward-Port-Of: odoo/enterprise#74445
Original PR description
Steps: - Go to the Rewards page - Buy a reward - Breadcrumb and navigation menu were disappearing after the purchase Cause of the issue: - Page reload was resetting the breadcrumb and navigation Fix: - Used a soft reload instead of a full page reload to prevent the reset and preserve the breadcrumb and navigation menu task-4266538 Forward-Port-Of: odoo/enterprise#74445
**[FIX] account_asset: fix empty string and False/None inconsistencies** (adapting tests) When empty, the name field of account.move.line could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as label->not set and label == "" yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is
Original PR description
**[FIX] account_asset: fix empty string and False/None inconsistencies** (adapting tests)
When empty, the name field of account.move.line could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as label->not set and label == "" yielded different outcomes. The latter behavior aligns with expected ORM operations.
This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior. We also adapt some tests to the new behavior in enterprise.
opw-4167139
[community PR](https://github.com/odoo/odoo/pull/186079)
Forward-Port-Of: odoo/enterprise#73766
Forward-Port-Of: odoo/enterprise#73256**Issue:** - Uninstalling the Field Service app will make all normal projects non-billable, resulting in the removal of customers and sales orders from their tasks. **Steps To Reproduce:** - Install the Field Service app. - Create a project and set it as billable. - Create a task for the project. set customer and sales order. - Uninstall the Field Service app. - Check the project's billable status and the task. **Solution:** - remove the `uninstall_hook` meth
Original PR description
**Issue:**
- Uninstalling the Field Service app will make all normal projects non-billable, resulting in the removal of customers and sales orders from their tasks.
**Steps To Reproduce:**
- Install the Field Service app.
- Create a project and set it as billable.
- Create a task for the project. set customer and sales order.
- Uninstall the Field Service app.
- Check the project's billable status and the task.
**Solution:**
- remove the `uninstall_hook` method since the original issue it was added for is no longer reproducable. https://github.com/odoo/enterprise/pull/32022/commits/341e68e6a3e569137aeb41d69203c731559f9ef8
opw-[4379638](https://www.odoo.com/web#id=4379638&view_type=form&model=project.task)
Forward-Port-Of: odoo/enterprise#75356Description of the issue this commit addresses: The community commit linked to this one changed the rates of luxembourgian taxes used in the oss fiscal positions. Because of that, some tests are failing. --- Desired behavior after this commit is merged: Said tests are not failing anymore. --- Community PR: https://github.com/odoo/odoo/pull/189444 task-[4369658](https://www.odoo.com/odoo/project/967/tasks/4369658) Forward-Port-Of: odoo/enterprise#75716 Forward-Port-Of: odoo/en
Original PR description
Description of the issue this commit addresses: The community commit linked to this one changed the rates of luxembourgian taxes used in the oss fiscal positions. Because of that, some tests are failing. --- Desired behavior after this commit is merged: Said tests are not failing anymore. --- Community PR: https://github.com/odoo/odoo/pull/189444 task-[4369658](https://www.odoo.com/odoo/project/967/tasks/4369658) Forward-Port-Of: odoo/enterprise#75716 Forward-Port-Of: odoo/enterprise#75650
When creating a PO/SO with inter-company rules, the related SO/PO has no fiscal position set, unless having one set on the partner. Removing the `fiscal_position_id` from the values dict allows it to be computed directly at the creation of the related SO/PO Steps: - Have 2 companies A and B - Activate inter-company rules and synchronize sale/purchase orders - With A, create a SO for B, confirm - With B, go to PO and select the related PO newy created -> There is no fiscal position opw-4247948
Original PR description
When creating a PO/SO with inter-company rules, the related SO/PO has no fiscal position set, unless having one set on the partner. Removing the `fiscal_position_id` from the values dict allows it to be computed directly at the creation of the related SO/PO Steps: - Have 2 companies A and B - Activate inter-company rules and synchronize sale/purchase orders - With A, create a SO for B, confirm - With B, go to PO and select the related PO newy created -> There is no fiscal position opw-4247948 Forward-Port-Of: odoo/enterprise#73392
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a manufacturing order for one unit of P1 - Confirm the MO - Go to the shop floor and process “OP1” - Validate the MO - Go to the SN of P1 Problem: The quality check smart button is correctly computes the number of QC linked with finished_lot or lot_id thanks to: htt
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked with SN
- Create a BoM:
- no need to component
- Add an operation “OP1” with steps
- Control by product
- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1
Problem:
The quality check smart button is correctly computes the number of QC linked with finished_lot or lot_id thanks to:
https://github.com/odoo/enterprise/pull/72693/commits/2e2a49d4ee90b20fe899ca3c199a20ad88d185ad
but they are not read in the quality check view because the domain is
not correct
opw-4361358
Forward-Port-Of: odoo/enterprise#75447**[FIX] account_consolidation: handle empty totals when formatting account lines** When processing account lines, the totals list might be empty resulting in an IndexError when trying to set auditable to false on the last column, which leads to consolidated balance to crash. This fix just makes sure that modifying the column on this line is only done when the cols actually contains some data. opw-4205722 Forward-Port-Of: odoo/enterprise#74938
Original PR description
**[FIX] account_consolidation: handle empty totals when formatting account lines** When processing account lines, the totals list might be empty resulting in an IndexError when trying to set auditable to false on the last column, which leads to consolidated balance to crash. This fix just makes sure that modifying the column on this line is only done when the cols actually contains some data. opw-4205722 Forward-Port-Of: odoo/enterprise#74938
In odoo/enterprise#70371, the manifest file for l10n_ee_rounding specifies the country 'ee'. However, since the module depends on l10n_ee_reports, adding 'countries' interferes with auto_install, leading to the module l10n_ee_rounding not being auto installed when l10n_ee_reports is installed. This commit removes the country specification from the manifest. no-task Forward-Port-Of: odoo/enterprise#75676
Original PR description
In odoo/enterprise#70371, the manifest file for l10n_ee_rounding specifies the country 'ee'. However, since the module depends on l10n_ee_reports, adding 'countries' interferes with auto_install, leading to the module l10n_ee_rounding not being auto installed when l10n_ee_reports is installed. This commit removes the country specification from the manifest. no-task Forward-Port-Of: odoo/enterprise#75676
This commit upgrades the Linkedin's versioned API to the latest available which is `202411`. As no features has been broken, nor is there any new features impacting the parts of the API we use. Only the headers are updated as explained inside their documentation. task-4273179 Forward-Port-Of: odoo/enterprise#74687
Original PR description
This commit upgrades the Linkedin's versioned API to the latest available which is `202411`. As no features has been broken, nor is there any new features impacting the parts of the API we use. Only the headers are updated as explained inside their documentation. task-4273179 Forward-Port-Of: odoo/enterprise#74687
An error occurs when the system try to raise an error message when a bank account has not client code. ```TypeError: list.append() takes no keyword arguments``` Currently in code [1] mistakenly provides multiple values via keyword arguments to the `append` method. which is incorrect. So instead of it, we need to change the formatting to pass a single argument as a string to resolve the error. Link [1]: https://github.com/odoo/enterprise/blob/07fae63e381dfa7a8035f67837f19d619600d434/l10n
Original PR description
An error occurs when the system try to raise an error message when a bank account has not client code. ```TypeError: list.append() takes no keyword arguments``` Currently in code [1] mistakenly provides multiple values via keyword arguments to the `append` method. which is incorrect. So instead of it, we need to change the formatting to pass a single argument as a string to resolve the error. Link [1]: https://github.com/odoo/enterprise/blob/07fae63e381dfa7a8035f67837f19d619600d434/l10n_jp_zengin/models/account_batch_payment.py#L77 Sentry-6128197646 Forward-Port-Of: odoo/enterprise#75475
Before this commit there was no groupby Properties. In this commit we add a filter for groupby properties in planning module. The search view is being used by two modules`planning.slot` and `planning.analysis.report` thus solution resulted in adding the filter in `planning_view_search` as it is a primary inherited view of search view base in planning.slot. task-3801551 Forward-Port-Of: odoo/enterprise#58814
Original PR description
Before this commit there was no groupby Properties. In this commit we add a filter for groupby properties in planning module. The search view is being used by two modules`planning.slot` and `planning.analysis.report` thus solution resulted in adding the filter in `planning_view_search` as it is a primary inherited view of search view base in planning.slot. task-3801551 Forward-Port-Of: odoo/enterprise#58814
Community: https://github.com/odoo/odoo/pull/189421 task-4374458 Forward-Port-Of: odoo/enterprise#75671
Original PR description
Community: https://github.com/odoo/odoo/pull/189421 task-4374458 Forward-Port-Of: odoo/enterprise#75671
Steps to Reproduce: - Install the Helpdesk app without demo data. - Navigate to the dashboard. - Observe the `SAMPLE` ribbon in the top-right corner. Cause: - The issue occurs because the SAMPLE ribbon for "Fake Data for Demo" is rendered before the helpdesk banner. Due to this loading order, the banner displays on top of the ribbon, obscuring it. Solution: - By adjusting the loading order so the ribbon loads after the helpdesk banner, we ensure the ribbon displays clearly
Original PR description
Steps to Reproduce: - Install the Helpdesk app without demo data. - Navigate to the dashboard. - Observe the `SAMPLE` ribbon in the top-right corner. Cause: - The issue occurs because the SAMPLE ribbon for "Fake Data for Demo" is rendered before the helpdesk banner. Due to this loading order, the banner displays on top of the ribbon, obscuring it. Solution: - By adjusting the loading order so the ribbon loads after the helpdesk banner, we ensure the ribbon displays clearly above the banner without additional adjustments. task: 4209920 Forward-Port-Of: odoo/enterprise#72786