Thursday, October 17, 2024
37 changes · saas-17.4
Resolved issues and error corrections
This change makes an internal mail test more reliable by avoiding dependence on timing-sensitive scrolling events. It helps reduce false test failures, supporting smoother maintenance and release validation without changing end-user behavior.
Original PR description
The `scroll to the first unread message (slow ref registration)` test checks that clicking the unread message banner scrolls to the first unread message, even with delayed message loading. Previously, the test expected three `scrollend` events: - Scroll to top - Scroll to unread message - Minor scroll from highlight effect However, the highlight scroll sometimes fails to trigger if it starts before the second scroll ends, causing a missing `scrollend`. This PR resolves the issue by enhancing the `isInViewportOf` helper to listen for scroll events and assert directly, without relying on specific steps. runbot-69429739 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
This fix makes an accounting test independent from changes made by other tests by ensuring the test company partner and fiscal positions use the same country. It helps keep automated validation reliable, reducing false failures in the release process without changing customer-facing behavior.
Original PR description
The test_get_first_fiscal_position() was failing on the runbot since its addition. The failure occurred because the company's partner in the environment either had no country set or a different country from the two fiscal positions defined in the test. This led to incorrect or missing fiscal positions being selected in _get_fiscal_position(). The issue arose because other test classes modified the company’s country. To resolve this, the test partner is now explicitly assigned a country, and the fiscal positions are defined with the same country to maintain consistent priority levels compared to existing fiscal positions. This ensures the test remains isolated from external factors, verifying that when two fiscal positions have identical attributes except for sequence, the one with the lowest sequence is prioritized. Runbot issue: 98910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in the Indian Point of Sale flow where adding certain products to an order could cause an error if their HSN code was missing. Sales staff can now add those products without interruption, reducing checkout disruptions.
Original PR description
Before this commit, adding a product without the l10n_in_hsn_code field to an order would cause an error, as the system expected this field to be a string. opw-4254897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents website pages from failing when a table of contents section is removed before it has fully loaded, especially on mobile or pages with hidden content. It helps keep affected website pages stable while a deeper underlying issue is investigated.
Original PR description
A previous commit [1] fixed a bug where multiple "table of content" snippets were hidden in "mobile" view on a page (see commit message). However, this did not fix all cases. It is likely that with even more hidden elements on the page, the problem remains unresolved. We thought that await the start would solve the issue, but in some cases, the start wasn't even triggered by the time we reached the destroy. This commit fixes the issue by checking that the "this._scrollTarget" variable is initialized before removing its listener in the destroy. This bug requires more investigation, but this fix solves the issue for now. [1]: https://github.com/odoo/odoo/commit/ac5e9fe93c2158be1e8555de3da1419c69f543e5 task-4160033 opw-4228666 opw-4220959 opw-4226783
PDF generation no longer creates misleading device history entries such as “Linux - Safari” caused by the internal PDF tool. This keeps user device logs cleaner and avoids confusion when reviewing account activity.
Original PR description
During pdf generation, `wkhtmltopdf` creates device logs via a request whose user agent is: `Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34`. The result is that a `Linux - Safari` device log is created. This must be prevented (using the `_disable_trace` server-side mechanism of the session object).
This fix updates the demo setup for Colombia DIAN support documents so testing the DIAN web service no longer requires an extra manual step. It helps make validation smoother and reduces the chance of setup mistakes during testing.
Original PR description
This avoids a manual operation when testing DIAN's webservice for support documents. no task
Miscellaneous changes
When User Clicks on Send payment status to SInvoice action, a traceback will appear. Steps to reproduce the error: - Install ``l10n_vn_edi_viettel`` module - Switch to VN Company - Go to Invoicing > Customers > Invoices > Select any invoice > Actions > Send payment status to SInvoice Traceback: ``` SyntaxError: syntax error at or near ")" LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO... ^ File "odoo/tool
Original PR description
When User Clicks on Send payment status to SInvoice action, a traceback will appear. Steps to reproduce the error: - Install ``l10n_vn_edi_viettel`` module - Switch to VN Company - Go to Invoicing >…
When User Clicks on Send payment status to SInvoice action,
a traceback will appear.
Steps to reproduce the error:
- Install ``l10n_vn_edi_viettel`` module
- Switch to VN Company
- Go to Invoicing > Customers > Invoices > Select any invoice > Actions >
Send payment status to SInvoice
Traceback:
```
SyntaxError: syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
^
File "odoo/tools/safe_eval.py", line 391, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(2134,)", line 3, in <module>
File "addons/l10n_vn_edi_viettel/models/account_move.py", line 299, in action_l10n_vn_edi_update_payment_status
self.env['res.company']._with_locked_records(self)
File "addons/account/models/company.py", line 785, in _with_locked_records
self._cr.execute(f'SELECT * FROM {records._table} WHERE id IN %s FOR UPDATE SKIP LOCKED', [tuple(records.ids)])
File "odoo/sql_db.py", line 347, in execute
res = self._obj.execute(query, params)
ValueError: <class 'psycopg2.errors.SyntaxError'>: "syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
^
```
https://github.com/odoo/odoo/blob/072da22e72e66e6332d073502b987682f1b6e88b/addons/account/models/company.py#L745
Here, when there are no records for sending their payment status to SInvoice,
records.ids will be empty,
It will lead to the above traceback.
This commit will fix the above issue by preventing the execution of the query
when ``records.ids`` is empty.
sentry-5954926261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182621revert commit 30c561b422d58d7622f7ee173fae2f8158a14657 because it broke existing optimization and users were unable to access the website instead the functionality was moved to `_get_pl_partner_order()` because it's a cached method and the extra search added by the `.sorted()` wouldn't be an issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183805
Original PR description
revert commit 30c561b422d58d7622f7ee173fae2f8158a14657 because it broke existing optimization and users were unable to access the website instead the functionality was moved to `_get_pl_partner_order()` because it's a cached method and the extra search added by the `.sorted()` wouldn't be an issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183805
Currently there is the following problem when loading a chart template on a company. In case the company has no country set the loading of the template may set it. This can i.e. happen when the template specifies a `account_fiscal_country_id`. Setting a country on a company (`write`) may trigger the installation of additional localization modules related to the country (`install_l10n_modules`). The problematic `write` happens in `_pre_load_data` but the actual template data is not loaded y
Original PR description
Currently there is the following problem when loading a chart template on a company. In case the company has no country set the loading of the template may set it. This can i.e. happen when the…
Currently there is the following problem when loading a chart template on a company.
In case the company has no country set the loading of the template may set it.
This can i.e. happen when the template specifies a `account_fiscal_country_id`.
Setting a country on a company (`write`) may trigger the installation of additional
localization modules related to the country (`install_l10n_modules`).
The problematic `write` happens in `_pre_load_data` but the actual
template data is not loaded yet (happens later in `_load_data`).
This can cause the following 2 issues.
Issue (1)
The new modules may add new data to the current template (modifies the
result of `_get_chart_template_data`).
But this new data is not considered during the current loading
since the template data is fetched before the automatic installation happens.
The module may not work as intended for companies w/o the new data though.
So we would have to reload the chart template manually.
Issue (2)
The auto-installation happens after the chart template info (field `chart_template`)
is set on the company but before the data is actually loaded.
The module installation may trigger a post init hook to set up new
data on companies with the current template (field `chart_template`).
This new setup may rely on the chart template data (from before the
module was installed) being laoded already though.
Issue (2) i.e. causes runbut build error-60149.
During the populate test a company with chart_template 'generic_coa'
is created which causes the installation of module `l10n_us_reports`
during the 'generic_coa' chart template loading.
There the deferred expense and revenue accounts are loaded in a post init hook
via `_load_data` for every company where the `chart_template` field has value 'generic_coa'.
```python
ChartTemplate._load_data({
'res.company': , {
company.id: {
'deferred_expense_account_id': 'prepaid_expenses',
'deferred_revenue_account_id': 'deferred_revenue',
}
}
})
```
Here 'prepaid_expenses' and 'deferred_revenue' are xmlids of accounts of the
'generic_coa' chart template from module 'account'.
Since the template data has not been loaded yet we cannot derefence
these 2 xmlids. In the log we get the following warning:
> Failed when trying to recover prepaid_expenses for field=res.company.deferred_expense_account_id
To avoid this problem we just skip the automatic installing in case we are in the process
of loading a chart template.
runbot build error-60149
Forward-Port-Of: odoo/odoo#183792Steps --- * In the setting enable *Multi Step Routes* * Create an internal transfer with 1 operation for some product > *Mark as Todo* * On the stock.move operation line click the list icon for detailed operations. * *Add a line* => this opens a Wizard where we can choose the quant from which to pick the product for the sml * After adding the line *Add a line* again, we cannot pick the same quant Use case --- For internal transfers, we would like to be able to pick products from the s
Original PR description
Steps --- * In the setting enable *Multi Step Routes* * Create an internal transfer with 1 operation for some product > *Mark as Todo* * On the stock.move operation line click the list icon for detailed operations. * *Add a line* => this opens a Wizard where we can choose the quant from which to pick the product for the sml * After adding the line *Add a line* again, we cannot pick the same quant Use case --- For internal transfers, we would like to be able to pick products from the same quant and dispatch them to several sub-locations of the picking's destination location. Side Fix --- Delete `onRecordDiscarted` method, which wasn't being used because of the typo and doesn't appear to be necessary. opw-4072541 Co-authored-by: @ajf-odoo Forward-Port-Of: odoo/odoo#183815 Forward-Port-Of: odoo/odoo#174984
When changing the move associated with the bank statement line we i.e. update the `amount_currency` field on the bank statement line. But currently we just set it to the `amount_currency` value of the suspense line. This may not be correct in case we also have other lines on the move: We should have (liquidity = suspense + other) and the `amount_currency` on the bank statement line expresses the liquidity (total amount) and not the suspense (residual amount). After this commit we also include t
Original PR description
When changing the move associated with the bank statement line we i.e. update the `amount_currency` field on the bank statement line. But currently we just set it to the `amount_currency` value of the suspense line. This may not be correct in case we also have other lines on the move: We should have (liquidity = suspense + other) and the `amount_currency` on the bank statement line expresses the liquidity (total amount) and not the suspense (residual amount). After this commit we also include the other lines in the computation. (Note: We cannot just use the liquidity line It is in journal currency / company currency but the `amount_currency` of the bank statement line may be in a foreign currency that is neither the company nor the journal currency.) enterprise PR which needs the change: https://github.com/odoo/enterprise/pull/71243 Forward-Port-Of: odoo/odoo#182589
The LATERAL was destroying perfs to compute the account roots. It took more than 7 sec on a db that only had 660k move lines. Replaced it by a simple JOIN which reduced it to 1.2 sec. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183458 Forward-Port-Of: odoo/odoo#170689
Original PR description
The LATERAL was destroying perfs to compute the account roots. It took more than 7 sec on a db that only had 660k move lines. Replaced it by a simple JOIN which reduced it to 1.2 sec. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183458 Forward-Port-Of: odoo/odoo#170689
*purchase,repair,sale,stock Related to https://github.com/odoo/enterprise/pull/71384
Original PR description
*purchase,repair,sale,stock Related to https://github.com/odoo/enterprise/pull/71384
Issue ----- The activities from the calendar, which should be today's meetings, are in some circumstances displaying meetings from the next day. Steps ----- - Set the user timezone to "Asia/Manila". - In Calendar, create a meeting early (before 18:00) the next day. - Check the activities (clock in the navbar), tomorrow's meeting appears. Cause ----- `datetime.datetime` objects are not timezone aware, and using the `replace` function on them will simply lead to a naive convers
Original PR description
Issue
-----
The activities from the calendar, which should be today's
meetings, are in some circumstances displaying meetings
from the next day.
Steps
-----
- Set the user timezone to "Asia/Manila".
- In Calendar, create a meeting early (before 18:00) the
next day.
- Check the activities (clock in the navbar), tomorrow's
meeting appears.
Cause
-----
`datetime.datetime` objects are not timezone aware, and using
the `replace` function on them will simply lead to a naive
conversion which causes potential issues.
Example:
```
import pytz
import datetime
dt = datetime.datetime(2024,1,1,0,0)
dt = dt.replace(tzinfo=pytz.timezone("Asia/Manila")).astimezone(pytz.UTC)
print(dt)
>>> 2024-01-01 15:56:00+00:00 # 1 day offset to expected result
```
Instead, it is better to use the pytz `localize` function.
opw-4142911
Forward-Port-Of: odoo/odoo#181795- sale_project: fix domain as it is not possible to select a SOL on a task in the case where the SOL's contact belongs to the same company than the contact set as the task's customer. The `.id` was removed by https://github.com/odoo/odoo/commit/e095ef5153fb1a8364a4f53896a522fefa35ecd9 and is actually necessary if we want to have SOLs where the `order_partner_id` is the parent of the `partner_id` or shares the same parent than `parent_id`. - sale: remove SOLs of discount products from th
Original PR description
- sale_project: fix domain as it is not possible to select a SOL on a task in the case where the SOL's contact belongs to the same company than the contact set as the task's customer. The `.id` was removed by https://github.com/odoo/odoo/commit/e095ef5153fb1a8364a4f53896a522fefa35ecd9 and is actually necessary if we want to have SOLs where the `order_partner_id` is the parent of the `partner_id` or shares the same parent than `parent_id`. - sale: remove SOLs of discount products from the SOLs considered as sellable. The discount products are "fake" products used to manage discounts. opw-4212956 Forward-Port-Of: odoo/odoo#183121
Commands that stop and start the LED service in `posbox_update.sh` were removed in commit `bf96199`, however these were necessary to prevent the filesystem getting stuck in write-mode and potentially getting corrupted (see #54339). The fix is to restore these commands in `posbox_update.sh`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183868
Original PR description
Commands that stop and start the LED service in `posbox_update.sh` were removed in commit `bf96199`, however these were necessary to prevent the filesystem getting stuck in write-mode and potentially getting corrupted (see #54339). The fix is to restore these commands in `posbox_update.sh`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183868
Issue: ===== The cover template of the training theme template doesn't show in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing with training template - Send a test email - Cover snippet missing Origin of the issue: ==================== While converting the template from bootstrap to table we expect to have `container` -> `row` -> `col` classes but the template was missing the `col` class opw-3944347 Forward-Port-Of: odoo/odoo#1
Original PR description
Issue: ===== The cover template of the training theme template doesn't show in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing with training template - Send a test email - Cover snippet missing Origin of the issue: ==================== While converting the template from bootstrap to table we expect to have `container` -> `row` -> `col` classes but the template was missing the `col` class opw-3944347 Forward-Port-Of: odoo/odoo#183105
Versions -------- - 17.0+ Steps ----- 1. Have an SO selling a timesheet-based service; 2. have at least some hours delivered via timesheets; 3. click on "Create Invoice"; 4. select a date for "Timesheets Period". Issue ----- It first shows a datepicker for only the start date, only after closing it can you select a second date. Cause ----- The `daterange` widget doesn't actually default to a range, unless the date field is marked as required. As seen in the `isRange` funct
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an SO selling a timesheet-based service; 2. have at least some hours delivered via timesheets; 3. click on "Create Invoice"; 4. select a date for "Timesheets Period". Issue ----- It first shows a datepicker for only the start date, only after closing it can you select a second date. Cause ----- The `daterange` widget doesn't actually default to a range, unless the date field is marked as required. As seen in the `isRange` function, it opens a range picker when there are two values present, the field is required, or the `alwaysRange` property is `true`: https://github.com/odoo/odoo/blob/39029710bbce55889c6b951fc423c1254e05ff22/addons/web/static/src/views/fields/datetime/datetime_field.js#L215-L224 Solution -------- Force the range picker on the `daterange` widget by setting the `always_range` option. opw-4049959 Forward-Port-Of: odoo/odoo#181079
# Issue: When creating a vendor bill for a non EU partner, setting the tax to "22% G RC (Goods)" and generating the XML file, checking the generated XML file gives the error: "Tipo Documento must not be empty." # Steps to reproduce: - create a vendor bill with a non EU partner - add a product with tax "22% G RC (Goods)" - post the bill - click Send Tax Integration - check the generated XML file using an online checker like www.fatturacheck.it - it will show the error "Tipo Documento mu
Original PR description
# Issue: When creating a vendor bill for a non EU partner, setting the tax to "22% G RC (Goods)" and generating the XML file, checking the generated XML file gives the error: "Tipo Documento must not…
# Issue: When creating a vendor bill for a non EU partner, setting the tax to "22% G RC (Goods)" and generating the XML file, checking the generated XML file gives the error: "Tipo Documento must not be empty." # Steps to reproduce: - create a vendor bill with a non EU partner - add a product with tax "22% G RC (Goods)" - post the bill - click Send Tax Integration - check the generated XML file using an online checker like www.fatturacheck.it - it will show the error "Tipo Documento must not be empty." # Solution: - The document type is usually computed. However, in this specific case, it cannot be computed because it does not meet any of the conditions in the computation logic. Additionally, there is no safeguard to prevent the generation of the XML file if the document type is not set. - A check has been added to prevent XML generation when the document type is not set, ensuring the document type is always correctly provided before XML generation. opw-4182531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180364
**Behaviour before PR:** - In chatgpt prompt dialog, `submitPrompt` method gets called twice when user presses `ctrl + enter` after writing something. As result chatgpt responds twice with same content. This happens because in `dialog.js` a hotkey service is active on `ctrl + enter` which is responsible to trigger a click event on submit button of dialog and `submitPrompt` gets called second time. - Moreover, if text-area is empty and user hits `enter` then an empty prompt is sent to chatGPT
Original PR description
**Behaviour before PR:** - In chatgpt prompt dialog, `submitPrompt` method gets called twice when user presses `ctrl + enter` after writing something. As result chatgpt responds twice with same content. This happens because in `dialog.js` a hotkey service is active on `ctrl + enter` which is responsible to trigger a click event on submit button of dialog and `submitPrompt` gets called second time. - Moreover, if text-area is empty and user hits `enter` then an empty prompt is sent to chatGPT resulting in a meaningless response. **Behaviour after PR:** - Now, `submitPrompt` method gets called once on `ctrl + enter.` - If text-area is empty then pressing `enter` will not submit prompt. task-4207108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181334
Steps to reproduce ================== - Go to CRM - Open a lead - Open studio - Add a new notebook page - Add a many2many field - Select the task model - Save and exit studio - Switch to the new notebook page - Add a new task => Record does not exist or has been deleted. Cause of the issue ================== The CrmFormRecord is also used for the Many2Many popup. project.task also has a stage_id field, checkRainbowmanMessage is then called, but with the id of the task ht
Original PR description
Steps to reproduce ================== - Go to CRM - Open a lead - Open studio - Add a new notebook page - Add a many2many field - Select the task model - Save and exit studio - Switch to the new notebook page - Add a new task => Record does not exist or has been deleted. Cause of the issue ================== The CrmFormRecord is also used for the Many2Many popup. project.task also has a stage_id field, checkRainbowmanMessage is then called, but with the id of the task https://github.com/odoo/odoo/blob/54d6a19444bfa4f01d03117e4542a5244f274429/addons/crm/static/src/views/crm_form/crm_form.js#L44-L51 Solution ======== It makes no sense to do this if we are not acting on a crm.lead record => We check the resModel before proceeding opw-4101752 Forward-Port-Of: odoo/odoo#183375
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a local server): - Activate the developer mode - Navigate to Website and click on "Go to Website" - Click on the menu "Pages" > "Manage Pages" - At the /contactus line, click on the "bug" button to access the view - Click on "Edit" to be able to change the architecture - Add something that
Original PR description
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a…
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a local server): - Activate the developer mode - Navigate to Website and click on "Go to Website" - Click on the menu "Pages" > "Manage Pages" - At the /contactus line, click on the "bug" button to access the view - Click on "Edit" to be able to change the architecture - Add something that breaks the view in the template (i.e : ```<p t-field="no_field.exists"></p>```) - Click on "Save" and after "Go to Page Manager" - Click on the /contactus url link - An internal server error page appears with the possibility to restore the previous version of the view (soft reset) or to reset to initial version (hard reset). Click on "Hard Reset" - With your DB manager, search in the table ir.ui.view, the record with the key website.contactus. Observe that the field arch_updated is still True while the view is reset and shouldn't be in an updated state. This commit ensures consistent updating of this field. A "Hard" reset of a broken view will remove its previous architecture used for "Soft" reset, since there is no real usage where a "Previous" reset is needed after a "Hard" one. [1]: https://github.com/odoo/odoo/commit/479585140caca9fdc758709f043da500297e8046 task-3743850 Forward-Port-Of: odoo/odoo#164929
Steps to reproduce: - Install Timesheet - Delete all tasks - Run server actions to create tasks with the following scripts https://gist.github.com/mattismegevand/5db26ee9d1e7756e7fe4600897244c1e - Go to Project -> Tasks -> All tasks - Switch to calendar view and go to june 2024 Issues: A traceback appears, the cause is an infinite recursion caused by the computation of the intersection. Since two events are next to each other their intersection is null but fullcalendar try to compute it
Original PR description
Steps to reproduce: - Install Timesheet - Delete all tasks - Run server actions to create tasks with the following scripts https://gist.github.com/mattismegevand/5db26ee9d1e7756e7fe4600897244c1e - Go to Project -> Tasks -> All tasks - Switch to calendar view and go to june 2024 Issues: A traceback appears, the cause is an infinite recursion caused by the computation of the intersection. Since two events are next to each other their intersection is null but fullcalendar try to compute it anyway which leads to the intersection span being null which causes a traceback. I suspect that the fix is https://github.com/fullcalendar/fullcalendar/commit/362a37345a4b7cb65d16f345e8555f727f1c8450 However for good measure and to fix preemptively other bug from fullcalendar an update seems like the best decision. opw-3997810 Forward-Port-Of: odoo/odoo#183151
When reconciliing and invoice with a misc entry line, we display the amount currency of the total amount of the entry instead of the partial. Steps: - With USD company currency and EUR foreign currency - Make an invoice for 2000 EUR - Register a payment for 1000 EUR - Make a journal entry in USD, 3 credit lines 1000 USD each on the receivable account, for the invoice's partner - Come back to the invoice and reconcile it with two misc lines via the outstanding credit widget - O
Original PR description
When reconciliing and invoice with a misc entry line, we display the amount currency of the total amount of the entry instead of the partial. Steps: - With USD company currency and EUR foreign currency - Make an invoice for 2000 EUR - Register a payment for 1000 EUR - Make a journal entry in USD, 3 credit lines 1000 USD each on the receivable account, for the invoice's partner - Come back to the invoice and reconcile it with two misc lines via the outstanding credit widget - Open the payment and print the payment receipt -> The Amount Currency column of the misc entry lines show -$3000 instead of $-1000 and $-528.89 (depending of the current rate) With this commit we take the debit or credit amount currency from the partial instead of the total amount of the entry. opw-4089534 Forward-Port-Of: odoo/odoo#183819 Forward-Port-Of: odoo/odoo#180189
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#72140 Forward-Port-Of: odoo/enterprise#71782
Original PR description
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#72140 Forward-Port-Of: odoo/enterprise#71782
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/
Original PR description
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/comunicacion/publicaciones/operaciones-moneda-extranjera. latam-task: 1264 adhoc-side-task: 43762 Forward-Port-Of: odoo/enterprise#70335
When doing a groupby on a non-relational field (e.g. a char), if the field contains NULL values in DB, they appear as `None` in the keys of the `group_lines_by_keys` dict. If the comparison operator is not implemented between the field type and `NoneType`, `sorted` will fail with a traceback. Solution: sort on keys `(k is None, k)`. if k is None, then `k is None = True`. Because `True > False`, these values are pushed to the end by the sorting. task-none Forward-Port-Of: odoo/enterpri
Original PR description
When doing a groupby on a non-relational field (e.g. a char), if the field contains NULL values in DB, they appear as `None` in the keys of the `group_lines_by_keys` dict. If the comparison operator is not implemented between the field type and `NoneType`, `sorted` will fail with a traceback. Solution: sort on keys `(k is None, k)`. if k is None, then `k is None = True`. Because `True > False`, these values are pushed to the end by the sorting. task-none Forward-Port-Of: odoo/enterprise#72008
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always displays the full amount; even if the move is partly "reconciled" already. 3. Duplicate entries can appear. All issues are solved by rewriting the generation logic a bit. Issue (1) i.e. happens due to move lines with a 0 balance in the move associated with the bank statement (line). All
Original PR description
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always…
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always displays the full amount; even if the move is partly "reconciled" already. 3. Duplicate entries can appear. All issues are solved by rewriting the generation logic a bit. Issue (1) i.e. happens due to move lines with a 0 balance in the move associated with the bank statement (line). All 3 issues can happen due to the way the entries in the report are generated: Consider a single bank statement (line) / its associated "bank move". To generate the line the report we join the bank statement line and bank move to each line of the bank move (except the liquidity line). The report groups by move line id. This generates 1 row in the report per move line (except the liquidity line) of the bank move. This directly causes issue (3). It also causes issue (2) due to the following: The reason we join all the move lines in the first place is to compute the unreconciled amount of the bank move. (By summing amounts on the move lines). But when generating a single row of the report we only have the information about 1 line (due to the grouping by id) and not the whole sum. Thus we do not have the full residual information. opw-4178134 (Issue 1) community PR: https://github.com/odoo/odoo/pull/182589 Forward-Port-Of: odoo/enterprise#71243
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time wit
Original PR description
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time without taking into consideration that there might be a break hour in the middle of the duration. **Desired behavior after PR is merged:** We are now considering the employee resource calendar in our calculation for the time of the slot. opw-3890629 Forward-Port-Of: odoo/enterprise#71914 Forward-Port-Of: odoo/enterprise#63002
*account_followup,industry_fsm,sale_renting Related to https://github.com/odoo/odoo/pull/182620
Original PR description
*account_followup,industry_fsm,sale_renting Related to https://github.com/odoo/odoo/pull/182620
It’s too easy to forget to set the right group opw-4206894 Forward-Port-Of: odoo/enterprise#71907 Forward-Port-Of: odoo/enterprise#70894
Original PR description
It’s too easy to forget to set the right group opw-4206894 Forward-Port-Of: odoo/enterprise#71907 Forward-Port-Of: odoo/enterprise#70894
Before this commit, tests were skipped without using self.skipTest which is not a good practice. Moreover, assertAlmostEqual was not properly used in an older version. ssertAlmostEqual should be used to compare amounts but it can be called with place, delta and message. The named argument should be used correctly. See https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual The msg parameter should be explicitely named. Runbots: https://runbot.odoo.com/web
Original PR description
Before this commit, tests were skipped without using self.skipTest which is not a good practice. Moreover, assertAlmostEqual was not properly used in an older version. ssertAlmostEqual should be used…
Before this commit, tests were skipped without using self.skipTest which is not a good practice. Moreover, assertAlmostEqual was not properly used in an older version. ssertAlmostEqual should be used to compare amounts but it can be called with place, delta and message. The named argument should be used correctly. See https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual The msg parameter should be explicitely named. Runbots: https://runbot.odoo.com/web/#id=102838&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102837&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102836&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102835&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=102834&view_type=form&model=runbot.build.error&menu_id=405&cids=1 Forward-Port-Of: odoo/enterprise#71974
Problem: The `is_available` flag was used to check both product availability and conflicts with other rentals. However, the UI message was misleading, stating "Other rental(s) in conflict" even when the product was simply not available. Steps to reproduce: - Create a rental product with a quantity of 0. - Add a rental order for that product. - In the Schedule Gantt view, hover over the order. - A warning appears stating "Other rental(s) in conflict," even though no other rentals exist
Original PR description
Problem: The `is_available` flag was used to check both product availability and conflicts with other rentals. However, the UI message was misleading, stating "Other rental(s) in conflict" even when the product was simply not available. Steps to reproduce: - Create a rental product with a quantity of 0. - Add a rental order for that product. - In the Schedule Gantt view, hover over the order. - A warning appears stating "Other rental(s) in conflict," even though no other rentals exist on the same date; the actual issue is that the product is not available. opw-4085496 Forward-Port-Of: odoo/enterprise#69783
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard. error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])` This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model. This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records. sentry-56
Original PR description
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard.
error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])`
This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model.
This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records.
sentry-5657224204
Forward-Port-Of: odoo/enterprise#71360Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company') By removing the countries field from the manifest, the modules now auto-install as expected, and the test
Original PR description
Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company')
By removing the countries field from the manifest, the modules now auto-install as expected, and the test no longer fails. But why? If a module depends on another module that has the countries attribute, there’s no need to include it back; the auto-installation will only be triggered if there is a company that belongs to that country.
Forward-Port-Of: odoo/enterprise#72132Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528 Forward-Port-Of: odoo/enterprise#71737
Original PR description
Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528 Forward-Port-Of: odoo/enterprise#71737
Before this commit, the data given to the spreadsheet init callback in the case of inserting a pivot view was not used. This could lead to an error if the data was too big to be stored in the browser's session storage. This commit removes the useless data given to the spreadsheet init. Note that it's not necessary to write a new test for this, as the existing tests already cover this case. Task: 4255049 Forward-Port-Of: odoo/enterprise#71847
Original PR description
Before this commit, the data given to the spreadsheet init callback in the case of inserting a pivot view was not used. This could lead to an error if the data was too big to be stored in the browser's session storage. This commit removes the useless data given to the spreadsheet init. Note that it's not necessary to write a new test for this, as the existing tests already cover this case. Task: 4255049 Forward-Port-Of: odoo/enterprise#71847