Tuesday, April 30, 2024
33 changes · saas-17.1
Resolved issues and error corrections
This corrects the Czech localization accounting configuration so it uses the expected newer data structure. It helps ensure Czech companies receive the right chart of accounts, taxes, tax groups, and fiscal positions during setup or updates.
Original PR description
Fw-port #148410 was merged before smdc-odoo force-pushed his corrections. As a result, the commit that was merged 39f72f8341b0984da3a324e1a956be0e6e3af030 added chart template data in pre-16.2 format, rather than modify the post-16.2 template files. This commit fixes the fw-port.
The customer field in the portal's blocked-by task page now prioritizes customer-type contacts, matching behavior in other service-related fields. This makes it easier for portal users to find the right customer when editing task dependencies.
Original PR description
Steps: - Install project and account app. - Enable task dependancy from project. - Share project which at least have one task with blocked by task. - Open that project in portal. - Edit customer field in blocked by page. Issue: - Customer with customer type are not displaying first like we have in other partner field in service apps. Cause: - Forgot to add context on blocked-by page's partner field to display type customer first. Fix: - Added a context to work it properly. task-3716784
Users could encounter an error when opening the Project schedule in the Planning app while debug mode was enabled. This fix prevents that crash so teams can access planning schedules reliably during configuration or troubleshooting.
Original PR description
Steps: - Install `planning` - Enable debug `/web?debug=1` or assets `/web?debug=assets` - Open `planning` - Configuration - Enable "Project Planning" - Schedule/Project - Traceback ```…
Steps:
- Install `planning`
- Enable debug `/web?debug=1` or assets `/web?debug=assets`
- Open `planning`
- Configuration
- Enable "Project Planning"
- Schedule/Project
- Traceback
```
UncaughtPromiseError > OwlError
Uncaught Promise > Invalid props for component 'PlanningEmployeeAvatar':
'isResourceMaterial' is missing (should be a boolean),
'showPopover' is missing (should be a boolean),
'resourceColor' is missing (should be a number)
```
The error is clear: the `PlanningEmployeeAvatar` component used by the `Gantt` view takes in props
```js
static props = {
...Avatar.props,
isResourceMaterial: { type: Boolean},
showPopover: { type: Boolean },
resourceColor: { type: Number },
};
```
In the gantt view, we define `Avatar` props via the `avatarProps` variable
https://github.com/odoo/enterprise/blob/d8c76685d09e724ca2060b7dcbcbc062e1fa7444/planning/static/src/views/planning_gantt/planning_gantt_renderer.xml#L28-L34
https://github.com/odoo/enterprise/blob/61afda686a786d4e44d82902c995c0265d742404/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L79-L83
we use the props of the `Avatar` component inherited by our broken component.
One solution would be either to specify default values for the requested props, or to mark them as optional, which is what this commit does.
opw-3889131Miscellaneous changes
This is a temporary fix to avoid warnings when using uctnow in python 3.12. A proper fix should be to localize all timezone using datetime.now(timezone.utc) instead of datetime.utcnow(). Unfortunately this is not as straightforward as it seems, since those naive timezones are localize in the code conditionally, but not always. It may take time and an in depth review to fix all occurrence. Not sure yet in witch version we should fix it properly. While in netsvc file, removes the encod
Original PR description
This is a temporary fix to avoid warnings when using uctnow in python 3.12. A proper fix should be to localize all timezone using datetime.now(timezone.utc) instead of datetime.utcnow(). Unfortunately this is not as straightforward as it seems, since those naive timezones are localize in the code conditionally, but not always. It may take time and an in depth review to fix all occurrence. Not sure yet in witch version we should fix it properly. While in netsvc file, removes the encoding suppress warning Forward-Port-Of: odoo/odoo#163872 Forward-Port-Of: odoo/odoo#163794
Issue: A traceback error is raised when a sales order is saved with products with varying company ids. Was trying to lookup a list of ids rather than a singular id which triggered the traceback. Purpose of this PR: To check accessible company branches on a individual company rather than a recordset of companies. Steps to Reproduce on Runbot: 1) Create branch of main company. 2) Create products one with company id of the branch and the other of company id in the main company. 3) Creat
Original PR description
Issue: A traceback error is raised when a sales order is saved with products with varying company ids. Was trying to lookup a list of ids rather than a singular id which triggered the traceback. Purpose of this PR: To check accessible company branches on a individual company rather than a recordset of companies. Steps to Reproduce on Runbot: 1) Create branch of main company. 2) Create products one with company id of the branch and the other of company id in the main company. 3) Create sale order, order lines with each of the products. 4) On save, a traceback error is raised. Notes: opw-3810770 Forward-Port-Of: odoo/odoo#162547
On a customer invoice, the sentence "Please use the following communication for your payment : +++000/0000/10205+++" was changed to "Please use the following communication for your payment : +++000/0000/10205+++ on this account : BE81 3101 2528 8724" Customer invoices only had payment reference. Bank account (iban) was also needed on the invoice. task-3794432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163912
Original PR description
On a customer invoice, the sentence "Please use the following communication for your payment : +++000/0000/10205+++" was changed to "Please use the following communication for your payment : +++000/0000/10205+++ on this account : BE81 3101 2528 8724" Customer invoices only had payment reference. Bank account (iban) was also needed on the invoice. task-3794432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163912 Forward-Port-Of: odoo/odoo#157503
Description of the issue/feature this PR addresses: In the mobile view, the header has extra padding, for this reason it is not perfectly aligned with the content of the page. Current behavior before PR: The header is not aligned with the content | Desktop | Mobile | |--------|--------| |  |  | Desired
Original PR description
Description of the issue/feature this PR addresses: In the mobile view, the header has extra padding, for this reason it is not perfectly aligned with the content of the page. Current behavior before PR: The header is not aligned with the content | Desktop | Mobile | |--------|--------| |  |  | Desired behavior after PR is merged: The header is aligned with the content like desktop view https://github.com/odoo/odoo/assets/35231827/32fbe3f1-3ba8-443f-856d-26b03a0cbe13 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163705
**Version:** - saas-16.3 **Step to reproduce:** - Create a subscription product with the type set to 'product' - Create a BOM for that product with the BOM type set to 'kit' - In the component, add any product with the type 'product' - Create a sale order with the products that are created and generate an invoice - Upon creating the next invoice for the subscription product, the picking was not being generated. **Issue:** Currently, if the product type is set to 'product' and
Original PR description
**Version:** - saas-16.3 **Step to reproduce:** - Create a subscription product with the type set to 'product' - Create a BOM for that product with the BOM type set to 'kit' - In the component, add any product with the type 'product' - Create a sale order with the products that are created and generate an invoice - Upon creating the next invoice for the subscription product, the picking was not being generated. **Issue:** Currently, if the product type is set to 'product' and recurring_invoice is true, and the product has a bill of materials (BOM) with the type 'kit' the picking was not created after the first invoice. **Solution:** If the product has a subscription, the quantity for BOM kits will not be updated. task-3681597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163243 Forward-Port-Of: odoo/odoo#153173
#### [FIX] core: add invalidation of Environment's _cache_key. Changing the environment in method create() to force bin_size=False looks harmless, but it actually breaks many tests, in particular in module account. The reason is that company_dependent fields are read at the wrong place in the cache. And this is because `env._cache_key` can be polluted with old data. Make sure that `_cache_key` is cleared when resetting all the lazy properties on the environment. Only the change in
Original PR description
#### [FIX] core: add invalidation of Environment's _cache_key. Changing the environment in method create() to force bin_size=False looks harmless, but it actually breaks many tests, in particular in…
#### [FIX] core: add invalidation of Environment's _cache_key.
Changing the environment in method create() to force bin_size=False
looks harmless, but it actually breaks many tests, in particular in
module account. The reason is that company_dependent fields are read at
the wrong place in the cache. And this is because `env._cache_key` can
be polluted with old data.
Make sure that `_cache_key` is cleared when resetting all the lazy
properties on the environment. Only the change in res_user.py makes it
work, but let's not tempt the devil.
Side note: I hate caches.
#### [FIX] test_new_api: test's change that already works
Add some test cases, and also remove useless flush/invalidate.
#### [FIX] core: fix create/write on binary fields
When invoking create() or write() with a binary field, the cache of the
field was incorrect if bin_size=True was in context. Force context with
bin_size=False when putting a binary value in cache. It is particularly
important to have coherent values in the cache for `web_save`.
Also, because an environment with bin_size=False won't return the same
context cache key as one with bin_size=None, it leads to have a cache
inconstistency when we write with bin_size=False. Change Environment
method cache_key() to return the same cache key when bin_size is absent,
bin_size=None or bin_size=False.
Tests on binary fields have been updated to not rely on flush and
invalidate. We also created specific tests for the binary write() path.
#### [FIX] core: cache inconsistency when assigning related resized image field
After writing or creating on a related Image field, its cache contains
the full-size image instead of the resized one (according to its
attributes max_width and max_height). Fix it by re-setting the
the resized image on the cache at the end of the inverse method.
#### [FIX] core: flush non-attachment binary field when necessary
Non-attachment binary field needs to be flushed before reading their size,
since the latter relies on the database's binary size function.
#### [FIX] core: fix no-attachment binary for web_save
When bin_size=True is in the context, the computed no-attachment binary
was incorrectly saved to the database. The row is updated with the size
of the binary instead of the value itself (check compute_value() +
cache.set).
Fix this problem by avoiding setting the cache of the bin_size value
as dirty.
Moreover, the binary size is computed with `pg_size_pretty` for the
no-attachment binary fields. Also, in compute_value() we called
b64decode on the value that was previously encoded in base64 by
_compute_datas(). But in our case, we never use _compute_datas()
because it is not stored as an attachment. Then b64decode() doesn't
make sense in this case.
These 2 bugs are now covered by testing web_save(), where cache
consistency is required. It was first reported for this method.
#### [FIX] core: flush with the correct context
There is a typo in https://github.com/odoo/odoo/commit/ddfc2aab80933bf4abd6d81dee04cfce33f2dcd2 :
`self.with_context(context={})`, it adds "context":{} to the context
itself, instead of clearing it. It breaks the new tests of binary
fields, and it is important to flush with an empty context to write
the correct value of context-dependent fields (like binary fields).
Fix this typo.
Forward-Port-Of: odoo/odoo#160708fixes for following runbot errors: - 62449 - 62452 Forward-Port-Of: odoo/odoo#163795
Original PR description
fixes for following runbot errors: - 62449 - 62452 Forward-Port-Of: odoo/odoo#163795
Starting with Odoo 16.1, the ECMAScript version supported by Odoo has been bumped to ES2022, but support for all ES2022 features has only been achieved with Node.js 16.11*, making it the minimum required version to run Odoo. This commit updates the package.json to make this requirement explicit, preventing from using the tooling with an outdated version of Node.js, which would otherwise result in an unclear syntax error. *: From all the features added in ES2022, support for static initiali
Original PR description
Starting with Odoo 16.1, the ECMAScript version supported by Odoo has been bumped to ES2022, but support for all ES2022 features has only been achieved with Node.js 16.11*, making it the minimum required version to run Odoo. This commit updates the package.json to make this requirement explicit, preventing from using the tooling with an outdated version of Node.js, which would otherwise result in an unclear syntax error. *: From all the features added in ES2022, support for static initialization blocks is the latest to have been added, in Node.js 16.11, according to MDN's compatibility data. Forward-Port-Of: odoo/odoo#163787
Make the mininum version of Python a variable so that it can be easily retrieved and used by the code. For example, it could be used to detect when a monkey patch should be removed. Forward-Port-Of: odoo/odoo#163605 Forward-Port-Of: odoo/odoo#156774
Original PR description
Make the mininum version of Python a variable so that it can be easily retrieved and used by the code. For example, it could be used to detect when a monkey patch should be removed. Forward-Port-Of: odoo/odoo#163605 Forward-Port-Of: odoo/odoo#156774
### Current Issue: When we have an accrual plan where the accrued time is allocated at the start of the accrual period and we set the allocation start time in the past, the plan will be processed but `already_accrued` will not be saved. ### Example: - We have an accrual plan that allocates 1 day per month at the start of the accrual period. Milestone reached 0 days after allocation start. - We set the start date of the allocation to 2024-01-01, the current date is 2024-03-15. The number
Original PR description
### Current Issue: When we have an accrual plan where the accrued time is allocated at the start of the accrual period and we set the allocation start time in the past, the plan will be processed but `already_accrued` will not be saved. ### Example: - We have an accrual plan that allocates 1 day per month at the start of the accrual period. Milestone reached 0 days after allocation start. - We set the start date of the allocation to 2024-01-01, the current date is 2024-03-15. The number of days are calculated to 3.00 (jan, feb, mar). - We save the record, `already_accrued` is not saved (defaults to false) - When the scheduled action runs (2024-04-01), it will allocate 2 days instead of 1 ### Solution: This commit fixes this behavior by adding the `already_accrued` field to the form view so that it is saved when the record is created. opw-3851320 Forward-Port-Of: odoo/odoo#161508
Steps to reproduce: - in A1, type '02/2024' - in A2, type '=ODOO.BALANCE("100", A1)' - right click on A2 - click the menu item "See record" => you end up with wrong records in the list view The value of A1 is detected as a number (first of february 2024) When that number is given as the argument of ODOO.BALANCE, the number falls back as being interpreted as a single day, instead of a month period. opw-3872445 Description of the issue/feature this PR addresses: Current behavior be
Original PR description
Steps to reproduce:
- in A1, type '02/2024'
- in A2, type '=ODOO.BALANCE("100", A1)'
- right click on A2
- click the menu item "See record" => you end up with wrong records in the list view
The value of A1 is detected as a number (first of february 2024) When that number is given as the argument of ODOO.BALANCE, the number falls back as being interpreted as a single day, instead of a month period.
opw-3872445
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#163156This is a backport of odoo/odoo#159671 This commit adds the requirements in order to add the bidimensional code on the receipt of the point of sale for the Chilean localization. task-id: 3747828 Enterprise PR: odoo/enterprise#60451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161342
Original PR description
This is a backport of odoo/odoo#159671 This commit adds the requirements in order to add the bidimensional code on the receipt of the point of sale for the Chilean localization. task-id: 3747828 Enterprise PR: odoo/enterprise#60451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161342
Reproduce Create some `expense`, approve some of them Expected: On journal dashboard, The `Expense Journal` need to display Number of Expense to process Actual: `number_expenses_to_pay` does not display on The `Expense Journal` because we haven't override the needed method yet Also this PR aim to improve the `open_expenses_action` to display correctly the number of expense on the journal dashboard Video to reproduce on runbot 25/09/2023 https://github.com/odoo/odoo/assets/5678
Original PR description
Reproduce Create some `expense`, approve some of them Expected: On journal dashboard, The `Expense Journal` need to display Number of Expense to process Actual: `number_expenses_to_pay` does not display on The `Expense Journal` because we haven't override the needed method yet Also this PR aim to improve the `open_expenses_action` to display correctly the number of expense on the journal dashboard Video to reproduce on runbot 25/09/2023 https://github.com/odoo/odoo/assets/56789189/6d4a4c14-1551-40af-84ae-9ce9a7e4a666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139971 Forward-Port-Of: odoo/odoo#136232
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. task-3672445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161658 Forward-Port-Of: odoo/odoo#155223
Original PR description
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. task-3672445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161658 Forward-Port-Of: odoo/odoo#155223
Steps to reproduce: 1) Create a quotation and confirm it 2) Invoice a first down payment (fixed amount) and validate it 3) Invoice the rest of the SO amount and validate it 4) Create a credit note for the last invoice created (at step 3)) 5) From the SO, re-invoice the rest of the SO amount Issue: the amount of the downpayment is added to the total, not subtracted opw-3817440 Forward-Port-Of: odoo/odoo#161350
Original PR description
Steps to reproduce: 1) Create a quotation and confirm it 2) Invoice a first down payment (fixed amount) and validate it 3) Invoice the rest of the SO amount and validate it 4) Create a credit note for the last invoice created (at step 3)) 5) From the SO, re-invoice the rest of the SO amount Issue: the amount of the downpayment is added to the total, not subtracted opw-3817440 Forward-Port-Of: odoo/odoo#161350
**Description of the issue/feature this PR addresses:** This PR address the issue of redirecting to courses page with /invite_error when trying to update the optimize seo. **Current behavior before PR:** Previously, when editing Optimize SEO and clicking "Save," it redirected to /invite_error in Courses instead of remaining on the same URL after saving, which was caused due to not receiving seoName. **Desired behavior after PR is merged:** Now after saving, we stay on the same course U
Original PR description
**Description of the issue/feature this PR addresses:** This PR address the issue of redirecting to courses page with /invite_error when trying to update the optimize seo. **Current behavior before PR:** Previously, when editing Optimize SEO and clicking "Save," it redirected to /invite_error in Courses instead of remaining on the same URL after saving, which was caused due to not receiving seoName. **Desired behavior after PR is merged:** Now after saving, we stay on the same course URL without being redirected to /invite_error. This fix includes checking if the seoContext doesn't have a seoName , in which case we redirect to seoNameDefault to prevent redirection to /invite_error on the Courses page. **Task**-3688285 Forward-Port-Of: odoo/odoo#161029
Delivery and loyalty discount lines were already disregarded when computing the invoice status if they were the only lines to invoice, but new logic of discount lines, introduced in 17 with bf95b1f2ade01a79263461987e62d3b5b1b09483, didn't consider this situation. This commit harmonizes the existing logic of `loyalty` & `delivery`, directly in `sale`, making sure this is correctly handled at once for the three cases. opw-3853012 --- I confirm I have signed the CLA and read the PR guid
Original PR description
Delivery and loyalty discount lines were already disregarded when computing the invoice status if they were the only lines to invoice, but new logic of discount lines, introduced in 17 with bf95b1f2ade01a79263461987e62d3b5b1b09483, didn't consider this situation. This commit harmonizes the existing logic of `loyalty` & `delivery`, directly in `sale`, making sure this is correctly handled at once for the three cases. opw-3853012 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161563
Add a new tax, Exento, to the master data of the module l10n_mx, change the fiscal position 'Foreign Customer' and add a new tax group for Exento. Add the Exento tax recognition for the XML reader for vendor bills. task id : 3774996 Forward-Port-Of: odoo/odoo#163662 Forward-Port-Of: odoo/odoo#160624
Original PR description
Add a new tax, Exento, to the master data of the module l10n_mx, change the fiscal position 'Foreign Customer' and add a new tax group for Exento. Add the Exento tax recognition for the XML reader for vendor bills. task id : 3774996 Forward-Port-Of: odoo/odoo#163662 Forward-Port-Of: odoo/odoo#160624
Before this commit, alarms were always being set up when there was no 'next_date' specified, creating an undeterministic behavior since inside the 'get_next_alarm_date' function we check if the 'call_at' attribute from the trigger happens before 'now'. If this condition is false, i.e. if there is already an alarm set up for the future, we were returning a falsy value for the next alarm date and setting up the alarm anyway (using the current date inside '_setup_alarms', since the context was None
Original PR description
Before this commit, alarms were always being set up when there was no 'next_date' specified, creating an undeterministic behavior since inside the 'get_next_alarm_date' function we check if the 'call_at' attribute from the trigger happens before 'now'. If this condition is false, i.e. if there is already an alarm set up for the future, we were returning a falsy value for the next alarm date and setting up the alarm anyway (using the current date inside '_setup_alarms', since the context was None), thus generating a new alarm with the wrong call date. After this commit, we make an extra check for recurrences in the 'get_next_alarm_date' function in order to get the correct next date for the next alarm from the next recurrent event. Additionally, if there is no next date to be called in the in the future, we skip the 'send_reminder' function which was wrongly creating another alarm using 'now' as time. Issue-from: odoo/odoo#147914 Forward-Port-Of: odoo/odoo#161941
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to reproduce the issue: ============================= - Go to to-do - add a table on top the editable - Hover on the top left cell - The row and col ui boxes doesn't show correctl Origin of the issue: ==================== Since we forced the mentioned commit that `overflow-x` should be hid
Original PR description
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to…
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to reproduce the issue: ============================= - Go to to-do - add a table on top the editable - Hover on the top left cell - The row and col ui boxes doesn't show correctl Origin of the issue: ==================== Since we forced the mentioned commit that `overflow-x` should be hidden, then the ui elements which overflows the visible area of the html field will be hdden too that's why only a small part of them appear. Solution: ========= To conserve the same ui and not add extra padding , we add padding to the `note-editable` to make it possible to display the ui elements fully (needs 16px) and decrease the padding of the padding of the formView sheet. Before: ======  After: =====  task-3861784 Forward-Port-Of: odoo/odoo#162029
- When creating a new invoice the payment method is "Por definir" by default, so it is necessary to check the l10n_mx_edi_payment_method_id of the customer used in the invoice before checking the l10n_mx_edi_payment_method_id of the invoice and replacing it if the customer has this value assigned or use the corresponding payment method. Description of the issue/feature this PR addresses: 1. Configure the Payment way and the Usage in the partner. ![image](https://github.com/odoo/
Original PR description
- When creating a new invoice the payment method is "Por definir" by default, so it is necessary to check the l10n_mx_edi_payment_method_id of the customer used in the invoice before checking the…
- When creating a new invoice the payment method is "Por definir" by default, so it is necessary to check the l10n_mx_edi_payment_method_id of the customer used in the invoice before checking the l10n_mx_edi_payment_method_id of the invoice and replacing it if the customer has this value assigned or use the corresponding payment method. Description of the issue/feature this PR addresses: 1. Configure the Payment way and the Usage in the partner.  2. Create a new invoice and select the partner configured in number 1.  The payment way doesn't change, it is "Por definir" by default. Desired behavior after PR is merged: After this is merged the invoice payment method will be the same as assigned in the partner.  Forward-Port-Of: odoo/enterprise#61114
**Version:** - saas-16.3 **Step to reproduce:** - Create a subscription product with the type set to 'product' - Create a BOM for that product with the BOM type set to 'kit' - In the component, add any product with the type 'product' - Create a sale order with the products that are created and generate an invoice - Upon creating the next invoice for the subscription product, the picking was not being generated. **Issue:** Currently, if the product type is set to 'product' and
Original PR description
**Version:** - saas-16.3 **Step to reproduce:** - Create a subscription product with the type set to 'product' - Create a BOM for that product with the BOM type set to 'kit' - In the component, add any product with the type 'product' - Create a sale order with the products that are created and generate an invoice - Upon creating the next invoice for the subscription product, the picking was not being generated. **Issue:** Currently, if the product type is set to 'product' and recurring_invoice is true, and the product has a bill of materials (BOM) with the type 'kit' the picking was not created after the first invoice. **Solution:** If the product has a subscription, the quantity for BOM kits will not be updated. task-3681597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#61415 Forward-Port-Of: odoo/enterprise#56121
**Version:** - saas-16.3 **Step to reproduce:** - renew a sale order - click on the renewal quote stat button and change the state=sent quotation - the renewal button will disappear from the confirmed sale order form view **Issue:** The renewal quote stat button in the subscription module's sale order form view is only visible when the sale order is in the draft state. **Solution:** The renewal quote stat button will now be displayed even when the sale order is in the sent sta
Original PR description
**Version:** - saas-16.3 **Step to reproduce:** - renew a sale order - click on the renewal quote stat button and change the state=sent quotation - the renewal button will disappear from the confirmed sale order form view **Issue:** The renewal quote stat button in the subscription module's sale order form view is only visible when the sale order is in the draft state. **Solution:** The renewal quote stat button will now be displayed even when the sale order is in the sent state. task-3593973 <hr/> I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#52992 Forward-Port-Of: odoo/enterprise#52865
Before this commit: when editing a sign template and opening the sign item popover, it remained open when clicking away even when leaving the sign app. This commit addresses this issue by refining the `closeOnClickAway` to close the popover only if the click is not within an active modal, ensuring that the popover stays open when the role modal is displayed. Task: 3861496 _______________________________________________________________ Bug was introduced in this PR: https://github.com/
Original PR description
Before this commit: when editing a sign template and opening the sign item popover, it remained open when clicking away even when leaving the sign app. This commit addresses this issue by refining the `closeOnClickAway` to close the popover only if the click is not within an active modal, ensuring that the popover stays open when the role modal is displayed. Task: 3861496 _______________________________________________________________ Bug was introduced in this PR: https://github.com/odoo/enterprise/pull/49900 in attempt to keep the popover open when updating the sign item role. Forward-Port-Of: odoo/enterprise#60613
Before this commit: =========== - The balance column text on the partner screen had a low shade, diminishing its visibility. After this commit: =========== - The balance column text in the partner screen has a high shade, improving its visibility. task-3877793 Forward-Port-Of: odoo/enterprise#61127
Original PR description
Before this commit: =========== - The balance column text on the partner screen had a low shade, diminishing its visibility. After this commit: =========== - The balance column text in the partner screen has a high shade, improving its visibility. task-3877793 Forward-Port-Of: odoo/enterprise#61127
Summary ----- When you try to display the spanish tax report, model 347, if you have too much partners with few small transactions (the sum is lower than 3005.06€), an error is raised. Steps to reproduce ----- 1. Install the l10n_es module 2. Create 30,000 invoices with an amount of 1€, and each having a distinct partner linked 3. Open the model 347: Accounting > Reporting > Tax Report, and select the report called "Tax Report (Mod 347)(ES)" and a date range large enough 4. Observe the
Original PR description
Summary ----- When you try to display the spanish tax report, model 347, if you have too much partners with few small transactions (the sum is lower than 3005.06€), an error is raised. Steps to reproduce ----- 1. Install the l10n_es module 2. Create 30,000 invoices with an amount of 1€, and each having a distinct partner linked 3. Open the model 347: Accounting > Reporting > Tax Report, and select the report called "Tax Report (Mod 347)(ES)" and a date range large enough 4. Observe the very long UserError Cause ----- Too much partners must be excluded and the list of this partners are added to a domain which becomes very long and an error is raised when we use the function ast.literal_eval on it. Fix ----- The list of the excluded partners are passed in the "forced_domain" options. Like that, the ast.literal_eval function is not applied on it and the error is not raised. opw-3770944 Forward-Port-Of: odoo/enterprise#61452
This is a backport of odoo/enterprise#58479 This commit adds the bidimensional code on the receipt, it also adds to the receipt header the requirements for considering the receipt as a valid electronic document. task-id: 3747828 Community PR: odoo/odoo#161342 Forward-Port-Of: odoo/enterprise#60451
Original PR description
This is a backport of odoo/enterprise#58479 This commit adds the bidimensional code on the receipt, it also adds to the receipt header the requirements for considering the receipt as a valid electronic document. task-id: 3747828 Community PR: odoo/odoo#161342 Forward-Port-Of: odoo/enterprise#60451
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. Forward-Port-Of: odoo/enterprise#61557 Forward-Port-Of: odoo/enterprise#57367
Original PR description
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. Forward-Port-Of: odoo/enterprise#61557 Forward-Port-Of: odoo/enterprise#57367
[IMP] l10n_mx : Update master data with new Exento tax and fix the XML reader issues Add a new tax, Exento, to the master data of the module l10n_mx, change the fiscal position 'Foreign Customer' and add a new tax group for Exento. Add the Exento tax recognition for the XML reader for vendor bills. task id: 3774996 Forward-Port-Of: odoo/enterprise#61613 Forward-Port-Of: odoo/enterprise#60107
Original PR description
[IMP] l10n_mx : Update master data with new Exento tax and fix the XML reader issues Add a new tax, Exento, to the master data of the module l10n_mx, change the fiscal position 'Foreign Customer' and add a new tax group for Exento. Add the Exento tax recognition for the XML reader for vendor bills. task id: 3774996 Forward-Port-Of: odoo/enterprise#61613 Forward-Port-Of: odoo/enterprise#60107
Withholding tax lines should not appear in the Libro de IVA export, where only base lines and Tax Lines of IVA (=VAT) taxes should be reported. task-3875272 Forward-Port-Of: odoo/enterprise#61206
Original PR description
Withholding tax lines should not appear in the Libro de IVA export, where only base lines and Tax Lines of IVA (=VAT) taxes should be reported. task-3875272 Forward-Port-Of: odoo/enterprise#61206