Friday, November 22, 2024
38 changes · saas-17.2
Resolved issues and error corrections
This fixes an internal website test so it no longer depends on optional demo data being available. It helps keep automated validation reliable and prevents false build failures, without changing the user-facing website experience.
Original PR description
[Runbot Error 107975](https://runbot.odoo.com/web#id=107975&model=runbot.build.error)
This fixes an issue in the self-ordering point of sale test setup where tax information could be missing when no company country was configured. It helps keep automated checks stable and reduces false failures during development validation.
Original PR description
tax_group_id was not set since company_id was didn't have any country and class wasn't extending from common class. runbot id: 105616
This fix makes avatar tag fields show the same background color as other invalid fields. It improves visual consistency in forms and helps users more clearly recognize validation issues.
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-prMiscellaneous changes
Currently, the accounting firm's VAT is used for the CodaBox connection but sometimes, accounting firms need to use a different VAT as their contract number. This adds a system parameter that if filled, is used instead of the firm's VAT. task-4335294 Forward-Port-Of: odoo/enterprise#73883
Original PR description
Currently, the accounting firm's VAT is used for the CodaBox connection but sometimes, accounting firms need to use a different VAT as their contract number. This adds a system parameter that if filled, is used instead of the firm's VAT. task-4335294 Forward-Port-Of: odoo/enterprise#73883
- Add .pot base translation file. - Replace potentially unsafe `const_eval()` with a `json.loads()`. - Use the built-in methods for setting filename for received files. Forward-Port-Of: odoo/enterprise#74347
Original PR description
- Add .pot base translation file. - Replace potentially unsafe `const_eval()` with a `json.loads()`. - Use the built-in methods for setting filename for received files. Forward-Port-Of: odoo/enterprise#74347
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create a vendor bill with this partner using the tax "Exento" - Go to Reports -> Tax report -> DIOT.txt ### Cause: For partners that only have lines with the tax "Exento", no information are retrieved for the report. The columns "Type of third", "type of operation", "VAT", etc. are empty in the Tax report before trying to download the DIOT report. When trying to generate the txt file, the code tries to access th
Original PR description
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create a vendor bill with this partner using the tax "Exento" - Go to Reports -> Tax report -> DIOT.txt ### Cause: For partners that only have lines with the tax "Exento", no information are retrieved for the report. The columns "Type of third", "type of operation", "VAT", etc. are empty in the Tax report before trying to download the DIOT report. When trying to generate the txt file, the code tries to access the value "third_party_code" in a dictionary but the key is not there so an error is raised. This occurs because the tax "Exento" is "on_invoice" so there are no cash basis entry created. But in the custom query to retrieve the information of the partners it is specified the journal_id must be part of the cash basis journals. So no lines with "on_invoice" taxes were selected. ### Solution: Remove the journal restriction. opw-4312155 Forward-Port-Of: odoo/enterprise#74105
Steps to reproduce ================== - Install hr_attendance_gantt,web_studio - Go to Attendences - Open studio - Enable "Display total row" in the sidebar - Exit studio - Create a new entry with no end date - Switch to the week view - Go to the previous week => `Cannot read properties of undefined (reading 'pills')` Cause of the issue ================== When records don't have a dateStop value, it is set as now(). The domain included record that start before now and have n
Original PR description
Steps to reproduce ================== - Install hr_attendance_gantt,web_studio - Go to Attendences - Open studio - Enable "Display total row" in the sidebar - Exit studio - Create a new entry with no end date - Switch to the week view - Go to the previous week => `Cannot read properties of undefined (reading 'pills')` Cause of the issue ================== When records don't have a dateStop value, it is set as now(). The domain included record that start before now and have no stop (so converted to now). If the current window is between the 01 and 07 Nov, and today is 14 Nov, a record starting the 09 Nov that has no end date will be included. When finding the closest date, it will be out of bound (day 8 when we only have 7). Solution ======== Those records shouldn't be included at all as the are outside the current viewable range. opw-4160977 Forward-Port-Of: odoo/enterprise#73839
### 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
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
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#74091
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#74091
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
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
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
## 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#74209
Forward-Port-Of: odoo/enterprise#73082--- 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
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
Since October 2024, the Facebook mobile site (m.facebook.com) uses an 'X-Frame-Options' header set to 'deny', preventing iframe embedding across different domains. This header enforces a security policy restricting cross-origin access to the content. Meta has not provided any communication regarding this change. Until it is resolved, we have no choice but to hide the iframe on mobile to prevent users from seeing a "unavailable content" icon. Steps to reproduce: - In website edit mode. -
Original PR description
Since October 2024, the Facebook mobile site (m.facebook.com) uses an 'X-Frame-Options' header set to 'deny', preventing iframe embedding across different domains. This header enforces a security policy restricting cross-origin access to the content. Meta has not provided any communication regarding this change. Until it is resolved, we have no choice but to hide the iframe on mobile to prevent users from seeing a "unavailable content" icon. Steps to reproduce: - In website edit mode. - Drag and drop the "Facebook" snippet into the footer. - Save the page. - Open the dev tools and enable the mobile preview. - Bug: The "Facebook" snippet crashes. More info about the issue: https://developers.facebook.com/community/threads/550478830783215/ opw-4302563 opw-4309180 opw-4222359 opw-4277045 Forward-Port-Of: odoo/odoo#187815 Forward-Port-Of: odoo/odoo#186813
**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
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
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: 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
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
Versions -------- - 17.0+ Steps ----- 1. Have 50% discount program; 2. have a deliverable $300 product; 3. have a $10 shipping method that's free for orders over $250; 4. in eCommerce, add the $300 product to your cart; 5. go to checkout; 6. remove the automatically applied discount; 7. proceed to payment; 8. select the $10 shipping method; 9. click the "Claim" button for the 50% discount. Issue ----- Shipping is still free despite the order being below $250. Cause -----
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have 50% discount program; 2. have a deliverable $300 product; 3. have a $10 shipping method that's free for orders over $250; 4. in eCommerce, add the $300 product to your cart; 5. go to checkout; 6. remove the automatically applied discount; 7. proceed to payment; 8. select the $10 shipping method; 9. click the "Claim" button for the 50% discount. Issue ----- Shipping is still free despite the order being below $250. Cause ----- Delivery rate isn't recomputed after applying rewards. Solution -------- After applying a reward in eCommerce, update programs & rewards. If the reward isn't a payment program (gift card or eWallet), and the selected carrier has a `free_over` rule, recompute shipping costs. opw-4319533 Forward-Port-Of: odoo/odoo#187296
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
Description of the issue this PR addresses: Previously, selection using Shift + Arrow keys was not possible across contenteditable=false elements such as banners and clipboards. This commit makes sure now selection be done across these elements using Shift + Arrow keys. task-3502724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182503
Original PR description
Description of the issue this PR addresses: Previously, selection using Shift + Arrow keys was not possible across contenteditable=false elements such as banners and clipboards. This commit makes sure now selection be done across these elements using Shift + Arrow keys. task-3502724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182503
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
Steps to reproduce ================== - Install crm - Add a single property - Drag and drop it to the second group => TypeError: Cannot read properties of undefined (reading 'elements') Cause of the issue ================== A properties field is composed of a list of property stored in a JSON object. A property can either be a separator, or any other type, char, bool, ... The properties field has a columns props. If we either have no separator, or we have only one and i
Original PR description
Steps to reproduce ================== - Install crm - Add a single property - Drag and drop it to the second group => TypeError: Cannot read properties of undefined (reading 'elements') Cause of the…
Steps to reproduce ================== - Install crm - Add a single property - Drag and drop it to the second group => TypeError: Cannot read properties of undefined (reading 'elements') Cause of the issue ================== A properties field is composed of a list of property stored in a JSON object. A property can either be a separator, or any other type, char, bool, ... The properties field has a columns props. If we either have no separator, or we have only one and it is at the first position, we enter the split mode. This means that properties are displayed across the available columns. If we move a property in a group, it means we wan't that property to stay in that group. When we're in split mode, we need to add the least amount of new separators so that we get the expected layout. In some cases, it wasn't possible to get the actual group where we dropped a property. This can happen for example when the target was inside an empty group with a default invisible separator (it has no name). In some cases also, the behavior wasn't simply what was expected. opw-3961445 Forward-Port-Of: odoo/odoo#169056
In #183165 the override of the PdfReader constructor was forcing the `strict` parameter to True[1][1] in the pdf shim for PyPDF2 1.x. So, when a PdfReader is instanciated with strict set to False, with that PyPDF version installed, the strict parameter is not taken into account. In that case, it impossible to upload some PDF documents that were allowed before the shims. With this commit, the override of the constructor is removed in the 1.x shim and the PdfReader override is only made once
Original PR description
In #183165 the override of the PdfReader constructor was forcing the `strict` parameter to True[1][1] in the pdf shim for PyPDF2 1.x. So, when a PdfReader is instanciated with strict set to False,…
In #183165 the override of the PdfReader constructor was forcing the `strict` parameter to True[1][1] in the pdf shim for PyPDF2 1.x. So, when a PdfReader is instanciated with strict set to False, with that PyPDF version installed, the strict parameter is not taken into account. In that case, it impossible to upload some PDF documents that were allowed before the shims. With this commit, the override of the constructor is removed in the 1.x shim and the PdfReader override is only made once at the upper level. The `strict` parameter is defaulting to True but not enforced as it was the default behavior in PyPDF2 1.x. It should be changed later to follow the behavior of PyPDF2 >= 2.x. Also, any other parameter of the constructor are discarded as they are useless in PyPDF 1.x and not compatible at all with PyPDF >= 2.x. On the other hand, the new `password` parameter of 2.x is not backward compatible. [1]: odoo/odoo@f03a12c9296c90e6e371f0970fc3760eb5514ab1/odoo/tools/pdf/_pypdf2_1.py#L19 Forward-Port-Of: odoo/odoo#187900
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: - 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
**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
After discussion with Pagero support, the BIC of the Payee must be set, therefore we add a constraint to enforce it when invoicing to Chorus Pro. opw-4139689 Forward-Port-Of: odoo/odoo#187535
Original PR description
After discussion with Pagero support, the BIC of the Payee must be set, therefore we add a constraint to enforce it when invoicing to Chorus Pro. opw-4139689 Forward-Port-Of: odoo/odoo#187535
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
Current behavior before PR: When a user posted a message in a group chat, the web notification displayed `#False` as the title. This occurred because `record_name` was used as the title but it was empty for channels with `channel_type = 'group'`, as the displayName name is calculated on the UI side when displaying chat in Discuss. Before / After <div style="display: flex;"> <img src="https://github.com/user-attachments/assets/7ad2de52-8cef-41a7-8d63-b19d718725ff" width="48%" style="margi
Original PR description
Current behavior before PR: When a user posted a message in a group chat, the web notification displayed `#False` as the title. This occurred because `record_name` was used as the title but it was empty for channels with `channel_type = 'group'`, as the displayName name is calculated on the UI side when displaying chat in Discuss. Before / After <div style="display: flex;"> <img src="https://github.com/user-attachments/assets/7ad2de52-8cef-41a7-8d63-b19d718725ff" width="48%" style="margin-right: 4%;" /> <img src="https://github.com/user-attachments/assets/452fac6e-3a79-4e53-a09c-4fad57b44856" width="48%" /> </div> Desired behavior after PR is merged: The title of the web notification now correctly displays the group chat name, ensuring recipients see accurate and complete group titles in notifications. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186756
*: 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
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
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 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
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 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#186160