Monday, July 1, 2024
26 changes
14 changes
Resolved issues and error corrections
Invoices with fixed taxes now avoid showing a base amount next to those taxes, because that amount is not used in the fixed tax calculation. This makes printed invoices clearer and prevents customers from seeing potentially misleading tax details.
Original PR description
When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount. Added a check to differenciate fixed taxes from other and adapt display accordingly. see https://github.com/odoo/odoo/pull/168638 task-3964942
This fix keeps the header line visible in empty list views, preventing the page from looking visually broken. Users get a clearer, more consistent view even when there are no records to display.
Original PR description
Before this commit: The content of list view is empty, the outline of the `<thead>` tag (the line below the first `<tr>` inside `<thead>`) would disappear, means its opacity reduced. After this commit: This commit fixes the issue by ensuring that the outline of the `<thead>` tag remains visible even when the list view is empty. task - 3834758
Features or functions removed from Odoo
This update removes an unused piece of timesheet-related project logic. It helps keep the application code cleaner and easier to maintain, with no expected change for end users.
Original PR description
task-3754591
Miscellaneous changes
The TicketBAI EDI integration will pre-process invoice lines to make sure that the description in the EDI is properly encoded/striped of non-supported characters. However this pre-processing step does not take into account the fact that the `name` field of an `account.move.line` record is not required and can thus be Falsy. This causes the EDI pre-processing to crash with a traceback for invoices with empty lines. This also prevents the cron from going any further than such an invoice in i
Original PR description
The TicketBAI EDI integration will pre-process invoice lines to make sure that the description in the EDI is properly encoded/striped of non-supported characters. However this pre-processing step does not take into account the fact that the `name` field of an `account.move.line` record is not required and can thus be Falsy. This causes the EDI pre-processing to crash with a traceback for invoices with empty lines. This also prevents the cron from going any further than such an invoice in its queue. This fix solves this issue. Note that the generated XML will not pass the XLD validation, since the presence of at least one alpha-numeric character is required - but at least the problem will now be explained with an actual error flow and not a complete crash. opw-3974117 Forward-Port-Of: odoo/odoo#171181
11 changes
Enhancements to existing features
Payroll dashboard charts have been adjusted to match the redesigned graph visuals used elsewhere in Odoo. This gives users a more consistent reporting experience and keeps Payroll analytics aligned with the latest visual standards.
Original PR description
Since the redesign of the Graph view and the update of visualization colors in [odoo/#167296](https://github.com/odoo/odoo/pull/167296), this PR adapts charts outside the Graph view to maintain consistency with it in Payroll. Requires: - https://github.com/odoo/odoo/pull/167296 task-3620659
1 change
Resolved issues and error corrections
This update fixes the invoice extraction tests to work reliably regardless of whether demo data is loaded. Previously, tests would fail if demo data wasn't present, causing inconsistent results. Now the tests are self-contained and produce consistent outcomes in all environments.
Original PR description
Removed dependency on demo data for the TestInvoiceExtractPurchase tests, as they would previously fail if the demo data had not been loaded. Now the results will be consistent, no matter if the demo data is present. Task-3957718 Forward-Port-Of: odoo/enterprise#65742 Forward-Port-Of: odoo/enterprise#65660
Steps: - In Studio, add a many2one field with the widget "many2one_avatar_user" in SO form - Create a SO and confirm it - Press Alt+I Actual result: - Alt+I is related to "Create Invoice" in UI - Alt+I open the user choice for the added field Expected result: - Alt+Q for "Create Invoice" - Alt+I open the user choice for the added field `q` used to be aligned with [sale_subscription](https://github.com/odoo/enterprise/blob/17.0/sale_subscription/views/sale_order_views.xml#L28) `q
Original PR description
Steps: - In Studio, add a many2one field with the widget "many2one_avatar_user" in SO form - Create a SO and confirm it - Press Alt+I Actual result: - Alt+I is related to "Create Invoice" in UI - Alt+I open the user choice for the added field Expected result: - Alt+Q for "Create Invoice" - Alt+I open the user choice for the added field `q` used to be aligned with [sale_subscription](https://github.com/odoo/enterprise/blob/17.0/sale_subscription/views/sale_order_views.xml#L28) `q` used for "Confirm" action in the same view, should not be a conflict opw-4004869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170997
…xerror ForecastedDetails template inheritance wrong declaration of name (sale_stock, mrp, purchase_stock) Steps to Reproduce customer want to add an additional column to the ForecastedDetails template. customer able to do it to basic template But not for prepared inheritances in sale_stock, mrp, purchase_stock. The problem is that system can’t resolve symbol e.g t-inherit="sale_stock.ForecastedDetails” because somebody declatest in code ```py <t name="sale_stock.ForecastedDe
Original PR description
…xerror ForecastedDetails template inheritance wrong declaration of name (sale_stock, mrp, purchase_stock) Steps to Reproduce customer want to add an additional column to the ForecastedDetails…
…xerror ForecastedDetails template inheritance wrong declaration of name (sale_stock, mrp, purchase_stock) Steps to Reproduce customer want to add an additional column to the ForecastedDetails template. customer able to do it to basic template But not for prepared inheritances in sale_stock, mrp, purchase_stock. The problem is that system can’t resolve symbol e.g t-inherit="sale_stock.ForecastedDetails” because somebody declatest in code ```py <t name="sale_stock.ForecastedDetails" t-inherit="stock.ForecastedDetails" t-inherit-mode="extension"> instead <t t-name="sale_stock.ForecastedDetails" t-inherit="stock.ForecastedDetails" t-inherit-mode="extension"> ``` here is a issue link :- https://github.com/odoo/odoo/issues/167741 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#171238 Forward-Port-Of: odoo/odoo#169804
In this PR fixes the following issue: - This pull request addresses a mobile view issue in the 'customer ratings' section by setting the 'frequency' field width to 'auto.' This adjustment prevents content overflow on mobile devices, enhancing user experience. Your review and feedback are appreciated for seamless integration. - I'm submitting a pull request to address an issue in the 'project.task' kanban card. The problem is the persistent visibility of the 'Assign People' b
Original PR description
In this PR fixes the following issue:
- This pull request addresses a mobile view issue in the 'customer ratings' section by setting
the 'frequency' field width to 'auto.' This adjustment prevents content overflow on mobile devices,
enhancing user experience. Your review and feedback are appreciated for seamless integration.
- I'm submitting a pull request to address an issue in the 'project.task' kanban card. The problem is
the persistent visibility of the 'Assign People' button for sub-tasks, causing UI clutter. My solution
involves displaying the 'Assign People' button only upon hovering over a sub-task line within the
'project.task' kanban card's sub-tasks list. Your review and feedback on this change are appreciated.
task- 3549267
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#139807In a large database with lots (>1M) account.moves, installing the ecommerce module can lead to a MemoryError. This is because of the computed stored field `website_id`. Computing this field's value for each one of the >1M account.moves overfills the field_cache and make the 2gb worker hit a memory limit. To fix that, this commit init the compute field through an override of the `_auto_init` method. As `sale.order.website_id` is expected to be NULL at the module installation, creating the webs
Original PR description
In a large database with lots (>1M) account.moves, installing the ecommerce module can lead to a MemoryError. This is because of the computed stored field `website_id`. Computing this field's value for each one of the >1M account.moves overfills the field_cache and make the 2gb worker hit a memory limit. To fix that, this commit init the compute field through an override of the `_auto_init` method. As `sale.order.website_id` is expected to be NULL at the module installation, creating the website_id column on the account.move table is enough. opw-3989064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169991
When reducing the quantity to produce in the subcontracted manufacturing orders, we use the wrong quantity for the call to `change_prod_qty()`. Instead of `production.product_uom_qty` (which is in the **product** uom), use `production.product_qty` (which is in the **production** uom), itself set from the move's uom. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171204 Forward-Port-Of: odoo/odoo#171093
Original PR description
When reducing the quantity to produce in the subcontracted manufacturing orders, we use the wrong quantity for the call to `change_prod_qty()`. Instead of `production.product_uom_qty` (which is in the **product** uom), use `production.product_qty` (which is in the **production** uom), itself set from the move's uom. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171204 Forward-Port-Of: odoo/odoo#171093
Steps to reproduce: 1. Go to website > Edit 2. Drag and drop 'Banner' snippet and 'Items' snippet > Save 3. Repeat the step 2 again 4. Error will be generated in terminal Current behavior before PR: Dropping and saving new snippets immediately after snippets containing links would generate a traceback. This issue occurred because the `callPostSnippetDrop` had not completed execution, and `cleanForSave`, responsible for removing `zwnbsp` was called prematurely. Consequently `historySt
Original PR description
Steps to reproduce: 1. Go to website > Edit 2. Drag and drop 'Banner' snippet and 'Items' snippet > Save 3. Repeat the step 2 again 4. Error will be generated in terminal Current behavior before PR: Dropping and saving new snippets immediately after snippets containing links would generate a traceback. This issue occurred because the `callPostSnippetDrop` had not completed execution, and `cleanForSave`, responsible for removing `zwnbsp` was called prematurely. Consequently `historyStep` after `callPostSnippetDrop` would reintroduce `zwnbsp` to links. Desired behavior after PR is merged: Ensure that all post-snippet drop promises are resolved before saving. task-3954229 Forward-Port-Of: odoo/odoo#171068 Forward-Port-Of: odoo/odoo#167365
When using base.automation a timed condition using a calendar, the check was done for each record to get the datetime with the delay using the calendar. Now we invert the logic instead of adding the delay to the record in a loop datetime field, we substract from the last_run and now once outside of the loop. It goes from this logic: last_run <= record_dt + delay < now to this: last_run - delay <= record_dt < now - delay In a database with 1000 records to check a single calendar: it
Original PR description
When using base.automation a timed condition using a calendar, the check was done for each record to get the datetime with the delay using the calendar. Now we invert the logic instead of adding the delay to the record in a loop datetime field, we substract from the last_run and now once outside of the loop. It goes from this logic: last_run <= record_dt + delay < now to this: last_run - delay <= record_dt < now - delay In a database with 1000 records to check a single calendar: it went from 15s to 20ms opw-3876867 https://github.com/odoo/enterprise/pull/65417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171270 Forward-Port-Of: odoo/odoo#167310
**Current behavior before PR:** In discuss guest user view, notification settings button was visible, which used to throw a "Session Expired" error upon being clicked. **Desired behavior after PR is merged:** In discuss guest user view, notification settings button is removed. **task:3975859** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171278 Forward-Port-Of: odoo/odoo#169044
Original PR description
**Current behavior before PR:** In discuss guest user view, notification settings button was visible, which used to throw a "Session Expired" error upon being clicked. **Desired behavior after PR is merged:** In discuss guest user view, notification settings button is removed. **task:3975859** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171278 Forward-Port-Of: odoo/odoo#169044
Anglo-Saxon accounting is the main system used in Colombia, this commit enables it by default when installing `l10n_co`. This configuration is only accessible in Debug mode in the `Settings` -> `Bank and Cash` section, so during the implementation it doesn't get much visibility. Setting the correct default for the localization helps prevent re-implementations and reduces accounting errors for companies. At present, the impact of this configuration can only be assessed after going live.
Original PR description
Anglo-Saxon accounting is the main system used in Colombia, this commit enables it by default when installing `l10n_co`. This configuration is only accessible in Debug mode in the `Settings` -> `Bank and Cash` section, so during the implementation it doesn't get much visibility. Setting the correct default for the localization helps prevent re-implementations and reduces accounting errors for companies. At present, the impact of this configuration can only be assessed after going live. [Task link](https://www.odoo.com/odoo/project.task/3990709) task-3990709 Forward-Port-Of: odoo/odoo#170732
[FIX] l10n_pk: script to auto trigger try_loading here->https://github.com/odoo/odoo/commit/049f2a2fad240e738b15794763b48e0e79bf50d3 We did a big improvement in the pk package but if the user tries to use the new stuff He won't have them because he needs to manually trigger the reload button in the configuration page solution: bump-up the package version and add a local script to automatically trigger that try_loading functionality task-id#3871597 --- I confirm I have signed the C
Original PR description
[FIX] l10n_pk: script to auto trigger try_loading here->https://github.com/odoo/odoo/commit/049f2a2fad240e738b15794763b48e0e79bf50d3 We did a big improvement in the pk package but if the user tries to use the new stuff He won't have them because he needs to manually trigger the reload button in the configuration page solution: bump-up the package version and add a local script to automatically trigger that try_loading functionality task-id#3871597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171361
This update aligns spreadsheet-related tests with the redesigned copy-to-clipboard experience. It helps ensure the improved clipboard interaction remains reliable for users working with documents and dashboards.
Original PR description
Adapt test for the new CopyClipboard design from https://github.com/odoo/odoo/pull/170310 task-3964629
Miscellaneous changes
Steps to Reproduce: ------------------- 1. Install hr_contract_salary module, create an advantage. 2. In the advantages 'Display Type' field should be 'Always selected'. 3. Leave the res_field_id field empty. 4. Put this advantage as Mandatory Advantage for another field. 5. Open Recruitement App, create and send an offer. 6. Go to Offers smart button and open the Offer link. 7. There will be an Internal Server Error. To resolve this issue we'll just continue wherever the res
Original PR description
Steps to Reproduce: ------------------- 1. Install hr_contract_salary module, create an advantage. 2. In the advantages 'Display Type' field should be 'Always selected'. 3. Leave the res_field_id…
Steps to Reproduce:
-------------------
1. Install hr_contract_salary module, create an advantage.
2. In the advantages 'Display Type' field should be 'Always selected'.
3. Leave the res_field_id field empty.
4. Put this advantage as Mandatory Advantage for another field.
5. Open Recruitement App, create and send an offer.
6. Go to Offers smart button and open the Offer link.
7. There will be an Internal Server Error.
To resolve this issue we'll just continue wherever the res_field_id is not set. Because
if the res_field_id is not set it'll have no value which in return gives False(bool) which
can't be appended.
Traceback:
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1770, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1797, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1914, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 725, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 231, in salary_package
values = self._get_default_template_values(contract, offer)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 131, in _get_default_template_values
values = self._get_salary_package_values(contract, offer)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 411, in _get_salary_package_values
mapped_benefits, mapped_dependent_benefits, mandatory_benefits, mandatory_benefits_names, benefit_types, dropdown_options_2, dropdown_group_options, initial_values_2 = self._get_benefits_values(contract, offer)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 397, in _get_benefits_values
dependent_name = dependent_benefit.field + '_' + dependent_benefit.display_type
TypeError: unsupported operand type(s) for +: 'bool' and 'str'
```
Forward-Port-Of: odoo/enterprise#62255This PR changes an enterprise test that failed with a community PR. Linked community PR: https://github.com/odoo/odoo/pull/166965 ### Steps to reproduce: - Create a company and a branch - Create a contact and assign him to the company created - Switch to the branch and go to the Contact app - You can't see the contact created ### Cause: A rule does not allow branches to see partners from the parent company. ### Solution: Change the rule to make partners accessible to branches. T
Original PR description
This PR changes an enterprise test that failed with a community PR. Linked community PR: https://github.com/odoo/odoo/pull/166965 ### Steps to reproduce: - Create a company and a branch - Create a contact and assign him to the company created - Switch to the branch and go to the Contact app - You can't see the contact created ### Cause: A rule does not allow branches to see partners from the parent company. ### Solution: Change the rule to make partners accessible to branches. This solution implies changing access rules defined in base to use the 'parent_of' operator. By changing it, I removed a performance improvement introduced so I needed to change performance tests counting queries to make them pass. opw-3927295 Forward-Port-Of: odoo/enterprise#65644 Forward-Port-Of: odoo/enterprise#63589
Duplicate emails were being sent out to employees because employees were being searched from user ids for each company, but each search was not filtered by the company. So if there was a user that had multiple employee records, all of their employee records on every company would be pulled up for every company on their database that had timesheet notifications on. For example if there were 4 companies and the employee had an employee record for each of them they would receive 16 emails in total.
Original PR description
Duplicate emails were being sent out to employees because employees were being searched from user ids for each company, but each search was not filtered by the company. So if there was a user that had multiple employee records, all of their employee records on every company would be pulled up for every company on their database that had timesheet notifications on. For example if there were 4 companies and the employee had an employee record for each of them they would receive 16 emails in total. 4 for each employee record. Adding to the search domain to only look for employees on the current company defined by the for loop avoids these duplicate emails. This is similar to a fix that was done on the manager notification emails here: https://github.com/odoo/enterprise/pull/52808 opw-3748426 Forward-Port-Of: odoo/enterprise#64291
ForecastedDetails template inheritance wrong declaration of name (sale_subscription_stock) Steps to Reproduce customer want to add an additional column to the ForecastedDetails template. customer able to do it to basic template But not for prepared inheritances in sale_subscription_stock. The problem is that system can’t resolve symbol e.g t-inherit="sale_subscription_stock.ForecastedDetails” because somebody declatest in code ```py <t name="sale_subscription_stock.ForecastedDet
Original PR description
ForecastedDetails template inheritance wrong declaration of name (sale_subscription_stock) Steps to Reproduce customer want to add an additional column to the ForecastedDetails template. customer able to do it to basic template But not for prepared inheritances in sale_subscription_stock. The problem is that system can’t resolve symbol e.g t-inherit="sale_subscription_stock.ForecastedDetails” because somebody declatest in code ```py <t name="sale_subscription_stock.ForecastedDetails" t-inherit="stock.ForecastedDetails" t-inherit-mode="extension"> instead <t t-name="sale_subscription_stock.ForecastedDetails" t-inherit="stock.ForecastedDetails" t-inherit-mode="extension"> ``` here is a issue link :- https://github.com/odoo/odoo/issues/167741 Forward-Port-Of: odoo/enterprise#65571 Forward-Port-Of: odoo/enterprise#64885
This module adds user facing elements to ecommerce (i.e. the Website > Shop). This results in part of the checkout process showing up in English when customers are using a language other than Spanish. We make an exception for translating a localization into a language other than the one spoken in the country it's specific to because this is customer facing (i.e. in the website) and we do not want to restrict the language of the potential ecommerce customers. Unfortunately some of the terms th
Original PR description
This module adds user facing elements to ecommerce (i.e. the Website > Shop). This results in part of the checkout process showing up in English when customers are using a language other than Spanish. We make an exception for translating a localization into a language other than the one spoken in the country it's specific to because this is customer facing (i.e. in the website) and we do not want to restrict the language of the potential ecommerce customers. Unfortunately some of the terms that show in the extra step added by this model are defined in other `l10n_mx_*` modules and since we don't want to have to track down only these specific terms or translate all of the Mexico localization into French, we leave some parts untranslated (specifically the invoicing specifics) opw-3881171 Forward-Port-Of: odoo/enterprise#65563
Current behavior in gstr1 report: - For invoices and credit notes, if there are nil rated tax grid journal items then these tax lines are considered in both GSTR summary tables i.e self category (b2b/b2c) table and nil category table. After fix: - Now, the journal items are considered for their respective GSTR summary tables only. - For, `special economic zone` the nil-rated journal items are considered in their category i.e b2b/b2cs/b2cl, not in the nil summary table. task-3866787 Fo
Original PR description
Current behavior in gstr1 report: - For invoices and credit notes, if there are nil rated tax grid journal items then these tax lines are considered in both GSTR summary tables i.e self category (b2b/b2c) table and nil category table. After fix: - Now, the journal items are considered for their respective GSTR summary tables only. - For, `special economic zone` the nil-rated journal items are considered in their category i.e b2b/b2cs/b2cl, not in the nil summary table. task-3866787 Forward-Port-Of: odoo/enterprise#65105 Forward-Port-Of: odoo/enterprise#61433
Before this PR: In Marketing Automation, upon opening a template form view, a duplicate button is displayed which won't be used. After this PR: Duplicate button is now hidden. Task - 3994775 Forward-Port-Of: odoo/enterprise#64993
Original PR description
Before this PR: In Marketing Automation, upon opening a template form view, a duplicate button is displayed which won't be used. After this PR: Duplicate button is now hidden. Task - 3994775 Forward-Port-Of: odoo/enterprise#64993
Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769 Forward-Port-Of: odoo/enterprise#64988 Forward-Port-Of: odoo/enterprise#63488
Original PR description
Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769 Forward-Port-Of: odoo/enterprise#64988 Forward-Port-Of: odoo/enterprise#63488
Before this commit, the search bar only look at the visible lines. With that a problem arise with hierarchy for example. When writing an account in the searchbar we want to search on the account.account and not the group. task: 3988840 Forward-Port-Of: odoo/enterprise#65101
Original PR description
Before this commit, the search bar only look at the visible lines. With that a problem arise with hierarchy for example. When writing an account in the searchbar we want to search on the account.account and not the group. task: 3988840 Forward-Port-Of: odoo/enterprise#65101