Wednesday, December 18, 2024
80 changes
9 changes
Miscellaneous changes
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
### [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
## 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
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
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
### 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#190820Steps to reproduce: - Insert a pivot in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the pivot side panel, update something (move up a dimension) - Save => The domain does not take the global filter into account Task: 4398645 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 guid
Original PR description
Steps to reproduce: - Insert a pivot in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the pivot side panel, update something (move up a dimension) - Save => The domain does not take the global filter into account Task: 4398645 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#190848 Forward-Port-Of: odoo/odoo#190781
### Initial issue: On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location ### This issue was fixed in: - 17.0 by: https://github.com/odoo/odoo/commit/6b158aa333cf111472e4b850543b8379f0e998b7 - saas-17.2+ by: https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36 However, there is a tiny corner case where the fix of 17.0 is better than the one of saas-17.2: If you were to put hal
Original PR description
### Initial issue: On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location ### This issue was fixed in: - 17.0 by:…
### Initial issue: On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location ### This issue was fixed in: - 17.0 by: https://github.com/odoo/odoo/commit/6b158aa333cf111472e4b850543b8379f0e998b7 - saas-17.2+ by: https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36 However, there is a tiny corner case where the fix of 17.0 is better than the one of saas-17.2: If you were to put half of a lot in a pack in a sublocation and the other half eslewhere, the current fix of saas-17.2 would not use the sublocation that is however available as it relies on the 'location_id' field of the `stock.lot` model which will not be set in that valid use case: https://github.com/odoo/odoo/blob/d9cca6201a39c431deaf13891a314dde2db7e82e/addons/stock/models/stock_lot.py#L155-L159 The purpose of the present PR is to reconcile both fix by reverting the current one and by adapting the test to both usecases. Revert "[FIX] stock: start SML from sub location" This reverts commit https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36. X-original-commit: https://github.com/odoo/odoo/commit/28f5b2244954a8aaa2a7c2599b0716c88a55e5f0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188840
We get an access error when trying to register a vendor payment with a user having access only to a branch company. Steps: - Create a branch B - Create a user U with company_id and company_ids being B - Log as user U - Create and confirm a vendor bill - Open the 'Register payment' wizard and try to create a payment -> Access Error on company id opw-4317289 Forward-Port-Of: odoo/odoo#188512
Original PR description
We get an access error when trying to register a vendor payment with a user having access only to a branch company. Steps: - Create a branch B - Create a user U with company_id and company_ids being B - Log as user U - Create and confirm a vendor bill - Open the 'Register payment' wizard and try to create a payment -> Access Error on company id opw-4317289 Forward-Port-Of: odoo/odoo#188512
16 changes
Resolved issues and error corrections
German DATEV exports now remove line breaks from accounting entry descriptions by replacing them with spaces. This prevents invalid export files when descriptions contain multi-line text, helping businesses share accounting data more reliably.
Original PR description
In the datev export, we cannot use any linebreak. But in the aml name you could have some, to fix this we just replace any linebreak by a simple space task: 4358246
Miscellaneous changes
Issue: When 'website' is installed a singleton error is thrown when duplicating multiple users In previous versions, such as [17.0] The copy method would be called multiple times, once per record. However, starting with version 17.2+, self becomes a record set that can potentially contain multiple records, which changes the behavior. res.users(1), res.users(2) --> res.users(1,2) see IMP: [#154132](https://github.com/odoo/odoo/pull/154132) Steps to reproduce: - Install 'website' - N
Original PR description
Issue: When 'website' is installed a singleton error is thrown when duplicating multiple users In previous versions, such as [17.0] The copy method would be called multiple times, once per record. However, starting with version 17.2+, self becomes a record set that can potentially contain multiple records, which changes the behavior. res.users(1), res.users(2) --> res.users(1,2) see IMP: [#154132](https://github.com/odoo/odoo/pull/154132) Steps to reproduce: - Install 'website' - Navigate to user list view (Settings / Users & Companies / Users) - Select multiple users and try to duplicate them Current behavior before PR: - ValueError: Expected singleton Desired behavior after PR is merged: - Resolves expected singleton error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190690 Forward-Port-Of: odoo/odoo#189666
Description of the issue/feature this PR addresses: - On the error message when we check the lot and it's linked to another product it displays the location_id instead of the lot_id which isn't correct. Current behavior before PR: - Incorrect displayed value in the error message. Desired behavior after PR is merged: - Replace the location name with the lot name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/od
Original PR description
Description of the issue/feature this PR addresses: - On the error message when we check the lot and it's linked to another product it displays the location_id instead of the lot_id which isn't correct. Current behavior before PR: - Incorrect displayed value in the error message. Desired behavior after PR is merged: - Replace the location name with the lot name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190165
Steps to reproduce: - Install helpdesk_stock and Studio - Create 3 contacts, 1 company and two child employees - Create a quotation for each contact with a different product - Helpdesk app > Create a ticket - Add the Product ('product_id') field with studio - (Under 'Existing Fields' search product) - (View tab > Show invisible elements > Find product field > untick invisible) The products from contacts linked to the parent company should appear, but only those related to SOs from the
Original PR description
Steps to reproduce:
- Install helpdesk_stock and Studio
- Create 3 contacts, 1 company and two child employees
- Create a quotation for each contact with a different product
- Helpdesk app > Create a ticket
- Add the Product ('product_id') field with studio
- (Under 'Existing Fields' search product)
- (View tab > Show invisible elements > Find product field > untick invisible)
The products from contacts linked to the parent company should appear, but only those related to SOs from the contact itself or its parent company are shown (i.e. We should see all 3 products no matter which contact is set as customer).
This is related to https://github.com/odoo/enterprise/pull/73391, which was a step in the right direction but still insufficient. Unlike that fix however this one is relevant up to master.
opw-4285382
Forward-Port-Of: odoo/enterprise#75766
Forward-Port-Of: odoo/enterprise#74361### Issue: Worksheet quality checks can not be validated if they bypass the Quality wizzard, e.g. when when there is no notes on the QC and it is not related to worksheet data's. ### Steps to reproduce: - Install `quality_control_worksheet` - Create a BOM for a product with an operation + add instr (list icon): - Control per operation, type: worksheet, template: Quality issues - Create ans confirm an MO for 1 unit of your product - Go to the shopfloor and fill the worksheet > Sa
Original PR description
### Issue: Worksheet quality checks can not be validated if they bypass the Quality wizzard, e.g. when when there is no notes on the QC and it is not related to worksheet data's. ### Steps to…
### Issue:
Worksheet quality checks can not be validated if they bypass the Quality wizzard, e.g. when when there is no notes on the QC and it is not related to worksheet data's.
### Steps to reproduce:
- Install `quality_control_worksheet`
- Create a BOM for a product with an operation + add instr (list icon):
- Control per operation, type: worksheet, template: Quality issues
- Create ans confirm an MO for 1 unit of your product
- Go to the shopfloor and fill the worksheet > Save
#### > You are never able to validate the instruction and hence the WO can never be marked as done.
### Cause of the issue:
Since ee1913d7080f6aee06dac004d56203f2c09d4bad (saas-17.2) e.g the change on the "if" condition:
https://github.com/odoo/enterprise/blob/4238d6b071a57b3378968064ad322ea39a8b1294/quality_control_worksheet/static/src/views/quality_worksheet_fromview.js#L23-L28
the worksheet quality check is not marked as passed by the `action_worksheet_check` when the record is saved if no `quality_wizard_id` is set in the context. It is therefore expected to mark the quality check as passed only if it set through the validate button of the worksheet dialog. However, if the quality check does not have specific data's such as notes or a worksheet url, the worksheet dialog will be bypassed and there will not be a `quality_wizard_id` in the context of the action returned by `this.openWorksheet`:
https://github.com/odoo/enterprise/blob/4238d6b071a57b3378968064ad322ea39a8b1294/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L357-L362
https://github.com/odoo/enterprise/blob/0353a4c4307c2ac8d5a109a0e49be34a510e99ef/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L82-L85
https://github.com/odoo/enterprise/blob/0353a4c4307c2ac8d5a109a0e49be34a510e99ef/quality_mrp_workorder_worksheet/models/quality.py#L25-L27
It is therefore impossible to validate the quality check by any mean. Furthermore, the mark as done button of the WO is only visible once all the QC are either "pass" or "fail".
### Fix:
If we were to call the `action_open_quality_check_wizard` rather than the `action_quality_worksheet` the same action would be used but with an additional wizard would be in the context:
https://github.com/odoo/enterprise/blob/0353a4c4307c2ac8d5a109a0e49be34a510e99ef/quality_control_worksheet/models/quality.py#L53-L67
That way, if the `this.openWorksheet` is called without a worksheet dialog we will always have a wizard to rely on for the `action_worksheet_check` to be performed `onRecordSaved`.
### Other issue:
In the bypass condition is wrongly set since the `operation_note` field is used but is not defined on the `quality.check` model: https://github.com/odoo/enterprise/blob/4238d6b071a57b3378968064ad322ea39a8b1294/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L358 This condition should rather refer to the `note` field and the length should be used to determine if the string is falsy...
opw-4347352 and opw-4354876
---
Forward-Port-Of: odoo/enterprise#75548
Forward-Port-Of: odoo/enterprise#75137When 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#75795 Forward-Port-Of: odoo/enterprise#73392
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
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/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
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#75788 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#75788 Forward-Port-Of: odoo/enterprise#74687
**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#75356In 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
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#75447Community: 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
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
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