Daily updates from Odoo
Navigate
Branch
Tuesday, October 29, 2024
63 changes
20 changes
Miscellaneous changes
Sometimes when renaming the IoT box, it would instead rename to `localhost.localdomain`. This was due to the script writing to the `/tmp` directory, which sometimes gets full and causes the `/etc/hostname` file to become empty. The fix is simply to bypass using the `/tmp` directory at all in the script. task-4210432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184843
Original PR description
Sometimes when renaming the IoT box, it would instead rename to `localhost.localdomain`. This was due to the script writing to the `/tmp` directory, which sometimes gets full and causes the `/etc/hostname` file to become empty. The fix is simply to bypass using the `/tmp` directory at all in the script. task-4210432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184843
When downloading a url type attachment, it will not open in a new tab and breaks the activity of the current tab,such as rtc call and breadcrumbs. To reproduce the error: Project > Task > click on the url attachment > open in the current tab, the breadcrumbs (previous filters) will be lost This commit fixes the issue by opening the url attachment in a new tab. And "downloading" a url does not make sense, so the download button is replaced by an open button. --- I confirm I have signed
Original PR description
When downloading a url type attachment, it will not open in a new tab and breaks the activity of the current tab,such as rtc call and breadcrumbs. To reproduce the error: Project > Task > click on the url attachment > open in the current tab, the breadcrumbs (previous filters) will be lost This commit fixes the issue by opening the url attachment in a new tab. And "downloading" a url does not make sense, so the download button is replaced by an open button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185550 Forward-Port-Of: odoo/odoo#184264
Same issue as https://github.com/odoo/odoo/pull/126323 but with CSV, TXT and other types of files. This basically overrides the default decoding charset of the email python module to use utf-8 by default. As mentioned in the PR above, utf-8 is a superset of the ascii encoding and this should not cause other issues. opw-4237114 opw-4245261 Forward-Port-Of: odoo/odoo#185360 Forward-Port-Of: odoo/odoo#184295
Original PR description
Same issue as https://github.com/odoo/odoo/pull/126323 but with CSV, TXT and other types of files. This basically overrides the default decoding charset of the email python module to use utf-8 by default. As mentioned in the PR above, utf-8 is a superset of the ascii encoding and this should not cause other issues. opw-4237114 opw-4245261 Forward-Port-Of: odoo/odoo#185360 Forward-Port-Of: odoo/odoo#184295
**Current behavior:** Selling a kit bom product will result in inaccurate journal entries in the stock output and expense accounts, the amount_currency field will only reflect the price unit of the kit's components. **Expected behavior:** The price unit should reflect the total cost of the components on the BoM: e.g., if a kit product needs 4 of some component1, the price unit should be 4 * component1.standard_price. **Steps to reproduce:** 1. Create a kit product with 2 components, bot
Original PR description
**Current behavior:** Selling a kit bom product will result in inaccurate journal entries in the stock output and expense accounts, the amount_currency field will only reflect the price unit of the…
**Current behavior:** Selling a kit bom product will result in inaccurate journal entries in the stock output and expense accounts, the amount_currency field will only reflect the price unit of the kit's components. **Expected behavior:** The price unit should reflect the total cost of the components on the BoM: e.g., if a kit product needs 4 of some component1, the price unit should be 4 * component1.standard_price. **Steps to reproduce:** 1. Create a kit product with 2 components, both with qty > 1 2. Assign dropshipping to the kit 3. Create a sale order and confirm -> confirm the purchase order 4. Validate the dropship transfer, invoice the sale order and post it 5. See the 2 inaccurate journal entries, where the debit/credit respectively only total to one instance of each component's cost added together **Cause of the issue:** The price unit calculation didn't look at the bom line product qty, only using the price unit 1 time per component. **Fix:** Multiply the value by the quantity of it required on its line in the BoM. opw-4253827 Forward-Port-Of: odoo/odoo#185247 Forward-Port-Of: odoo/odoo#183916
Before this commit, it was showing a "enable push notification" messaging menu item on iOS devices. This item was persistent and could not be removed, because iOS does not allow to enable specifically push notifcation on web apps, except if there are installed as PWA in which case they necessarily authorized push notifications based on OS app preferences. opw-4236170 Backport of https://github.com/odoo/odoo/pull/178057 Forward-Port-Of: odoo/odoo#185245
Original PR description
Before this commit, it was showing a "enable push notification" messaging menu item on iOS devices. This item was persistent and could not be removed, because iOS does not allow to enable specifically push notifcation on web apps, except if there are installed as PWA in which case they necessarily authorized push notifications based on OS app preferences. opw-4236170 Backport of https://github.com/odoo/odoo/pull/178057 Forward-Port-Of: odoo/odoo#185245
**Current behavior before PR:** Before this commit: Bus channels were not added every time when threads were opened, preventing real-time messaging in some cases. **Desired behavior after PR is merged:** Added bus channel subscription when opening threads, enabling proper channel name display and real-time messaging functionality. Task:[3899453](https://www.odoo.com/odoo/project/1519/tasks/3899453) --- I confirm I have signed the CLA and read the PR guidelines at www.odo
Original PR description
**Current behavior before PR:** Before this commit: Bus channels were not added every time when threads were opened, preventing real-time messaging in some cases. **Desired behavior after PR is merged:** Added bus channel subscription when opening threads, enabling proper channel name display and real-time messaging functionality. Task:[3899453](https://www.odoo.com/odoo/project/1519/tasks/3899453) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174473
Steps to reproduce: - Install `website_event_sale` - Go to an event and for one ticket set maximum as 1 - Open event page and purchase a ticket, but don't complete the payment - Do the same in private navigation - Click on pay on the two page Issues: If you check with stripe payment is processed meaning that the two people are charged however one of them can't get a ticket as there isn't enough tickets available. Fix is to check before sending payment to provider and return error if the
Original PR description
Steps to reproduce: - Install `website_event_sale` - Go to an event and for one ticket set maximum as 1 - Open event page and purchase a ticket, but don't complete the payment - Do the same in private navigation - Click on pay on the two page Issues: If you check with stripe payment is processed meaning that the two people are charged however one of them can't get a ticket as there isn't enough tickets available. Fix is to check before sending payment to provider and return error if there's not enough seats. Concurrency issue is not fully solved but would require much more precise timing, and a proper solution wouldn't be stable. opw-3772093 Forward-Port-Of: odoo/odoo#173809
Steps to reproduce: 1. Navigate to Pricelists. 2. Import a CSV or XLSX file that contains at least one product or product variant. 3. Duplicate the newly created pricelist. Issue: - When duplicating an imported pricelist, the duplicated record does not retain the product or product variant information. Cause: - If the applied_on field is not provided during the creation of the pricelist item, the default value of 3_global is applied. - As a result, when duplicating the pricelis
Original PR description
Steps to reproduce: 1. Navigate to Pricelists. 2. Import a CSV or XLSX file that contains at least one product or product variant. 3. Duplicate the newly created pricelist. Issue: - When duplicating an imported pricelist, the duplicated record does not retain the product or product variant information. Cause: - If the applied_on field is not provided during the creation of the pricelist item, the default value of 3_global is applied. - As a result, when duplicating the pricelist, the product_tmpl_id and product_id fields are set to None. Fix: - When the applied_on field is missing during the creation of a new pricelist item, set it based on the presence of the relevant fields (such as product or product variant). opw-4170242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185100
There were some cache inconsistencies when computing remaining leaves on the dashboard or in the accrual scheduled actions due to commit 7ef0ad2. The cache invalidation is necessary to avoid issues when the call to process_accrual is made twice in a row, but the cache invalidation was too broad. This commit aims at only invalidating the part of the cache that were causing issues when computing the remaining leaves. opw-4167557 opw-4167582 opw-4175815 opw-4149134 opw-4241970 Forward
Original PR description
There were some cache inconsistencies when computing remaining leaves on the dashboard or in the accrual scheduled actions due to commit 7ef0ad2. The cache invalidation is necessary to avoid issues when the call to process_accrual is made twice in a row, but the cache invalidation was too broad. This commit aims at only invalidating the part of the cache that were causing issues when computing the remaining leaves. opw-4167557 opw-4167582 opw-4175815 opw-4149134 opw-4241970 Forward-Port-Of: odoo/odoo#180832
"Tax Receivable" account shouldn't be set as a receivable account, but as a current assets one, else it will appear in aged reports, which does not make sense. Similar to the fix already made here for "Tax Payable": https://github.com/odoo/odoo/commit/2318e671c3a5535590fe6d95949835417856dce6 Forward-Port-Of: odoo/odoo#185141
Original PR description
"Tax Receivable" account shouldn't be set as a receivable account, but as a current assets one, else it will appear in aged reports, which does not make sense. Similar to the fix already made here for "Tax Payable": https://github.com/odoo/odoo/commit/2318e671c3a5535590fe6d95949835417856dce6 Forward-Port-Of: odoo/odoo#185141
Steps to reproduce ================== - Install stock,mrp,web_studio - Go to Inventory > Delivery Orders - Open WH/OUT/00001 - Open studio - On the x2many field, click on "Edit form" -> Studio switches to that view, - Click on "Edit form" again for the new lines - Exit studio - Click on the hamburger button -> The styling is broken Cause of the issue ================== When clicking on "Edit form", studio inlines the selected form view. The nosheet form style is only applied if
Original PR description
Steps to reproduce ================== - Install stock,mrp,web_studio - Go to Inventory > Delivery Orders - Open WH/OUT/00001 - Open studio - On the x2many field, click on "Edit form" -> Studio switches to that view, - Click on "Edit form" again for the new lines - Exit studio - Click on the hamburger button -> The styling is broken Cause of the issue ================== When clicking on "Edit form", studio inlines the selected form view. The nosheet form style is only applied if the form contains no sheet element. In this case, there is a sheet element, but inside a nested form. Solution ======== Only consider sheets if they are part of the current form view. opw-4130337 Forward-Port-Of: odoo/odoo#185504
Steps to reproduce: - insert a pivot with more rows than columns - write in a cell =TRANSPOSE(ODOO.PIVOT.TABLE(1)) - right-click on the grand total value => boom When computing which cell of the pivot table is clicked, we assume the matrix comes directly from the ODOO.PIVOT.TABLE(...) function to compute the offsets from the array formula. But it's completely wrong as the cell could at a completely different place if the matrix is manipulated by other functions before being outputted
Original PR description
Steps to reproduce: - insert a pivot with more rows than columns - write in a cell =TRANSPOSE(ODOO.PIVOT.TABLE(1)) - right-click on the grand total value => boom When computing which cell of the pivot table is clicked, we assume the matrix comes directly from the ODOO.PIVOT.TABLE(...) function to compute the offsets from the array formula. But it's completely wrong as the cell could at a completely different place if the matrix is manipulated by other functions before being outputted to the grid. Task: 4292134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185534
When model selection field is used in a form, its default value is always one of the available values. Because of this, if the field is required, it does not force the user to pick a value, but it provides a possibly incorrect default value. This commit makes an empty value available for selection if no default value is chosen. The behavior is also made available on custom fields, if such an empty value had been manually created, it will be replaced by this implementation. Steps to
Original PR description
When model selection field is used in a form, its default value is always one of the available values. Because of this, if the field is required, it does not force the user to pick a value, but it provides a possibly incorrect default value. This commit makes an empty value available for selection if no default value is chosen. The behavior is also made available on custom fields, if such an empty value had been manually created, it will be replaced by this implementation. Steps to reproduce: - Install website_form_project - Add a form in a page - Select the "Create a Task" action - Add the "Analytic Account" field to the form - Make the field required => There was no way to have no default value by default. opw-4268164 Forward-Port-Of: odoo/odoo#184842
Currently the `report_stock_quantity` view third `UNION ALL` does a `generate_series` between the moves date and `now()` in case the move is not in done. This can lead to significant slowdowns when querying the view in case some databases have old moves not in done, cancel, draft. In that case, the report will generate a row for each day between the move.date and `now()`, leading to thousands of rows for 1 stock.move. To alleviate that, this commit uses the `report_period` as a lower bound
Original PR description
Currently the `report_stock_quantity` view third `UNION ALL` does a `generate_series` between the moves date and `now()` in case the move is not in done. This can lead to significant slowdowns when querying the view in case some databases have old moves not in done, cancel, draft. In that case, the report will generate a row for each day between the move.date and `now()`, leading to thousands of rows for 1 stock.move. To alleviate that, this commit uses the `report_period` as a lower bound. This greatly reduces the number of rows generated by the third `UNION ALL` without losing forecasted accuracy since the moves are not in done. #### speedup In a v17 database where `all_sm` returns 600 000 rows, querying the `report_stock_quantity` view goes from 20s -> 7s. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179359
As VISA added more mandatory fields to perform payments, the holder's name is required now for the customer to fill when paying with adyen. opw-4085163 Forward-Port-Of: odoo/odoo#185253
Original PR description
As VISA added more mandatory fields to perform payments, the holder's name is required now for the customer to fill when paying with adyen. opw-4085163 Forward-Port-Of: odoo/odoo#185253
This completes https://github.com/odoo/odoo/pull/171784 by adding support for the same kind of rrule string, but without the `RRULE;` prefix. Based on Real World™️ evidence. Description of the issue/feature this PR addresses: <details> ``` odoo-1 | 2024-10-24 11:20:18,785 42 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : unsupported property: ! odoo-1 | Traceback (most recent call last): odoo-1 | File "/opt/odoo/auto
Original PR description
This completes https://github.com/odoo/odoo/pull/171784 by adding support for the same kind of rrule string, but without the `RRULE;` prefix. Based on Real World™️ evidence. Description of the…
This completes https://github.com/odoo/odoo/pull/171784 by adding support for the same kind of rrule string, but without the `RRULE;` prefix.
Based on Real World™️ evidence.
Description of the issue/feature this PR addresses:
<details>
```
odoo-1 | 2024-10-24 11:20:18,785 42 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : unsupported property: !
odoo-1 | Traceback (most recent call last):
odoo-1 | File "/opt/odoo/auto/addons/google_calendar/models/[res_users.py](https://res_users.py/)", line 100, in _sync_all_google_calendar
odoo-1 | user.with_user(user).sudo()._sync_google_calendar(google)
odoo-1 | File "/opt/odoo/auto/addons/google_calendar/models/[res_users.py](https://res_users.py/)", line 78, in _sync_google_calendar
odoo-1 | synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
odoo-1 | File "/opt/odoo/auto/addons/google_calendar/models/[google_sync.py](https://google_sync.py/)", line 202, in _sync_google2odoo
odoo-1 | odoo_record.with_context(dont_notify=True)._write_from_google(gevent, vals)
odoo-1 | File "/opt/odoo/auto/addons/google_calendar/models/[calendar_recurrence_rule.py](https://calendar_recurrence_rule.py/)", line 86, in _write_from_google
odoo-1 | current_parsed_rrule = self._rrule_parse(current_rrule, self.dtstart)
odoo-1 | File "/opt/odoo/auto/addons/calendar/models/[calendar_recurrence.py](https://calendar_recurrence.py/)", line 375, in _rrule_parse
odoo-1 | rule = rrule.rrulestr(rule_str, dtstart=date_start)
odoo-1 | File "/usr/local/lib/python3.10/site-packages/dateutil/[rrule.py](https://rrule.py/)", line 1730, in __call__
odoo-1 | return self._parse_rfc(s, **kwargs)
odoo-1 | File "/usr/local/lib/python3.10/site-packages/dateutil/[rrule.py](https://rrule.py/)", line 1698, in _parse_rfc
odoo-1 | raise ValueError("unsupported property: "+name)
odoo-1 | ValueError: unsupported property:
```
</details>
Current behavior before PR: Odoo stops sync of users calendars as long as they have one event with an RRULE like this.
Desired behavior after PR is merged: Odoo keeps working.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
@moduon MT-7215
Forward-Port-Of: odoo/odoo#185089Before this commit : `is_html_empty` considers empty icons as empty html. After this commit: Empty icons are considered as non empty html Note: changed the tag_re to more performant regex task-4060037 Forward-Port-Of: odoo/odoo#182642
Original PR description
Before this commit : `is_html_empty` considers empty icons as empty html. After this commit: Empty icons are considered as non empty html Note: changed the tag_re to more performant regex task-4060037 Forward-Port-Of: odoo/odoo#182642
Steps to reproduce: - New Project > New Task > Timesheet 10h on task - New subtask on task > Timesheet 5h on subtask - Reporting > Tasks Analysis Remaining hours are computed incorrectly, when no allocated hours are set on a task, we have null values in database that prevent the computation of allocated_hours and remaining_hours which also messes up the project totals. The computation of remaining hours is also only supposed to occur when we have a non zero amount of allocated hours,
Original PR description
Steps to reproduce: - New Project > New Task > Timesheet 10h on task - New subtask on task > Timesheet 5h on subtask - Reporting > Tasks Analysis Remaining hours are computed incorrectly, when no…
Steps to reproduce: - New Project > New Task > Timesheet 10h on task - New subtask on task > Timesheet 5h on subtask - Reporting > Tasks Analysis Remaining hours are computed incorrectly, when no allocated hours are set on a task, we have null values in database that prevent the computation of allocated_hours and remaining_hours which also messes up the project totals. The computation of remaining hours is also only supposed to occur when we have a non zero amount of allocated hours, otherwise the remaining hours are always 0. Additionally, the 'Total Hours' column is confusing for customers as it is meant to compute the total hours spent on a task (subtasks included) but is enabled by default when looking at the projects as a whole which does not make sense. For instance, with 'Task' parent of 'Subtask': | Name | Allocated | Hours spent | Remaining | Total Hours | | -------- | --------- | ----------- | ---------- | ----------- | | Project | 0 | 15 | -15 (-> 0) | 20 | | Task | 0 | 10 | -10 (-> 0) | 15 | | Subtask | 0 | 5 | -5 (-> 0) | 5 | The sum of total hours on project is meaningless and confusing so it is preferable not to have it enabled by default (Subtask is counted twice, once in Task and once itself). opw-4236984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184291
Currently it can happen that slightly changing the amount in (document) currency (field `amount_currency`) i.e. on a tax line can lead to an unbalanced move. (See example and "Reproduce" below.) The issue is the syncing (function `_sync_invoice`) between - amount in currency (document currency; field `amount_currency`) and - balance (company currency; field `balance`). There we update the amount in currency in case the balance is changed and the amount in currency is not changed. But
Original PR description
Currently it can happen that slightly changing the amount in (document) currency (field `amount_currency`) i.e. on a tax line can lead to an unbalanced move. (See example and "Reproduce" below.) The…
Currently it can happen that slightly changing the amount in (document)
currency (field `amount_currency`) i.e. on a tax line can lead to an
unbalanced move. (See example and "Reproduce" below.)
The issue is the syncing (function `_sync_invoice`) between
- amount in currency (document currency; field `amount_currency`) and
- balance (company currency; field `balance`).
There we update the amount in currency in case the balance is changed
and the amount in currency is not changed.
But this is problematic in case we want (in the same write) set
a different amount in currency but explicitly set the same balance
(and not just not write anything to the `balance` field).
Since we write the same balance it is not detected as a
change and we update the balance based on the amount in currency.
But this should not happen; the balance should be "protected"
from being updated (since it is the value we explicitly want).
This can i.e. cause the balance of the receivable line to receive the wrong value
I.e. consider the following case; with currency rate = 2 (also see "Reproduce" below)
Journal Items:
- product 1: amount in currency = -1000.00 €, balance = -500.00
- product 2: amount in currency = -200.00 €, balance = -100.00
- tax line 1: amount in currency = -180.03 €, balance = -90.02
- tax line 2: amount in currency = -30.00 €, balance = -15.00
- Receivable: amount in currency = -1410.03 €, balance = 705.02
And we modify tax line 2: amount in currency = -29.99 €.
Then first we set the correct values because we basically compute the
receivable line by summing the other lines:
Journal Items:
- product 1: amount in currency = -1000.00 €, balance = -500.00
- product 2: amount in currency = -200.00 €, balance = -100.00
- tax line 1: amount in currency = -180.03 €, balance = -90.02
- tax line 2: amount in currency = -29.99 €, balance = -15.00
- Receivable: amount in currency = -1410.02 €, balance = 705.02
So we have set the balance to the same as before but changed the
amount in currency. So then we recompute the balance on the receivable
line from the amount in currency due to the syncing (`_sync_invoice`)
Journal Items:
- product 1: amount in currency = -1000.00 €, balance = -500.00
- product 2: amount in currency = -200.00 €, balance = -100.00
- tax line 1: amount in currency = -180.03 €, balance = -90.02
- tax line 2: amount in currency = -29.99 €, balance = -15.00
- Receivable: amount in currency = -1410.02 €, balance = 705.01
But now the move is not balanced (the sum of the balances should be 0)
-500.00 + -100.00 + -90.02 + -15.00 = -705.02 (and not -705.01)
After this commit we "protect" the balance and amount in currency from
being updated by `_sync_invoice` in case the surrounding `write`
sets the balance (`balance`) or amount in currency (`amount_currency`)
respectively.
Reproduce: (c.f. example above)
1. Select company "My Company (San Francisco)"
2. Ensure EUR currency is activated and has value 2 unit per USD
(at the time of the invoice that will be created further below)
3. Copy the 15% tax
4. Create a new invoice in EUR with 2 lines
(1) qty = 1, unit price = 1000, taxes = 15%
(2) qty = 1, unit price = 200, taxes = 15%, 15% (Copy)
5. There should be 2 tax lines in the "Journal Items" tab
(1) amount in currency = -180.00 €, credit = 90.00 USD
(2) amount in currency = -30.00 €, credit = 90.00 USD
6. Modify tax line (1); set amount in currency to -180.03 €
and save.
The credit will be updated to 90.02 USD.
7. Modify tax line (2); set amount in currency to -29.99 €
and try to save
8. An "Invalid Operation" error is raised:
The move (Draft Invoice ) is not balanced.
The total of debits equals $ 705.01 and the total of credits equals $ 705.02.
Forward-Port-Of: odoo/odoo#171705Before this commit, when a payable account was used on a customer invoice, or a receivable account on a vendor bill, an error message was raised saying "Any journal item on a receivable/payable account must have a due date and vice versa.". This was unclear, and caused for example confusion when importing the accounting history. Therefore, we now handle this case with a new error message. opw-4196597 Forward-Port-Of: odoo/odoo#183795 Forward-Port-Of: odoo/odoo#182979
Original PR description
Before this commit, when a payable account was used on a customer invoice, or a receivable account on a vendor bill, an error message was raised saying "Any journal item on a receivable/payable account must have a due date and vice versa.". This was unclear, and caused for example confusion when importing the accounting history. Therefore, we now handle this case with a new error message. opw-4196597 Forward-Port-Of: odoo/odoo#183795 Forward-Port-Of: odoo/odoo#182979
22 changes
New functionality added to Odoo
This change brings back the option to show totals below report sections, after feedback that businesses in the US and Latin America rely on this layout. It helps companies keep financial reports aligned with local expectations and established reporting practices.
Original PR description
This reverts commit fca441f7fe024722a043cd9300dbaae3a2a2c1e0. We got reports that the "Totals Below Sections" setting is actually important in the US and LATAM countries. The usage is there to always display amounts like that on reports, and there is a lot of resistance to softwares not allowing that. We hence reintroduce this feature.
Enhancements to existing features
Report actions that require selecting the main company and all branches now remain available and show a clear message when the selection is incomplete. This helps users understand what to do instead of seeing disabled buttons and assuming the system is broken.
Original PR description
When you have a company with branches in a database, some reports only make sense when you have the main company with all its branches selected. Currently some report actions (buttons) were disabled if you didn't have your main company and its branches selected, without any information on why the buttons were disabled. This resulted in people creating tickets because they thought something was wrong. This change makes the buttons clickable again, but instead displays a message saying that the user should select the main company and its branches in order to save a sensible report. [task-4260501](https://www.odoo.com/odoo/all-tasks/4260501)
This update adjusts how WhatsApp-related screens are connected to the underlying Odoo interface so they remain compatible with recent layout changes. It is a minor maintenance improvement that helps keep the WhatsApp feature working reliably without changing business workflows.
This update improves explanatory notes in the code for mail-related features, making future maintenance easier for developers. It does not change how users interact with the system, but supports ongoing work on email-like chatter flows.
Original PR description
Just fixing / improving some docstrings while passing by. Part of Task-4273479 : [mail] Email-like chatter flow
Features or functions removed from Odoo
Notification emails in several Odoo apps no longer include extra action buttons or links that were considered distracting. This makes email notifications easier to read and more like regular email conversations, while aligning enterprise modules with the newer Odoo email layout.
Original PR description
RATIONALE Improve email management and composition in Odoo, ease understanding and make flow more looking like email discussions. SPECIFICATIONS We consider actions to be mainly noise in notification emails as it bloats email content and hide real content. Since Odoo v18 standard notification layout does not display them anymore but mechanism has been kept for backward compatibility. This commit removes it. Followup of https://github.com/odoo/odoo/pull/185223 Also remove translation tests. Those have been annoying to write, such sadness. Task-4284064 Part of Task-4273479: [mail] Email-like chatter flow
Notification emails no longer include extra action buttons or links that were already hidden in the standard layout. This makes email conversations easier to read and keeps the focus on the actual message content.
Original PR description
RATIONALE Improve email management and composition in Odoo, ease understanding and make flow more looking like email discussions. SPECIFICATIONS We consider actions to be mainly noise in notification emails as it bloats email content and hide real content. Since Odoo v18 standard notification layout does not display them anymore but mechanism has been kept for backward compatibility. This commit removes it. Followup of https://github.com/odoo/odoo/pull/185223 Also remove translation tests. Those have been annoying to write, such sadness. Task-4284064 Part of Task-4273479: [mail] Email-like chatter flow
Code cleanup and technical improvements
This update tidies the internal structure of several files by reordering imports and removing outdated header annotations. It does not change business behavior, but helps keep the codebase easier to maintain and align with current Odoo standards.
Original PR description
- Reordering and cleaning imports; - Removing encoding declaration; - Removing javascript module annotations (optional since commit Odoo/odoo@5f2c505836002ac7851c29c28d612f721d467bc4); Community PR: - https://github.com/odoo/odoo/pull/185347
Miscellaneous changes
**Steps to reproduce:** - Install Accounting - Go to Accounting settings - Disable "Checks" option (A warning pops up infoming that "account_check_printing" module will be uninstalled) - Save **Issue:** A traceback is raised because it tries to access some fields that are defined in "account_check_printing" module. **Cause:** After uninstallation of "account_check_printing" module, the settings page is reloaded. However, this reload is performed with an old version of the env where
Original PR description
**Steps to reproduce:** - Install Accounting - Go to Accounting settings - Disable "Checks" option (A warning pops up infoming that "account_check_printing" module will be uninstalled) - Save…
**Steps to reproduce:** - Install Accounting - Go to Accounting settings - Disable "Checks" option (A warning pops up infoming that "account_check_printing" module will be uninstalled) - Save **Issue:** A traceback is raised because it tries to access some fields that are defined in "account_check_printing" module. **Cause:** After uninstallation of "account_check_printing" module, the settings page is reloaded. However, this reload is performed with an old version of the env where the fields defined in the uninstalled module are still there. It's coming from an override of "execute" method of "res.config.settings" defined in Accounting module. This override is checking if "sign_invoice" field is enable in order to install Sign module. This action is performed after the "execute" on "super()". If the "execute" is uninstalling a module, the "env" is reset as some models or fields may not be present anymore. However, in the override of the "execute" method, the old "env" is still used and non-existent fields are prefetched. **Solution:** Check to install Sign module in the override of "execute" method before executing the one from "super()" to prevent using an expired "env". opw-4251932 Forward-Port-Of: odoo/enterprise#72227
Context: an AccessError is raised while running test `TestAccountMove.test_add_followers_on_post` and having `l10n_pe_edi_pos` installed: ``` odoo.exceptions.AccessError: You are not allowed to access 'Point of Sale Orders' (pos.order) records. This operation is allowed for the following groups: - Inventory/User - Point of Sale/User Contact your administrator to request access if necessary. ``` Reason: commit 3045807f9a318fed810095fc5746c0e7bbdb0063 extended the `_post` method
Original PR description
Context: an AccessError is raised while running test `TestAccountMove.test_add_followers_on_post` and having `l10n_pe_edi_pos` installed: ``` odoo.exceptions.AccessError: You are not allowed to access 'Point of Sale Orders' (pos.order) records. This operation is allowed for the following groups: - Inventory/User - Point of Sale/User Contact your administrator to request access if necessary. ``` Reason: commit 3045807f9a318fed810095fc5746c0e7bbdb0063 extended the `_post` method on `account.move`, and is reading the field `pos_order_ids`. But one may post an invoice without having sufficient security groups to access `pos.order` records (Inventory/User, Point of Sale/User). runbot-102743 Forward-Port-Of: odoo/enterprise#72547 Forward-Port-Of: odoo/enterprise#72467
To reproduce the issue: 1) Set a prefix group threshold of 2000 on the Generic Balance Sheet 2) Modify the groupby of the Receivable line of that report so that it does account_id,id 3) Duplicate the report ; modify the duplicate to: - Make it a variant of the Generic BS - Set its prefix group threshold to 3 4) Ensure at least 3 move lines exist in the same period for the Receivable account 5) Open the Balance Sheet. By default, the Generic one will be shown 6) Switch to the duplica
Original PR description
To reproduce the issue: 1) Set a prefix group threshold of 2000 on the Generic Balance Sheet 2) Modify the groupby of the Receivable line of that report so that it does account_id,id 3) Duplicate the…
To reproduce the issue:
1) Set a prefix group threshold of 2000 on the Generic Balance Sheet 2) Modify the groupby of the Receivable line of that report so that it does account_id,id 3) Duplicate the report ; modify the duplicate to:
- Make it a variant of the Generic BS
- Set its prefix group threshold to 3 4) Ensure at least 3 move lines exist in the same period for the Receivable account 5) Open the Balance Sheet. By default, the Generic one will be shown 6) Switch to the duplicate you made in 3).
7) Unfold both levels of the Receivable line.
====> Prefix groups aren't used, while the number of move lines reaches the threshold value.
This happens because the variant is opened from the Generic BS. So, options have first been generated and kept in the session for the Generic BS. When openin the variant, it receives the previously generated options as previous_options, and restores the threshold originally defined on the Generic BS.
We don't want to restore the threshold for previous options, so we just remove that code and now always initialize it to the value contained in the apporpriate field when computing the options.
Forward-Port-Of: odoo/enterprise#72938
Forward-Port-Of: odoo/enterprise#72822Purpose ======= If there is already a user for a given employee (including a trigram for instance), we should avoid erasing it to the value the employee encodes on the salary configurator. Forward-Port-Of: odoo/enterprise#72799
Original PR description
Purpose ======= If there is already a user for a given employee (including a trigram for instance), we should avoid erasing it to the value the employee encodes on the salary configurator. Forward-Port-Of: odoo/enterprise#72799
In this commit we try to clean some ambiguity to improve the code readability. Forward-Port-Of: odoo/enterprise#70628
Original PR description
In this commit we try to clean some ambiguity to improve the code readability. Forward-Port-Of: odoo/enterprise#70628
**Steps to reproduce:** - Install account_loans - Go to Settings - Disable "Import & Export" option - Save **Issue:** The db is not accessible anymore because of the following error: ``` The following modules are needed by other modules but have not been defined, they may not be present in the correct asset bundle: - @base_import/import_action/import_action - @base_import/import_model The following modules could not be loaded because they have unmet dependencies, this is a secon
Original PR description
**Steps to reproduce:** - Install account_loans - Go to Settings - Disable "Import & Export" option - Save **Issue:** The db is not accessible anymore because of the following error: ``` The following modules are needed by other modules but have not been defined, they may not be present in the correct asset bundle: - @base_import/import_action/import_action - @base_import/import_model The following modules could not be loaded because they have unmet dependencies, this is a secondary error which is likely caused by one of the above problems: - @account_loans/components/loans/import_action ``` **Cause:** When "Import & Export" option is disabled, "base_import" module and many others are unsintalled because they depend on "base_import" module. "account_loans" is not uninstalled but it should be because it depends on "base_import" module as it extends its "ImportAction" component. opw-4283944 Forward-Port-Of: odoo/enterprise#72874
Issue: Mail scanners can send HTTP HEAD requests to links contained in emails, which can change the state of a sign request without user action. Steps: - send a sign request - look in mailhog to get the notification mail - copy the link at the bottom of the mail and `curl --head <url>` - the sign request is now ignored opw-4217355 Forward-Port-Of: odoo/enterprise#72852 Forward-Port-Of: odoo/enterprise#72182
Original PR description
Issue: Mail scanners can send HTTP HEAD requests to links contained in emails, which can change the state of a sign request without user action. Steps: - send a sign request - look in mailhog to get the notification mail - copy the link at the bottom of the mail and `curl --head <url>` - the sign request is now ignored opw-4217355 Forward-Port-Of: odoo/enterprise#72852 Forward-Port-Of: odoo/enterprise#72182
Before this commit when dragging a sign item, the initial copy wasn't invisible completely. For example placeholder, dragging arrow were still visible. This commit aims to fix the issue by setting visibility of sign_item_body to be same as parent. Task: 4195899 Forward-Port-Of: odoo/enterprise#72782 Forward-Port-Of: odoo/enterprise#70276
Original PR description
Before this commit when dragging a sign item, the initial copy wasn't invisible completely. For example placeholder, dragging arrow were still visible. This commit aims to fix the issue by setting visibility of sign_item_body to be same as parent. Task: 4195899 Forward-Port-Of: odoo/enterprise#72782 Forward-Port-Of: odoo/enterprise#70276
Before this commit: - Creating a GST return period with a quarterly periodicity without selecting a quarter will raise a traceback. - Creating a GST return period with a monthly periodicity without selecting a month will raise a traceback. Reason: - While calculating the start_date and end_date of the quarterly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.month), year=int(record.year))` If there is no month, then int(record.month) will
Original PR description
Before this commit: - Creating a GST return period with a quarterly periodicity without selecting a quarter will raise a traceback. - Creating a GST return period with a monthly periodicity without…
Before this commit: - Creating a GST return period with a quarterly periodicity without selecting a quarter will raise a traceback. - Creating a GST return period with a monthly periodicity without selecting a month will raise a traceback. Reason: - While calculating the start_date and end_date of the quarterly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.month), year=int(record.year))` If there is no month, then int(record.month) will return 0 and The month should be between 1 and 12, so it will raise an error. - While calculating the start_date and end_date of the monthly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.quarter), year=int(record.year))` If there is no quarter, then int(record.quarter) will return 0 and The month should be between 1 and 12, so it will raise an error. After this commit: - The start_date and end_date will not be calculated if a month or quarter is not defined for the monthly or quarterly return periods. Traceback - https://pastebin.com/LyKUDrH5 Task-4243468 Forward-Port-Of: odoo/enterprise#72815 Forward-Port-Of: odoo/enterprise#71883
Forward-Port-Of: odoo/enterprise#72090
Original PR description
Forward-Port-Of: odoo/enterprise#72090
When the date in the modify wizard for assets is changed, the residual_value should be updated to give a better view to the user. As this value is changed, the tests had to be changed accordingly. The gain or loss account is now correctly adapted from the computed value (itself computed on the date) and the Asset Counterpart Account is hidden if there is no gain. task-3981380 Forward-Port-Of: odoo/enterprise#72504 Forward-Port-Of: odoo/enterprise#70277
Original PR description
When the date in the modify wizard for assets is changed, the residual_value should be updated to give a better view to the user. As this value is changed, the tests had to be changed accordingly. The gain or loss account is now correctly adapted from the computed value (itself computed on the date) and the Asset Counterpart Account is hidden if there is no gain. task-3981380 Forward-Port-Of: odoo/enterprise#72504 Forward-Port-Of: odoo/enterprise#70277
We want to keep the two columns layout when there is no transaction yet. Task-id: 4150010 Forward-Port-Of: odoo/enterprise#72418
Original PR description
We want to keep the two columns layout when there is no transaction yet. Task-id: 4150010 Forward-Port-Of: odoo/enterprise#72418
## [FIX] project_enterprise: avoid creating employee in test Before this commit, `:TestSmartSchedule.test_multi_users_tasks` test in `project_enterprise` module creates 2 employees but the problem is `hr` module is not in the dependencies of `project_enterprise` and so that test fails when `hr` is not installed. This commit adapts the test to make sure to not create any employees inside that test. ## [FIX] project_enterprise_hr: adds test_smart_schedule test Before this commit, t
Original PR description
## [FIX] project_enterprise: avoid creating employee in test Before this commit, `:TestSmartSchedule.test_multi_users_tasks` test in `project_enterprise` module creates 2 employees but the problem is `hr` module is not in the dependencies of `project_enterprise` and so that test fails when `hr` is not installed. This commit adapts the test to make sure to not create any employees inside that test. ## [FIX] project_enterprise_hr: adds test_smart_schedule test Before this commit, the `test_multi_users_tasks` test defined in `/project_enterprise:TestSmartSchedule` failed when `hr` module is not installed since that test create 2 employees. This commit moves the test in `project_enterprise_hr` to make sure the test works as expected and we can create employee since `hr` is in the dependencies of `project_enterprise_hr` module. runbot-76567 Forward-Port-Of: odoo/enterprise#72414
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the xml on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx/) **Issue:** The validation fails because "Sello" attribute is invalid. **Cause:** A wrong XSLT is used to generate the digital stamp for COA SAT (XML). opw-4209089 Forward
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the xml on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx/) **Issue:** The validation fails because "Sello" attribute is invalid. **Cause:** A wrong XSLT is used to generate the digital stamp for COA SAT (XML). opw-4209089 Forward-Port-Of: odoo/enterprise#72882
Before this commit currently when creating a new app using Studio the previous button icon in the navbar appears in the wrong direction After this commit The previous button icon should appear in the right direction Task - 3845561 Forward-Port-Of: odoo/enterprise#72674 Forward-Port-Of: odoo/enterprise#61835
Original PR description
Before this commit currently when creating a new app using Studio the previous button icon in the navbar appears in the wrong direction After this commit The previous button icon should appear in the right direction Task - 3845561 Forward-Port-Of: odoo/enterprise#72674 Forward-Port-Of: odoo/enterprise#61835
17 changes
Enhancements to existing features
The UrbanPiper point-of-sale integration now creates its discount product only when it is needed and only if it does not already exist. This reduces setup duplication and helps keep discount handling consistent without changing the day-to-day user workflow.
Original PR description
In this commit: === - Removed the XML data file for creating the discount product. - Added logic to create the discount product in Python, directly where the existing discount product is searched. - Implemented a check to first search for the discount product, and only create it if it does not already exist.
Belgian tax users can now create a payment directly while using the pay taxes wizard. This streamlines the process of paying taxes to the government and reduces the need for separate manual payment steps.
Original PR description
This commit will add the possibility to create a payment from the wizard to pay the taxes to the government. task: 4154861
Resolved issues and error corrections
Fixes several issues in the salary contract flow: applicant names now display correctly when signing, dependent benefit options only appear when relevant, and dropdown menus look editable. This reduces confusion for applicants and HR teams using the salary configurator.
Original PR description
1. When an applicant (who doesn't have an employee record yet) signs a contract their name is shown as `simulation employee` instead of their actual name. 2. Dependent benefits are visible although the mandatory benefits aren't selected. For example: the dialog box showing the number of insured children under ambulatory insurance is visible although the abulatory insurance isn't selected on the salary configurator. 3. The dropdown menus on the salary configurator have a grey color which makes the user think that they aren't editable. These changes fix the above issues. task-4280657
This fix prevents subscription order lines from being recalculated more broadly than needed. It helps reduce unnecessary processing, improving reliability and performance for subscription-related sales operations.
The Loan Accounting app now correctly depends on the Import & Export feature it uses. This prevents the database from becoming inaccessible when Import & Export is disabled while the loan app remains installed.
Original PR description
**Steps to reproduce:** - Install account_loans - Go to Settings - Disable "Import & Export" option - Save **Issue:** The db is not accessible anymore because of the following error: ``` The following modules are needed by other modules but have not been defined, they may not be present in the correct asset bundle: - @base_import/import_action/import_action - @base_import/import_model The following modules could not be loaded because they have unmet dependencies, this is a secondary error which is likely caused by one of the above problems: - @account_loans/components/loans/import_action ``` **Cause:** When "Import & Export" option is disabled, "base_import" module and many others are unsintalled because they depend on "base_import" module. "account_loans" is not uninstalled but it should be because it depends on "base_import" module as it extends its "ImportAction" component. opw-4283944
Miscellaneous changes
It was previously already done in commit 148810637bf9e7a9cc53338f665ec612221a1ba2 . But in the meantime new modules were added or the 'countries' info were added back to the manifest. Currently the auto_install does not work correctly. E.g. installing `account_reports` and then `l10n_lv` does not automatically install `l10n_lv_reports` (which it should). After this commit the auto_install works again. Forward-Port-Of: odoo/enterprise#72920 Forward-Port-Of: odoo/enterprise#72299
Original PR description
It was previously already done in commit 148810637bf9e7a9cc53338f665ec612221a1ba2 . But in the meantime new modules were added or the 'countries' info were added back to the manifest. Currently the auto_install does not work correctly. E.g. installing `account_reports` and then `l10n_lv` does not automatically install `l10n_lv_reports` (which it should). After this commit the auto_install works again. Forward-Port-Of: odoo/enterprise#72920 Forward-Port-Of: odoo/enterprise#72299
Purpose ======= If there is already a user for a given employee (including a trigram for instance), we should avoid erasing it to the value the employee encodes on the salary configurator. Forward-Port-Of: odoo/enterprise#72799
Original PR description
Purpose ======= If there is already a user for a given employee (including a trigram for instance), we should avoid erasing it to the value the employee encodes on the salary configurator. Forward-Port-Of: odoo/enterprise#72799
To reproduce the issue: 1) Set a prefix group threshold of 2000 on the Generic Balance Sheet 2) Modify the groupby of the Receivable line of that report so that it does account_id,id 3) Duplicate the report ; modify the duplicate to: - Make it a variant of the Generic BS - Set its prefix group threshold to 3 4) Ensure at least 3 move lines exist in the same period for the Receivable account 5) Open the Balance Sheet. By default, the Generic one will be shown 6) Switch to the duplica
Original PR description
To reproduce the issue: 1) Set a prefix group threshold of 2000 on the Generic Balance Sheet 2) Modify the groupby of the Receivable line of that report so that it does account_id,id 3) Duplicate the…
To reproduce the issue:
1) Set a prefix group threshold of 2000 on the Generic Balance Sheet 2) Modify the groupby of the Receivable line of that report so that it does account_id,id 3) Duplicate the report ; modify the duplicate to:
- Make it a variant of the Generic BS
- Set its prefix group threshold to 3 4) Ensure at least 3 move lines exist in the same period for the Receivable account 5) Open the Balance Sheet. By default, the Generic one will be shown 6) Switch to the duplicate you made in 3).
7) Unfold both levels of the Receivable line.
====> Prefix groups aren't used, while the number of move lines reaches the threshold value.
This happens because the variant is opened from the Generic BS. So, options have first been generated and kept in the session for the Generic BS. When openin the variant, it receives the previously generated options as previous_options, and restores the threshold originally defined on the Generic BS.
We don't want to restore the threshold for previous options, so we just remove that code and now always initialize it to the value contained in the apporpriate field when computing the options.
Forward-Port-Of: odoo/enterprise#72822Context: an AccessError is raised while running test `TestAccountMove.test_add_followers_on_post` and having `l10n_pe_edi_pos` installed: ``` odoo.exceptions.AccessError: You are not allowed to access 'Point of Sale Orders' (pos.order) records. This operation is allowed for the following groups: - Inventory/User - Point of Sale/User Contact your administrator to request access if necessary. ``` Reason: commit 3045807f9a318fed810095fc5746c0e7bbdb0063 extended the `_post` method
Original PR description
Context: an AccessError is raised while running test `TestAccountMove.test_add_followers_on_post` and having `l10n_pe_edi_pos` installed: ``` odoo.exceptions.AccessError: You are not allowed to access 'Point of Sale Orders' (pos.order) records. This operation is allowed for the following groups: - Inventory/User - Point of Sale/User Contact your administrator to request access if necessary. ``` Reason: commit 3045807f9a318fed810095fc5746c0e7bbdb0063 extended the `_post` method on `account.move`, and is reading the field `pos_order_ids`. But one may post an invoice without having sufficient security groups to access `pos.order` records (Inventory/User, Point of Sale/User). runbot-102743 Forward-Port-Of: odoo/enterprise#72467
File "/data/build/enterprise/sale_subscription/tests/test_performance.py", line 21, in test_recurring_order_creation_perf with self.assertQueryCount(__system__=2309): File "/usr/lib/python3.12/contextlib.py", line 144, in __exit__ next(self.gen) File "/data/build/odoo/odoo/tests/common.py", line 549, in assertQueryCount self.fail(msg % (login, count, expected, funcname, filename, linenum)) AssertionError: Query count more than expected for user __system__: 2310 > 2309 in te
Original PR description
File "/data/build/enterprise/sale_subscription/tests/test_performance.py", line 21, in test_recurring_order_creation_perf
with self.assertQueryCount(__system__=2309):
File "/usr/lib/python3.12/contextlib.py", line 144, in __exit__
next(self.gen)
File "/data/build/odoo/odoo/tests/common.py", line 549, in assertQueryCount
self.fail(msg % (login, count, expected, funcname, filename, linenum))
AssertionError: Query count more than expected for user __system__: 2310 > 2309 in test_recurring_order_creation_perf at /data/build/enterprise/sale_subscription/tests/test_performance.py:21
One more query has been added recently when all modules are installed.
runbot error: https://runbot.odoo.com/web#id=102953&view_type=form&model=runbot.build.error&menu_id=405&cids=1
Forward-Port-Of: odoo/enterprise#72349Before this commit when dragging a sign item, the initial copy wasn't invisible completely. For example placeholder, dragging arrow were still visible. This commit aims to fix the issue by setting visibility of sign_item_body to be same as parent. Task: 4195899 Forward-Port-Of: odoo/enterprise#70276
Original PR description
Before this commit when dragging a sign item, the initial copy wasn't invisible completely. For example placeholder, dragging arrow were still visible. This commit aims to fix the issue by setting visibility of sign_item_body to be same as parent. Task: 4195899 Forward-Port-Of: odoo/enterprise#70276
Before this commit: - Creating a GST return period with a quarterly periodicity without selecting a quarter will raise a traceback. - Creating a GST return period with a monthly periodicity without selecting a month will raise a traceback. Reason: - While calculating the start_date and end_date of the quarterly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.month), year=int(record.year))` If there is no month, then int(record.month) will
Original PR description
Before this commit: - Creating a GST return period with a quarterly periodicity without selecting a quarter will raise a traceback. - Creating a GST return period with a monthly periodicity without…
Before this commit: - Creating a GST return period with a quarterly periodicity without selecting a quarter will raise a traceback. - Creating a GST return period with a monthly periodicity without selecting a month will raise a traceback. Reason: - While calculating the start_date and end_date of the quarterly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.month), year=int(record.year))` If there is no month, then int(record.month) will return 0 and The month should be between 1 and 12, so it will raise an error. - While calculating the start_date and end_date of the monthly return period: `period_start = fields.Date.context_today(self).replace(day=1, month=int(record.quarter), year=int(record.year))` If there is no quarter, then int(record.quarter) will return 0 and The month should be between 1 and 12, so it will raise an error. After this commit: - The start_date and end_date will not be calculated if a month or quarter is not defined for the monthly or quarterly return periods. Traceback - https://pastebin.com/LyKUDrH5 Task-4243468 Forward-Port-Of: odoo/enterprise#72815 Forward-Port-Of: odoo/enterprise#71883
When the date in the modify wizard for assets is changed, the residual_value should be updated to give a better view to the user. As this value is changed, the tests had to be changed accordingly. The gain or loss account is now correctly adapted from the computed value (itself computed on the date) and the Asset Counterpart Account is hidden if there is no gain. task-3981380 Forward-Port-Of: odoo/enterprise#72504 Forward-Port-Of: odoo/enterprise#70277
Original PR description
When the date in the modify wizard for assets is changed, the residual_value should be updated to give a better view to the user. As this value is changed, the tests had to be changed accordingly. The gain or loss account is now correctly adapted from the computed value (itself computed on the date) and the Asset Counterpart Account is hidden if there is no gain. task-3981380 Forward-Port-Of: odoo/enterprise#72504 Forward-Port-Of: odoo/enterprise#70277
Issue: Mail scanners can send HTTP HEAD requests to links contained in emails, which can change the state of a sign request without user action. Steps: - send a sign request - look in mailhog to get the notification mail - copy the link at the bottom of the mail and `curl --head <url>` - the sign request is now ignored opw-4217355 Forward-Port-Of: odoo/enterprise#72423 Forward-Port-Of: odoo/enterprise#72182
Original PR description
Issue: Mail scanners can send HTTP HEAD requests to links contained in emails, which can change the state of a sign request without user action. Steps: - send a sign request - look in mailhog to get the notification mail - copy the link at the bottom of the mail and `curl --head <url>` - the sign request is now ignored opw-4217355 Forward-Port-Of: odoo/enterprise#72423 Forward-Port-Of: odoo/enterprise#72182
Steps ----- 1. Create a deduplication rule for a model with a non-stored company field (e.g. Document). Add a field to the deduplication rules. 2. Run the "Data Merge: Find Duplicate Records" scheduled action. ** ValueError: <class 'psycopg2.errors.UndefinedColumn'>: "column documents_document.company_id does not exist ** Change ----- Handle the case where the company field of the model is not stored but still accessible through its related field in another table. opw-4114062 Forward
Original PR description
Steps ----- 1. Create a deduplication rule for a model with a non-stored company field (e.g. Document). Add a field to the deduplication rules. 2. Run the "Data Merge: Find Duplicate Records" scheduled action. ** ValueError: <class 'psycopg2.errors.UndefinedColumn'>: "column documents_document.company_id does not exist ** Change ----- Handle the case where the company field of the model is not stored but still accessible through its related field in another table. opw-4114062 Forward-Port-Of: odoo/enterprise#72368 Forward-Port-Of: odoo/enterprise#68816
We want to keep the two columns layout when there is no transaction yet. Task-id: 4150010 Forward-Port-Of: odoo/enterprise#72418
Original PR description
We want to keep the two columns layout when there is no transaction yet. Task-id: 4150010 Forward-Port-Of: odoo/enterprise#72418
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the xml on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx/) **Issue:** The validation fails because "Sello" attribute is invalid. **Cause:** A wrong XSLT is used to generate the digital stamp for COA SAT (XML). opw-4209089 Forward
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the xml on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx/) **Issue:** The validation fails because "Sello" attribute is invalid. **Cause:** A wrong XSLT is used to generate the digital stamp for COA SAT (XML). opw-4209089 Forward-Port-Of: odoo/enterprise#72882
4 changes
Resolved issues and error corrections
This update resolves an issue where external tax calculators were incorrectly processing taxes on down payment invoices. To ensure accurate calculations, down payment invoices no longer send tax information to external calculators, reverting to a standard invoice calculation. This simplifies the process and avoids discrepancies due to tax rounding and exemptions.
Original PR description
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by…
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by tax calculators are only informational. When they return e.g. 5% tax, the actual amount can be different from 5% because of differences in rounding or (partial) exemptions. The authoritative tax is returned as a value amount (e.g. $10). Because of this, we cannot rely on Odoo to calculate the tax from account.tax records. It's not always going to match. It's not possible to fix this by externally calculating taxes on the down payment invoice. The single down payment line cannot accomodate all different tax categories. Creating a down payment line per tax category (e.g. avatax_category_id) was considered, but a specific down payment product would need to be created per used tax category which would clutter the database. On top of that, down payment products are removed in later versions [1] which would complicate this approach even further. This solves the issue by not calculating taxes on down payments at all. The down payment invoice will not be sent to external tax calculators. The resulting down payment lines on the SO won't have taxes set, and those lines will be excluded from the request to the external tax calculator. The final, "regular invoice" transaction will happen as if no down payments were made. The down payment lines won't be sent, so this will look like a regular invoice from the external calculator's view. By default, the downpayment lines equal the subtotal of the selected down payment amount. We remove tax_ids from the lines because we cannot count on calculating tax locally (see above). To keep the behavior analogous we override the downpayment wizard to create a single down payment line with a total equal to the entered total in the wizard. [1] odoo/odoo@9aa52dd6418e5881adc2d96d15d062b55d6150c5 opw-3971513
This update corrects a recent translation of payroll rule codes that was causing errors in salary calculations. The change reverts the translation, ensuring accurate payroll processing for French company structures like 'cadre'. This resolves confusion and improves the reliability of the payroll system.
Original PR description
Steps to reproduce: - Switch to 'FR company' > New employee > New contract (Use defaults) - Payroll app > Payslips > All Payslips - New Payslip for your employee using a french structure (like 'cadre') - Compute sheet > Salary computation tab - (Maybe set 'Salary Journal' in Configuration > Structures if needed) Salary rule codes were translated leading to confusion in the fields to fetch when computing payroll sheets. opw-4240326
This update enhances the report editor's ability to display placeholder content for 't-out' fields. Previously, developers could manually adjust expressions to avoid placeholders, but now a new 'data-oe-demo' attribute provides a clearer signal for placeholder content within the studio environment, ensuring consistent and correct display.
Original PR description
Some reports have been edited to have qweb default content that was meant to only be used from within studio. ```xml <t t-field="some_field">studio placeholder</t> ``` This content is displayed if the evaluated value is either False or None. This can also happen outside studio, if the field is not required. An attribute `data-oe-demo` was introduced for t-fields. ```xml <t t-field="some_field" data-oe-demo="studio placeholder"/> ``` This attribute was introduced for t-field nodes in order to only display placeholder content inside the report editor. We didn't introduce it for `t-out` as it was possible to change the expression `<t t-out="obj.prop"/>` -> `<t t-out="obj.prop or ''"/>` While this definitely works, the attribute better signals the intent of the change. We thus add support for the attribute on t-out.
This update resolves an issue preventing the correct generation of the 'COA SAT (XML)' report for Mexican companies. The previous XSLT was incorrect, causing validation failures. This fix ensures the report meets SAT requirements and allows for proper filing.
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the xml on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx/) **Issue:** The validation fails because "Sello" attribute is invalid. **Cause:** A wrong XSLT is used to generate the digital stamp for COA SAT (XML). opw-4209089 Forward-Port-Of: odoo/enterprise#72882