Friday, November 22, 2024
39 changes · saas-17.4
Resolved issues and error corrections
Fixed a regression that caused requests for quotation to use an inconsistent DIN 5008 document layout. This keeps RFQ documents aligned with purchase orders, improving document consistency for users working with German business formatting.
Original PR description
Commit ab5b806ced3a72f04af9b92f1ec8c32e9a03f4d7 introduced a regression by moving the computation logic for the DIN 5008 layout from Python into the XML template report_purchaseorder_document. However, the same logic was not applied to report_purchasequotation_document, which is used for RFQs, causing discrepancies in the RFQ layout. task-4089521
Draft upsell orders now refresh their link to the correct parent order line when the original subscription order changes. This helps avoid inconsistencies that could affect subscription-related customizations and downstream business processes.
Original PR description
Before this commit, when an upsell order was in draft and the parent order was modified (another upsell was confirmed or the parent order was modified directly), the parent_line compute was not trigerred. It could cause issues in customizations.
Miscellaneous changes
Before this commit, the invalid `many2many_tags_avatar` input has two layers of transparent background-color so the two colors stack one uppon the other one and so we had a inconsitancy color with others invalid field. This commit adds the `.o_field_many2many_tags_avatar` so the following CSS rules are also apply like on the `.o_field_many2many_tags`. And so the child input has `background-color: transparent` when the input is invalid. ```css .o_input { --o-input-background-color: transp
Original PR description
Before this commit, the invalid `many2many_tags_avatar` input has two layers of transparent background-color so the two colors stack one uppon the other one and so we had a inconsitancy color with others invalid field.
This commit adds the `.o_field_many2many_tags_avatar` so the following CSS rules are also apply like on the `.o_field_many2many_tags`. And so the child input has `background-color: transparent` when the input is invalid.
```css
.o_input {
--o-input-background-color: transparent;
}
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#188256Issue: When using non-stored fields as trigger_field_ids in an automation rule, old values will not be updated due to the following condition: `and record._fields[field_name].store` This condition prevents a write from occurring, as old_vals will not be retrieved when we pass the context to: `old_vals = self._context['old_values'].get(record.id, {})` Without old_vals, there are no detected differences, so the _check_trigger_fields function returns False instead of recognizing the update
Original PR description
Issue: When using non-stored fields as trigger_field_ids in an automation rule, old values will not be updated due to the following condition: `and record._fields[field_name].store` This condition…
Issue:
When using non-stored fields as trigger_field_ids in an automation rule, old values will not be updated due to the following condition:
`and record._fields[field_name].store`
This condition prevents a write from occurring, as old_vals will not be retrieved when we pass the context to:
`old_vals = self._context['old_values'].get(record.id, {})`
Without old_vals, there are no detected differences, so the _check_trigger_fields function returns False instead of recognizing the updated field.
This condition was recently added as a bug fix in the following ticket:
Ticket: opw-4106799
PR: #180965
As a result, non-stored fields can no longer be used as trigger fields.
Current behavior before PR:
non-stored fields do not trigger automation rules
Desired behavior after PR is merged:
prevent users from selecting non-stored fields as trigger fields
------------Steps----------
Steps to reproduce (opw-4207855):
1.) Create an automated action.
2.) Trigger: Set to "On Save."
3.) Leave "Before Update" and "Apply On" as default.
4.) When updating (trigger_field_ids): any non-stored field
Step to reproduce prior to pr (PR: #180965, opw-4106799)
1.) Create an automation rule on the Project model.
2.) Set Trigger to "On Save."
3.) Leave the remaining settings as default.
4.) Try to prioritize or deprioritize a project
5.) the project will not be starred until refreshed, or if clicked again, causing the rule to run twice (toggling the star each time).
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#186160Steps to reproduce: ------------------- - Make a sale order in the **Sale** app - Confirm sale order - Create invoice of Downpayment - Type 50% - Confirm invoice > Observation: Access error: pos_order_line_ids (allowed for groups 'Point of sale / Users') Why the fix: ------------ Users who do not belong to the point_of_sale.group_pos_user group get the error when they try to confirm an invoice of downpayment. User that have admin rights on accounting but are not users of pos shou
Original PR description
Steps to reproduce: ------------------- - Make a sale order in the **Sale** app - Confirm sale order - Create invoice of Downpayment - Type 50% - Confirm invoice > Observation: Access error: pos_order_line_ids (allowed for groups 'Point of sale / Users') Why the fix: ------------ Users who do not belong to the point_of_sale.group_pos_user group get the error when they try to confirm an invoice of downpayment. User that have admin rights on accounting but are not users of pos should still be able to invoice downpayments. Introduced here: https://github.com/odoo/odoo/commit/370f3bc opw-[4352799](https://www.odoo.com/web#id=4352799&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#188204
Problem: When both l10n_au and l10_nz are installed, the company form displays multiple labels for affected fields, vat and company_registry. Solution: The company form should only display a label per field to avoid confusions. Each view per localization will make the affected field on the parent view invisible and then add in the same affected fields but with a different label. Steps to Reproduce on Runbot: 1. Install l10_au and l10_nz 2. Observe the forms for all companies 3. See
Original PR description
Problem: When both l10n_au and l10_nz are installed, the company form displays multiple labels for affected fields, vat and company_registry. Solution: The company form should only display a label per field to avoid confusions. Each view per localization will make the affected field on the parent view invisible and then add in the same affected fields but with a different label. Steps to Reproduce on Runbot: 1. Install l10_au and l10_nz 2. Observe the forms for all companies 3. See that there's duplicate labels for fields, vat and company_registry opw-4250742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184806
Bank statement lines created from the form view won't have an `internal_index` value set yet. Running balance computation should set a value also on manually deleted lines from the form view as the balance is a computed non-stored field. @Tecnativa TT50906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182497
Original PR description
Bank statement lines created from the form view won't have an `internal_index` value set yet. Running balance computation should set a value also on manually deleted lines from the form view as the balance is a computed non-stored field. @Tecnativa TT50906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182497
Before this commit, messages sent by OdooBot would remain unread. 1. Log in as demo user 2. Open OdooBot chat, remains unread This happens because the `_set_last_seen_message` method called by the OdooBot reply logic sets the message as seen for the user. This results in the message being marked as read before it is received, preventing it to be marked as read by the client. This commit fixes the issue by preventing the message to be mark as read if the author is not the current user. A
Original PR description
Before this commit, messages sent by OdooBot would remain unread. 1. Log in as demo user 2. Open OdooBot chat, remains unread This happens because the `_set_last_seen_message` method called by the OdooBot reply logic sets the message as seen for the user. This results in the message being marked as read before it is received, preventing it to be marked as read by the client. This commit fixes the issue by preventing the message to be mark as read if the author is not the current user. Also added missing `message_unread_counter_bus_id` from `assignedDefined` that would prevent it to be set by record inserts. task-4295630 opw-4316799 Forward-Port-Of: odoo/odoo#187506 Forward-Port-Of: odoo/odoo#186742
*: l10n_account_edi_ubl_cii_tests Fix rounding issue with the early payment discount. I used the client's setup in the test to replicate the exact problem. opw-4245127 Forward-Port-Of: odoo/odoo#186811
Original PR description
*: l10n_account_edi_ubl_cii_tests Fix rounding issue with the early payment discount. I used the client's setup in the test to replicate the exact problem. opw-4245127 Forward-Port-Of: odoo/odoo#186811
[Runbot Error 107975](https://runbot.odoo.com/web#id=107975&model=runbot.build.error) Forward-Port-Of: odoo/odoo#188228
Original PR description
[Runbot Error 107975](https://runbot.odoo.com/web#id=107975&model=runbot.build.error) Forward-Port-Of: odoo/odoo#188228
**Problem**: When items come from a different JavaScript context (e.g., an iframe, a web worker, or a shadow DOM), their prototype chain may not match the `Attr` class in the current global scope. This mismatch leads to issues in detecting node types correctly. **Solution**: Use `attr.nodeType === Node.ATTRIBUTE_NODE` to check for attribute nodes. This approach is more resilient and works across different JavaScript contexts. **Steps to reproduce**: 1. Navigate to the Email Marketing ap
Original PR description
**Problem**: When items come from a different JavaScript context (e.g., an iframe, a web worker, or a shadow DOM), their prototype chain may not match the `Attr` class in the current global scope. This mismatch leads to issues in detecting node types correctly. **Solution**: Use `attr.nodeType === Node.ATTRIBUTE_NODE` to check for attribute nodes. This approach is more resilient and works across different JavaScript contexts. **Steps to reproduce**: 1. Navigate to the Email Marketing app. 2. Copy text with a hyperlink from any website. 3. Paste the copied text into the email body. 4. Observe that the text is pasted, but the link is empty due to incorrect node type detection. opw-4345535 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187988
Steps to reproduce: - Enter in Website edit mode. - Click on the "Contact Us" button in the header. - In the text toolbar, select "Link" as the "Style" option. - In the text toolbar, clear the URL input (remove "/contactus"). - Click anywhere on the page. - Save the page. - A traceback occurs: "Template fallback - An error occurred while rendering the template website.template_header_mobile" The header's CTA button cannot be removed because it has the class "oe_unremovable". However,
Original PR description
Steps to reproduce: - Enter in Website edit mode. - Click on the "Contact Us" button in the header. - In the text toolbar, select "Link" as the "Style" option. - In the text toolbar, clear the URL input (remove "/contactus"). - Click anywhere on the page. - Save the page. - A traceback occurs: "Template fallback - An error occurred while rendering the template website.template_header_mobile" The header's CTA button cannot be removed because it has the class "oe_unremovable". However, when the URL is cleared from the input field (see step 4 above), the "shouldUnlink" function in "link_tools.js" determines that the link around the "Contact Us" text should be removed. In this commit, we prevent links with the "oe_unremovable" class from being removed in this situation. opw-4308023 Forward-Port-Of: odoo/odoo#187947
Currently, if the `quick_encoding_vals` field becomes visible in a view (e.g., by toggling "Show invisible elements" in Studio), the system crashes. This happens because the field is currently a Binary field that cannot be represented as a string. ### Fix The `quick_encoding_vals` field is an **unstored computed** field that outputs a dictionary. To resolve the issue, we can safely convert it into a JSON field. Note: Fix confirmed by WAN on the ticket. opw-4241572 Forward-Port-Of: o
Original PR description
Currently, if the `quick_encoding_vals` field becomes visible in a view (e.g., by toggling "Show invisible elements" in Studio), the system crashes. This happens because the field is currently a Binary field that cannot be represented as a string. ### Fix The `quick_encoding_vals` field is an **unstored computed** field that outputs a dictionary. To resolve the issue, we can safely convert it into a JSON field. Note: Fix confirmed by WAN on the ticket. opw-4241572 Forward-Port-Of: odoo/odoo#187050
Steps to reproduce: 1. Go to Accounting > Invoices and print any invoice. 2. Go to Settings > Configure your document layout. 3. Set the layout to "Boxed" (default is "Light"). 4. Add a Company Tagline (any value), save, then delete it completely. 5. Go back to Accounting > Invoices and print any invoice. You can notice that the grey line and the text on the top right corner is more down compare to the first printed report. When the Company Tagline `report_header` is cleared, it lea
Original PR description
Steps to reproduce: 1. Go to Accounting > Invoices and print any invoice. 2. Go to Settings > Configure your document layout. 3. Set the layout to "Boxed" (default is "Light"). 4. Add a Company…
Steps to reproduce: 1. Go to Accounting > Invoices and print any invoice. 2. Go to Settings > Configure your document layout. 3. Set the layout to "Boxed" (default is "Light"). 4. Add a Company Tagline (any value), save, then delete it completely. 5. Go back to Accounting > Invoices and print any invoice. You can notice that the grey line and the text on the top right corner is more down compare to the first printed report. When the Company Tagline `report_header` is cleared, it leaves an extra newline in the report because the HTML editor sets it to `<p><br></p>` instead of `false`. This causes the printed invoice layout to shift. As a solution I added a method that checks if `report_header` is empty or not and then display it only when it’s not empty (`<p><br></p>`). Alternative solutions considered: 1. Clean the `report_header` field before saving it to the database OR use an on-change function to remove empty values. 2. Implement a custom widget or JS hook for better control. The chosen solution is the simplest, requiring minimal code changes to address the issue effectively. opw-4247281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188055 Forward-Port-Of: odoo/odoo#186023
The method _get_customization_ids is overriden in other modules to add their schema. The issue is that we call explicitely a specific model with _check_document_type_support. As we call it, the overrident part is not taken into account, as they are overriden in model that changed name. Ex: account.edi.xml.pint_jp is not account.edi.xml.ubl_21. It causes issues if you create a company with an existing participant in the country of these other modules and with the default eas. To reproduce
Original PR description
The method _get_customization_ids is overriden in other modules to add their schema. The issue is that we call explicitely a specific model with _check_document_type_support. As we call it, the overrident part is not taken into account, as they are overriden in model that changed name. Ex: account.edi.xml.pint_jp is not account.edi.xml.ubl_21. It causes issues if you create a company with an existing participant in the country of these other modules and with the default eas. To reproduce: Create a company with the module l10n_jp_ubl_pint and account_peppol installed. Put Japan as country and put as Tax number the endpoint of an existing participant When saving, it will traceback, as the key is not in the dict --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188005
Issue: When printing the PDF of a Purchase Order, if the company has multiple address, those appear on the same line. Steps to reproduce: - Create a Mexican Company with 2 address lines - Create a Purchase Order - Print the PDF of the Purchase Order Cause: The separator between the 2 address lines in the address format is set as a blank space. Solution: Replace the blank space separator with a new line. Ticket: 4221771 --- I confirm I have signed the CLA and read
Original PR description
Issue: When printing the PDF of a Purchase Order, if the company has multiple address, those appear on the same line. Steps to reproduce: - Create a Mexican Company with 2 address lines - Create a Purchase Order - Print the PDF of the Purchase Order Cause: The separator between the 2 address lines in the address format is set as a blank space. Solution: Replace the blank space separator with a new line. Ticket: 4221771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186926
When trying to add a DNI number from the user portal, the following error appears: The CUIT number [] does not seem to be valid. Note: the expected format is AR200-5536168-2 or 20055361682 How to reproduce the issue: - Install the Argentinian localization - Create a contact with an email, Identification Number on DNI - Grant them portal access - In users, change the password of the new contact - Log in to the user portal with the new contact credentials - In edit details, enter a DNI nu
Original PR description
When trying to add a DNI number from the user portal, the following error appears: The CUIT number [] does not seem to be valid. Note: the expected format is AR200-5536168-2 or 20055361682 How to reproduce the issue: - Install the Argentinian localization - Create a contact with an email, Identification Number on DNI - Grant them portal access - In users, change the password of the new contact - Log in to the user portal with the new contact credentials - In edit details, enter a DNI number and confirm The solution is a backport of this commit: https://github.com/odoo/odoo/commit/caf6bbc0ed875f9fff0440331acb10506d87605e#diff-abaa067ec8ef765ce398468a0dd52d47ea3585a90fa61e5276daa1e603b3b232R67 opw-4267173 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#185948
This fix is a continuation of this [commit]. Issue: ====== Inserting new image and image replacements don't get saved when switching tabs. Steps to reproduce the issue: ============================= - Create a mass mailing - choose welcome message template - add subject, mailing list and save - Add image using /image and switch directly to another tab like `a/b testing` - Go back to mail body => changes aren't saved. - Same if you replace an existing image with another one Ori
Original PR description
This fix is a continuation of this [commit]. Issue: ====== Inserting new image and image replacements don't get saved when switching tabs. Steps to reproduce the issue: =============================…
This fix is a continuation of this [commit]. Issue: ====== Inserting new image and image replacements don't get saved when switching tabs. Steps to reproduce the issue: ============================= - Create a mass mailing - choose welcome message template - add subject, mailing list and save - Add image using /image and switch directly to another tab like `a/b testing` - Go back to mail body => changes aren't saved. - Same if you replace an existing image with another one Origin of the issue: ==================== - For Newly inserted images we need to refocus in the editor like we did in the old commit. - Now for both of them after the refocus fix we still have an issue because the `saveModifiedImagesPromise` will take so much time so that after it gets resolved the component is already destroyed and we will not save the changes. Solution: ========= We force the commitChanges coming from mass_mailing as urgent so it will save the value before resolving any promise to make sure we don't loose the content. opw-3947516 [commit]: https://github.com/odoo/odoo/commit/146b0b9ff4b4c2cbabd5d71f869f31f4bbb649d2 Forward-Port-Of: odoo/odoo#182615
The previous code lead to cache-miss Courtesy of Dawn Hwang Forward-Port-Of: odoo/odoo#187772
Original PR description
The previous code lead to cache-miss Courtesy of Dawn Hwang Forward-Port-Of: odoo/odoo#187772
Issue: ====== sperator isn't inserted in the correct place. Steps to reproduce the issue: ============================= - Go to studio - Create a new internal report - Put the cursor in the div (second line) - Add some content over some lines - Insert seperator at the end of the lines - It gets inserted at the start Origin of the issue: ==================== Since we are writing inside the div directly, inserting the hr will look for the closest block and insert it before it whi
Original PR description
Issue: ====== sperator isn't inserted in the correct place. Steps to reproduce the issue: ============================= - Go to studio - Create a new internal report - Put the cursor in the div (second line) - Add some content over some lines - Insert seperator at the end of the lines - It gets inserted at the start Origin of the issue: ==================== Since we are writing inside the div directly, inserting the hr will look for the closest block and insert it before it which is the div. Because, new line inside a div is just a br and doesn't split the div. Solution: ========= Add a p element inside an empty div element when we put the selection there. task-4240730 Forward-Port-Of: odoo/odoo#187972 Forward-Port-Of: odoo/odoo#183129
This commit fixes the direction of the arrows in the stock rules diagram if the user languange is right-to-left. opw-4302429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187967 Forward-Port-Of: odoo/odoo#187921
Original PR description
This commit fixes the direction of the arrows in the stock rules diagram if the user languange is right-to-left. opw-4302429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187967 Forward-Port-Of: odoo/odoo#187921
Steps to reproduce: - Employee > New - Time Off > Configuration > Accrual Plans > New - Accrued Gain Time: 'Start of the accrual period' - New Milestone > 20 days; Yearly; Carry over: None - Time Off > Management > Allocations > New - Accrual allocation; Start at the 1st Jan this year - Asign it to your new employee - Employees > Your employee > Time Off - Take 10 days off this year - Check balance at the beginning of next year Only 10 days are available when we should get 20 after
Original PR description
Steps to reproduce: - Employee > New - Time Off > Configuration > Accrual Plans > New - Accrued Gain Time: 'Start of the accrual period' - New Milestone > 20 days; Yearly; Carry over: None - Time Off…
Steps to reproduce: - Employee > New - Time Off > Configuration > Accrual Plans > New - Accrued Gain Time: 'Start of the accrual period' - New Milestone > 20 days; Yearly; Carry over: None - Time Off > Management > Allocations > New - Accrual allocation; Start at the 1st Jan this year - Asign it to your new employee - Employees > Your employee > Time Off - Take 10 days off this year - Check balance at the beginning of next year Only 10 days are available when we should get 20 after the carryover date. While the allocation is computed correctly, leaves taken prior to the carryover are still deducted from the available days. This should not happen for days reset on carryover as the allocated days should have already been taken from the previous year's days we no longer have access to. This happens because sudo drops the context when creating a new environment, meaning we lose the target date which simply defaults back to today, making the accrual computation wrong. Note that this fix only addresses the case where leaves are validated. opw-4326914 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187377
**To reproduce:** - Install sales, delivery - Create currency DUM with value 5 DUM = 1 USD - Enable pricelists - Create shipping method based on rules with one rule: (shipping cost = 100 if price >=0) and fixed margin of 10 - Create new pricelist in DUM currency with a price for any product P - Create SO with pricelist DUM for some quantity of product P - Add shipping using above created shipping method **Current behaviour:** Calculated shipping cost 510 DUM. **Expected behaviour:*
Original PR description
**To reproduce:** - Install sales, delivery - Create currency DUM with value 5 DUM = 1 USD - Enable pricelists - Create shipping method based on rules with one rule: (shipping cost = 100 if price…
**To reproduce:** - Install sales, delivery - Create currency DUM with value 5 DUM = 1 USD - Enable pricelists - Create shipping method based on rules with one rule: (shipping cost = 100 if price >=0) and fixed margin of 10 - Create new pricelist in DUM currency with a price for any product P - Create SO with pricelist DUM for some quantity of product P - Add shipping using above created shipping method **Current behaviour:** Calculated shipping cost 510 DUM. **Expected behaviour:** Calculated shipping cost 550 DUM as in (100 USD + 10 USD) * 5 DUM/USD. **Reason:** The fixed_margin field introduced in [1] is added to the shipping cost in the `_apply_margins` method added in [2] without any currency conversion. This will lead to mismatched currency additions in case the sale order currency doesn't match the shipping methods company currency. [1] https://github.com/odoo/odoo/pull/108794 [2] https://github.com/odoo/odoo/pull/157452 opw-4289754 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187860
Before this PR, one-letter domain (like https://x.com) would not be linkified. This PR allows one-letter domain. Task-4344826 Forward-Port-Of: odoo/odoo#188037 Forward-Port-Of: odoo/odoo#187899
Original PR description
Before this PR, one-letter domain (like https://x.com) would not be linkified. This PR allows one-letter domain. Task-4344826 Forward-Port-Of: odoo/odoo#188037 Forward-Port-Of: odoo/odoo#187899
mrp: fix 2 state concerns correctly track production fields avoid recursion error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187040 Forward-Port-Of: odoo/odoo#185092
Original PR description
mrp: fix 2 state concerns correctly track production fields avoid recursion error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187040 Forward-Port-Of: odoo/odoo#185092
Since [1], the _is_indexable_url() method was introduced to determine whether a website should be indexed. However, if a domain name contains uppercase letters, the method incorrectly returns a falsy value. This happens because browsers automatically convert URLs to lowercase, causing a mismatch. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with uppercase letters (e.g., http://TEST.localhost:8069). - Go to settings and modify the robo
Original PR description
Since [1], the _is_indexable_url() method was introduced to determine whether a website should be indexed. However, if a domain name contains uppercase letters, the method incorrectly returns a falsy value. This happens because browsers automatically convert URLs to lowercase, causing a mismatch. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with uppercase letters (e.g., http://TEST.localhost:8069). - Go to settings and modify the robots.txt file. - Visit http://TEST.localhost:8069/robots.txt and notice that the changes are not reflected. This commit resolves the issue by handling uppercase letters in domain names correctly. [1]: https://github.com/odoo/odoo/commit/49c226a243864a935b7f8e13c79247a1d9405afa opw-4306840 Forward-Port-Of: odoo/odoo#187690
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188077
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188077
Steps to reproduce: 1. Drag and drop a text snippet. 2. Select background video and insert the video in the mediaDialog. 3. Click on the add button. Issue: A traceback occurs due to the tag name not being found for an element. This issue was introduced in commit [1]. Issue link: https://github.com/odoo/odoo/issues/186874 Solution: This PR resolves the traceback by adding a `parentEl` condition in the replace media on save function. [1] : https://github.com/odoo/odoo/commit/36594d04a
Original PR description
Steps to reproduce: 1. Drag and drop a text snippet. 2. Select background video and insert the video in the mediaDialog. 3. Click on the add button. Issue: A traceback occurs due to the tag name not being found for an element. This issue was introduced in commit [1]. Issue link: https://github.com/odoo/odoo/issues/186874 Solution: This PR resolves the traceback by adding a `parentEl` condition in the replace media on save function. [1] : https://github.com/odoo/odoo/commit/36594d04a8909dd40ab6384f387c372ddae62345 Forward-Port-Of: odoo/odoo#187952 Forward-Port-Of: odoo/odoo#186876
Steps to reproduce ================== - Install crm,web_studio - Enable leads - Go to CRM > Configuration > Sales Team - Open the first record - Uncheck Pipeline and Leads - Go to CRM > Sales > Teams - Open studio => Undefined graph model for Sales Team: Pre-Sales Cause of the issue ================== The window action uses the following domain `[["use_opportunities", "=", true]]` It is not used from within studio. opw-4285413 Forward-Port-Of: odoo/enterprise#74330 Forwar
Original PR description
Steps to reproduce ================== - Install crm,web_studio - Enable leads - Go to CRM > Configuration > Sales Team - Open the first record - Uncheck Pipeline and Leads - Go to CRM > Sales > Teams - Open studio => Undefined graph model for Sales Team: Pre-Sales Cause of the issue ================== The window action uses the following domain `[["use_opportunities", "=", true]]` It is not used from within studio. opw-4285413 Forward-Port-Of: odoo/enterprise#74330 Forward-Port-Of: odoo/enterprise#74091
## 1st Issue **[FIX] l10n_es_reports: hanldle new expressions in mod349** In report line, if there is no related expression pointing at it, it is being created by shortcut syntaxes. Before this PR[^1], there were no expressions pointing at these report lines: 1. mod_349_supplies 2. mod_349_acquisitions 3. mod_349_triangular 4. mod_349_services_sold 5. mod_349_services_acquired 6. mod_349_supplies_without_taxes 7. mod_349_supplies_without_taxes_legal_representative 8. mod_349
Original PR description
## 1st Issue **[FIX] l10n_es_reports: hanldle new expressions in mod349** In report line, if there is no related expression pointing at it, it is being created by shortcut syntaxes. Before this…
## 1st Issue
**[FIX] l10n_es_reports: hanldle new expressions in mod349**
In report line, if there is no related expression pointing at it,
it is being created by shortcut syntaxes.
Before this PR[^1], there were no expressions pointing at
these report lines:
1. mod_349_supplies
2. mod_349_acquisitions
3. mod_349_triangular
4. mod_349_services_sold
5. mod_349_services_acquired
6. mod_349_supplies_without_taxes
7. mod_349_supplies_without_taxes_legal_representative
8. mod_349_supplies_refunds
9. mod_349_acquisitions_refunds
10. mod_349_triangular_refunds
11. mod_349_services_sold_refunds
12. mod_349_services_acquired_refunds
13. mod_349_supplies_without_taxes_refunds
14. mod_349_supplies_without_taxes_legal_representative_refunds
After that PR, all of the report lines now include expressions with `engine=custom` and `label=balance`. For databases on version >= `16.0` before the PR, these report lines already have expressions without an IMD. However, during an upgrade, the addition of new expressions with an IMD triggers the creation of duplicates, resulting in a UNIQUE constraint violation on `(report_line_id, balance)`.
Steps to reproduce the issue:
1. Install `l10n_es_reports` in version `16.0` before that PR
2. Try to upgrade it to `17.0` after that PR
You will get error similar to this:
```
2024-10-30 13:56:05,428 3470006 WARNING test_l10n_es_report odoo.modules.loading: Transient module states were reset
2024-10-30 13:56:05,430 3470006 ERROR test_l10n_es_report odoo.modules.registry: Failed to load registry
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 462, in _tag_record
self._tag_record(child_rec, extra_vals={inverse_name: record.id})
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 462, in _tag_record
self._tag_record(child_rec, extra_vals={inverse_name: record.id})
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 462, in _tag_record
self._tag_record(child_rec, extra_vals={inverse_name: record.id})
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 456, in _tag_record
record = model._load_records([data], self.mode == 'update')
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 5088, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4999, in _load_records_create
return self.create(values)
File "<decorator-gen-216>", line 2, in create
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/odoo/17.0/addons/account/models/account_report.py", line 620, in create
result = super().create(vals_list)
File "<decorator-gen-123>", line 2, in create
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/upgrade-util/src/util/orm.py", line 244, in wrapper
return f(*args, **kwargs)
File "/home/odoo/src/upgrade/migrations/base/0.0.0/pre-models-match_uniq.py", line 25, in create
return super().create(vals_list)
File "<decorator-gen-12>", line 2, in create
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4627, in create
records = self._create(data_list)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4815, in _create
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "account_report_expression_line_label_uniq"
DETAIL: Key (report_line_id, label)=(480, balance) already exists.
```
## 2nd Issue
**[FIX] l10n_es_reports: fix subformulas' of expressions in mod349**
In this PR[^1], the expressions `mod_349_statistics_invoices_total_amount_balance`
and `mod_349_statistics_refunds_total_amount_balance` was modified so the engine of
both of them changed from `domain` to `aggregation`. Also the subformula from both
of them were removed. But during the upgrade the engines are being modified but
the subformulas kept same.
Expected condition is having NULL on both of the expressions' subformula.
Because of they are not being changed during upgrade, they end up being `sum`
at the end.
When we try to open the `Tax report mod 349` after upgrade, the new engine and old
subformula are conflicting and facing issue here[^2].
Steps to reproduce
1. Install `l10n_es_reports` before the PR above in version `16.0`
2. Upgrade the db to `17.0` by solving the 1st issue of this PR
3. Try to open `Tax report mod 349`
you will see error like this:
```
.....
result = getattr(recs, name)(*args, **kwargs)
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 4869, in get_report_information
all_column_groups_expression_totals = self._compute_expression_totals_for_each_column_group(self.line_ids.expression_ids, options, warnings=warnings)
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 2826, in _compute_expression_totals_for_each_column_group
current_group_expression_totals = self._compute_expression_totals_for_single_column_group(
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 3011, in _compute_expression_totals_for_single_column_group
aggregation_formula_results = self._compute_totals_no_batch_aggregation(column_group_options, aggregation_formulas_dict, column_group_expression_totals, cross_report_expr_totals_by_scope)
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 3208, in _compute_totals_no_batch_aggregation
expression_result = self._aggregation_apply_bounds(column_group_options, expression.subformula, formula_result)
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 3266, in _aggregation_apply_bounds
group_values = match.groupdict()
AttributeError: 'NoneType' object has no attribute 'groupdict'
```
[^1]: https://github.com/odoo/enterprise/pull/65074
[^2]: https://github.com/odoo/enterprise/blob/3a7a46ff2404a5c4ca1c0ad676529fc17d9a2234/account_reports/models/account_report.py#L3455-L3461
Forward-Port-Of: odoo/enterprise#74328
Forward-Port-Of: odoo/enterprise#73082Some strings weren't translatable/were missing from the pot files to be translated. Since these strings weren't translatable (i.e. no lost work), they have been updated to be more grammatically correct + understandable where useful. opw-4321317 Forward-Port-Of: odoo/enterprise#74100 Forward-Port-Of: odoo/enterprise#73854
Original PR description
Some strings weren't translatable/were missing from the pot files to be translated. Since these strings weren't translatable (i.e. no lost work), they have been updated to be more grammatically correct + understandable where useful. opw-4321317 Forward-Port-Of: odoo/enterprise#74100 Forward-Port-Of: odoo/enterprise#73854
### Steps to reproduce: - Install "l10n_cl" and switch to a Chilian company - Give another user the role "Bookkeeper" - Switch to this user - Select an invoice and try to generate a Credit note - This user has not the right to create `l10n_cl.account.invoice.reference` ### Cause: The record `l10n_cl.account.invoice.reference` can only be created by managers (Accountant). ### Solution: Change the access rights to give full access on the record to users with the role "Billing". opw
Original PR description
### Steps to reproduce: - Install "l10n_cl" and switch to a Chilian company - Give another user the role "Bookkeeper" - Switch to this user - Select an invoice and try to generate a Credit note - This user has not the right to create `l10n_cl.account.invoice.reference` ### Cause: The record `l10n_cl.account.invoice.reference` can only be created by managers (Accountant). ### Solution: Change the access rights to give full access on the record to users with the role "Billing". opw-4291981 Forward-Port-Of: odoo/enterprise#74015
This is a fix for failing test after the change introduced in the corrosponding community [PR] task-4240730 [PR]: https://github.com/odoo/odoo/pull/183129 Forward-Port-Of: odoo/enterprise#74224 Forward-Port-Of: odoo/enterprise#71778
Original PR description
This is a fix for failing test after the change introduced in the corrosponding community [PR] task-4240730 [PR]: https://github.com/odoo/odoo/pull/183129 Forward-Port-Of: odoo/enterprise#74224 Forward-Port-Of: odoo/enterprise#71778
An error will raise when users try to open a locked SO where taxes are automatically computed Set up Avatax on the current company In Settings > Sales > Quotations& Orders active 'Lock Confirmed Sales' Create a SO with fiscal position 'Automatic Tax Mapping (AvaTax)' Add a partner and product having avatax category defined Compute taxes Confirm order, it will be automatically locked - With only sale_external_tax installed: Click "Preview" - With sale_subscription_external_tax installe
Original PR description
An error will raise when users try to open a locked SO where taxes are automatically computed Set up Avatax on the current company In Settings > Sales > Quotations& Orders active 'Lock Confirmed Sales' Create a SO with fiscal position 'Automatic Tax Mapping (AvaTax)' Add a partner and product having avatax category defined Compute taxes Confirm order, it will be automatically locked - With only sale_external_tax installed: Click "Preview" - With sale_subscription_external_tax installed: Click "Confirm" Issue: Action will be blocked by User Error ``` It is forbidden to modify the following fields in a locked order ``` This occurs because the system attempt to recompute external taxes after confirming the sale order, which has been locked, so the action will be blocked opw-4261396 Forward-Port-Of: odoo/enterprise#74169
During the es_XX.po cleaning, the po file for l10n_co_reports was incorrectly not converted to es_419.po and only deleted. We now restore it + correctly rename it to es_419.po As part of this cleaning, the pot file has been re-exported and the po re-synced with it. Missing translations were also added it. A sentence that was obviously incorrect in the original Spanish was also translated to a correct sentence. opw-4336377 PR that deleted the original es_CO.po file: https://github.com/od
Original PR description
During the es_XX.po cleaning, the po file for l10n_co_reports was incorrectly not converted to es_419.po and only deleted. We now restore it + correctly rename it to es_419.po As part of this cleaning, the pot file has been re-exported and the po re-synced with it. Missing translations were also added it. A sentence that was obviously incorrect in the original Spanish was also translated to a correct sentence. opw-4336377 PR that deleted the original es_CO.po file: https://github.com/odoo/enterprise/pull/66317 Forward-Port-Of: odoo/enterprise#74248
### After this PR You can add new column to the account partner ledger Example: ``` def _get_additional_column_aml_query_values(self): res = super()._get_additional_column_aml_query_values() res +="account_move_line.date as date," return res ``` Forward-Port-Of: odoo/enterprise#74201 Forward-Port-Of: odoo/enterprise#74075
Original PR description
### After this PR
You can add new column to the account partner ledger
Example:
```
def _get_additional_column_aml_query_values(self):
res = super()._get_additional_column_aml_query_values()
res +="account_move_line.date as date,"
return res
```
Forward-Port-Of: odoo/enterprise#74201
Forward-Port-Of: odoo/enterprise#74075Introduced in https://github.com/odoo/enterprise/pull/73469 I made a mistake when checking module dependencies, `work_entry_source` attendance is not available in `hr_payroll`, the attendance module is separate. This move is needed to fix errors in runbot. opw-4266880 Forward-Port-Of: odoo/enterprise#74251
Original PR description
Introduced in https://github.com/odoo/enterprise/pull/73469 I made a mistake when checking module dependencies, `work_entry_source` attendance is not available in `hr_payroll`, the attendance module is separate. This move is needed to fix errors in runbot. opw-4266880 Forward-Port-Of: odoo/enterprise#74251
Add some hooks and tweaks to improve the experience to customize/improve on top of this module. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#72123
Original PR description
Add some hooks and tweaks to improve the experience to customize/improve on top of this module. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#72123
Task id 4244702 Forward-Port-Of: odoo/enterprise#74287
Original PR description
Task id 4244702 Forward-Port-Of: odoo/enterprise#74287