Thursday, October 5, 2023
17 changes · master
Enhancements to existing features
A new option is available in form view debug mode to show all raw field data for the current record in JSON format. This helps support and technical teams inspect record details more quickly when troubleshooting or validating data.
Original PR description
This commit introduces a new debug menu item in form view that allows to read all the raw fields data of the current record in JSON format. task-3509462
The map view list now hides records that do not have location data instead of showing them as dimmed entries. This makes map-based lists cleaner and helps users focus only on records that can actually be displayed on the map.
Original PR description
This commit changes The map view so that it will only show located records in the list and hide non located ones instead of displaying them with text muted class. task-3379997
Resolved issues and error corrections
This fixes Odoo's automated clickbot testing so it correctly applies all filters in views after changes introduced by the new Milk theme. It helps ensure automated interface checks cover filtered views properly, reducing the risk of missed issues.
Original PR description
Since the new milk theme, the clickbot for click everywhere, didn't set the filters on the views. Now, the clickbot set all the filters on the views. task-id 3535596
Code cleanup and technical improvements
This update removes outdated delivery-related code from the online shop checkout flow. It does not change how customers select delivery options, but helps keep the checkout code simpler and easier to maintain.
Original PR description
Remove unused: - `keep_carrier` from the kwargs of `_check_carrier_quotation` - `carrier_id` from the kwargs of the '/shop/payment' route
Miscellaneous changes
This issue occurs when a customer imports or uploads a file, and that file contains an image that is attached to the URL as text or HTML. then, The error would be generated. Stack Trace:- 'UnidentifiedImageError: cannot identify image file <_io.BytesIO object at 0x7f0fc9e08db0> File "addons/base_import/models/base_import.py", line 1258, in _import_image_by_url image = Image.open(io.BytesIO(content)) File "PIL/Image.py", line 3008, in open raise UnidentifiedImageError('
Original PR description
This issue occurs when a customer imports or uploads a file, and that file
contains an image that is attached to the URL as text or HTML. then,
The error would be generated.
Stack Trace:-
'UnidentifiedImageError: cannot identify image file <_io.BytesIO object at 0x7f0fc9e08db0>
File "addons/base_import/models/base_import.py", line 1258, in _import_image_by_url
image = Image.open(io.BytesIO(content))
File "PIL/Image.py", line 3008, in open
raise UnidentifiedImageError('
Step to Produce:-
- import CSV file (Ex.'product.product' model)
> that CSV file must have one URL Image(In that URL has content of text or
Html form)
- Click On the 'Test' Button.
Applying these changes will resolve this issue.
sentry-4046190590
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#136762
Forward-Port-Of: odoo/odoo#119499This fixes the automatic setup so the Avalara tax integration is installed for Canadian accounting, not Brazilian accounting. It helps ensure companies get the correct tax localization support for their country and avoids enabling the wrong tax integration.
Original PR description
Small issue in 70329177713. `account_avatax` supports the US and Canada. `l10n_br_avatax` supports Brazil. Introduced in https://github.com/odoo/odoo/pull/136490.
This fixes an issue where notification author names could appear in Firefox when they should be hidden. The change improves consistency across browsers and helps keep notification displays clean and as intended.
Original PR description
The author name of every notification is displayed when the `o_hide_author` class is not set. In order to do so, the css rule uses the `:has` pseudo-class. This is an issue since firefox does not support it. This PR removes the usage of this pseudo-class.
Calendar status filters now rely on the existing color styling instead of generating invalid color values. This keeps labels such as sales orders and quotations visually consistent and avoids confusing display issues in the calendar view.
Original PR description
Problem : From the sales order, if we go to the calendar view, it shows status like "sales order", "quotation",... when we check the style in the console, span style has nonsensical values for background-color and border-color. Ex : style="background-color:state; border-color:state;" Correction : The styles are already applied by t-att-class="getFilterColor(filter)" used on the div.o_calendar_filter_item. Then the utilisation of t-att-style is no more useful. taskId : 3512867
An unstable performance test in Australian payroll accounting was removed because it was blocking unrelated changes during automated validation. This reduces false alarms in the release process without changing payroll features or user workflows.
Original PR description
This test broke the l10n_staging in mergebot: https://runbot.odoo.com/runbot/build/51896700 The best thing is to remove it as it might give false positives on future l10n just before the freeze. It failed for PR https://github.com/odoo/odoo/pull/136164 which has nothing to do with payroll. Just adding a boolean on an account_move in l10n_es...
This update standardizes how Odoo's frontend code references a shared interface library, replacing direct global access with explicit imports. It reduces maintenance risk and helps developers catch mistakes earlier, with no expected change for end users.
Original PR description
Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859This internal cleanup updates many Odoo Enterprise modules to use the approved way of referencing Owl web framework features. It helps keep the codebase consistent and easier to maintain, with no expected functional change for users.
Original PR description
Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859As a visitor (non logged-in user), go to the forum and attempt to up vote a message. You get a notification asking you to login first but that notifications is literally: > Oh no! Please \<a href="/web/login">sign in\</a> to vote Instead of > Oh no! Please [sign in](/web/login) to vote With a link on "sign in". Using the Markup strings (i.e. Markup`` as opposed to the function Markup()), all parameters injected via placeholders (${}) are html-escaped unless the parameter is Markup
Original PR description
As a visitor (non logged-in user), go to the forum and attempt to up vote a message. You get a notification asking you to login first but that notifications is literally: > Oh no! Please \<a…
As a visitor (non logged-in user), go to the forum and attempt to up vote a message. You get a notification asking you to login first but that notifications is literally:
> Oh no! Please \<a href="/web/login">sign in\</a> to vote
Instead of
> Oh no! Please [sign in](/web/login) to vote
With a link on "sign in".
Using the Markup strings (i.e. Markup`` as opposed to the function Markup()), all parameters injected via placeholders (${}) are html-escaped unless the parameter is Markup too.
We could had applied to following diff:
```diff
-Markup`<p>${sprintf(_t('Oh no! Please <a href="%s">sign in</a> to vote'), "/web/login")}</p>`
+Markup`<p>${Markup(sprintf(_t('Oh no! Please <a href="%s">sign in</a> to vote'), "/web/login"))}</p>`
```
But this would had miss the opportunity to simplify the expression, injecting "/web/login" via sprintf has no real benefit.
task-3520200
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#136502**[IMP] project_sale_expense: change bad tests flows** Previous test flow: - Re-invoice a multi-currency expense with a product having a cost with a unit_amount override Expected test flow: - Re-invoice a multi-currency expense with a product having no cost and a total_amount override In the past it was feasible (but wrong) in the back-end to set a product with price in a multi-currency expense. Setting an expense amount through the unit_amount is also not reflecti
Original PR description
**[IMP] project_sale_expense: change bad tests flows** Previous test flow: - Re-invoice a multi-currency expense with a product having a cost with a unit_amount override Expected test flow: -…
**[IMP] project_sale_expense: change bad tests flows**
Previous test flow:
- Re-invoice a multi-currency expense
with a product having a cost with
a unit_amount override
Expected test flow:
- Re-invoice a multi-currency expense with a product
having no cost and a total_amount override
In the past it was feasible (but wrong) in the
back-end to set a product with price in a
multi-currency expense.
Setting an expense amount through the unit_amount is
also not reflecting the actual flow
**[FIX] hr_expense: Fix currency_rate handling**
The desired flow of currency rate in expense is as followed:
- (default) Use Odoo currency rate
- Allow the user to set a custom rate (to include fees)
when changing the total amount in company currency
- Revert to the default behaviour when the currency is changed
or the amount in foreign currency is changed
This aims to fix how currency rate is computed and overridden
- Reorganize all currency rate computation, so
it doesn't revert to Odoo rate at every compute call
- Deals with a bug where a total_amount_currency changed just
before calling "action_submit_expenses" would not trigger the
computation of unit_amount
- Force save when changing currency on expense form view
to prevent a bug where the first modification of
total_amount_company would be canceled (due to the new
behaviour of currency rate computation)
- Removes unit_amount_display from views as it should be
removed in master anyway and is deprecated since 16.0
task-3476569
Forward-Port-Of: odoo/odoo#134356Before this task, lots of mails were sent after updating or deleting recurrent event in 'All events' or 'This and future events' update type. This was happening because updating these recurrent events was triggering patch calls event by event, when they should be handled in batch. Since Outlook Calendar recurrences are not updated anymore (from Odoo to Outlook), we were able to update directly the 'calendar' module. After this commit, updating or deleting recurrent events should trigger at mo
Original PR description
Before this task, lots of mails were sent after updating or deleting recurrent event in 'All events' or 'This and future events' update type. This was happening because updating these recurrent events was triggering patch calls event by event, when they should be handled in batch. Since Outlook Calendar recurrences are not updated anymore (from Odoo to Outlook), we were able to update directly the 'calendar' module. After this commit, updating or deleting recurrent events should trigger at most two mails for Google users. Deleting multiple recurrent events is now more efficient and straightforward. Task-id: 3163695 Forward-Port-Of: odoo/odoo#113238
Steps to reproduce the bug: - Activate 2 currencies (assume EUR and USD, conversion rate: 0.65 EUR = 1 USD) - Create new product “P1”: - Purchase tab: - add two vendors: - Vendor_USD, currency = USD, price = 100 - Vendor_EUR, currency = EUR, price = 80 - Create PO: - vendor = vendor_EUR, - Currency = Eur - Add P1, Unit price should be 80 - Alternative tab > Create alternative > Vendor = Vendor_EUR - Compare product lines Issue: The line with price = 100 US
Original PR description
Steps to reproduce the bug:
- Activate 2 currencies (assume EUR and USD, conversion rate: 0.65 EUR = 1 USD)
- Create new product “P1”:
- Purchase tab:
- add two vendors:
- Vendor_USD, currency = USD, price = 100
- Vendor_EUR, currency = EUR, price = 80
- Create PO:
- vendor = vendor_EUR,
- Currency = Eur
- Add P1, Unit price should be 80
- Alternative tab > Create alternative > Vendor = Vendor_EUR
- Compare product lines Issue: The line with price = 100 USD is highlighted as being the cheapest option, but if we apply conversion rules, 80 EUR = 123,07 USD > 100 USD.
Solution:
Convert prices in company currency before comparing.
opw-3378253
Forward-Port-Of: odoo/odoo#135037before this commit, if the user doesn't have access to sales application and if tries to open the product form view, access error is shown on rental.pricing model scenario: * create or edit a product and set rental pricing * now login with a user having no access in sales * open product form * access error  after this commit, no access error wont be shown
Original PR description
before this commit, if the user doesn't have access to sales application and if tries to open the product form view, access error is shown on rental.pricing model scenario: * create or edit a product and set rental pricing * now login with a user having no access in sales * open product form * access error  after this commit, no access error wont be shown to users on opening the product form. Forward-Port-Of: odoo/enterprise#48322 Forward-Port-Of: odoo/enterprise#47492
Steps to reproduce: - Open "Project" app - Click on Studio - Click on edit menu button - Select a menu and drag and drop it to the root menu app (e.g Project) => a traceback occurs This error occurs because we don't have a root menu for the app menu to avoid this error, if no menu are found, we use the root menu app as root Forward-Port-Of: odoo/enterprise#47697
Original PR description
Steps to reproduce: - Open "Project" app - Click on Studio - Click on edit menu button - Select a menu and drag and drop it to the root menu app (e.g Project) => a traceback occurs This error occurs because we don't have a root menu for the app menu to avoid this error, if no menu are found, we use the root menu app as root Forward-Port-Of: odoo/enterprise#47697