Monday, June 2, 2025
15 changes · 17.0
Resolved issues and error corrections
This fixes an error that appeared when visitors opened more information on an event exhibitor page while debug mode was enabled. The change helps event exhibitor pages behave reliably for website visitors and administrators testing the site.
Original PR description
Steps to reproduce: 1. Open Event > any upcoming event 2. make sure to check website submenu and showcase exhibitors 3. Create a sponsor with the exhibitor type and publish the website 4. Open private window in browser and go to exhibitor page by 5. Go to Events > Modfied Event > Exhibitor submenu 6. Turn on debug mode 7. Now click on more info button inside the exhibitor card Issue: - Invalid prop 'close' is used but not passed. Solution: - Add close prop in ExhibitorConnectClosedDialog Backport of https://github.com/odoo/odoo/commit/a8a0e3b7a36e743aa24c51f96f1947e3bcaa5a5f opw-4737183
Corrects the layout of the IBAN number in DIN 5008 PDF document footers so it appears neatly on one line. This improves the professionalism and readability of generated business documents.
Original PR description
### Before this commit: The `IBAN number` in the PDF footer is currently broken and displayed across multiple lines.  ### After this commit: Fix it by updating the CSS classes to ensure proper alignment and a cleaner UI layout.  > Task-4822070 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Hungarian EDI validation now allows companies to use either Hungarian forint or euros as their company currency. This fixes an unnecessary restriction so businesses operating in euros can use Hungarian electronic invoicing without being blocked.
Original PR description
Before this **PR**: Only HUF was allowed as valid currency on company for Hungarian EDI. After this **PR**: Now both HUF and EUR is allowed as valid currency for Hungarian EDI. **task**-4707271
Odoo now displays tracked decimal number changes in the chatter using the precision configured for each field, instead of always rounding to two decimal places. This makes audit trails and change history clearer for teams working with quantities, rates, or other values that require more exact decimals.
Original PR description
Currently all floats are formatted with the default of 2 in the chatter. Instead if "digits" is specified for the field we should display the field with that precision. Formatting tests were updated, which required adding the option to set the "digits" field value for fields on models that are fetched from back-end definitions. As that info is only stored in python and is not transmitted to the test framework, similarly to "default". task-4746268
Expense settings now show only payment methods linked to active accounting journals. This prevents outdated options from archived journals appearing during expense configuration, reducing confusion for administrators.
Original PR description
**Steps to reproduce:** 1. Accounting > Configuration Menu > Journals 2. Archive a Journals with outgoing payment method 3. Go to Expenses > Configuration Menu 4. Settings > Payment methods Under Accounting 5. Notice that the payment methods from archived journals are still visible **Issue:** - In this commit https://github.com/odoo/odoo/commit/c4f21085f8f77d8786eb1bc9494ae0fc1327b8b8 the overridden action_archived method was removed, which previously prevented journals with linked payment methods from being archived. **Solution:** - Update the company_expense_allowed_payment_method_line_ids field's domain field to include only payment methods from active journals opw-4745525
When creating a field service task, Odoo now selects the default project based on the same order users see in the project list. This avoids unexpected selections when multiple field service projects have the same priority and makes the setup behave more predictably.
Original PR description
Before this commit, when the user creates more than one fsm project, the default fsm project selected once a fsm task is created if the one with the lowest sequence and lowest id which could be confusing for the user since the default order displayed in the list view of projects is `sequence, name, id`. This commit makes sure the default fsm project fetched is the first one displayed in the list view of projects. opw-4791468
This fixes an extra space that could appear in the origin address field of Chilean electronic invoices when the second street line was empty. It helps ensure generated tax documents are formatted cleanly and consistently for compliance and processing.
Original PR description
**Steps to Reproduce :** 1. Install l10n_cl_edi. 2. Navigate to Contacts create an invoice for CL Company 3. Choose the document type: (33) Electronic Invoice. 4. Confirm the invoice. 5. Ensure the partner has only the street value set (e.g., "Name"), and street2 is empty. **Issue:** When generating the DTE, if street2 is empty, a trailing space appears in the <DirOrigen> tag ex: `DirOrigen>Name </DirOrigen>` **Solution:** Applied strip() to remove the extra space when street2 is empty. This ensures no trailing space when street2 is empty and proper spacing when both street and street2 is present. opw-4765451
The Argentina invoicing localization now treats missing AFIP authorization details as an expected user warning instead of a system error. This reduces false error alerts in monitoring tools while still informing users what they need to correct before confirming a vendor bill.
Original PR description
Currently, an error-level log is generated when confirming a Vendor Bill without setting the required AFIP Authorization Code. **Steps to Reproduce:** 1) Install `l10n_ar_edi module`. 2) Select…
Currently, an error-level log is generated when confirming a Vendor Bill without setting the required AFIP Authorization Code.
**Steps to Reproduce:**
1) Install `l10n_ar_edi module`.
2) Select Company having Argentina code (e.g **(AR)Exento**)
3) Navigate to `Invoicing->Configuration->settings`, under Argentina localization,
set `Verify Vendor Bills validity in AFIP` to **required**.
4) Create a new Vendor Bill, select Vendor Name (e.g **ADHOC SA**).
5) Click on confirm.
**Error:**
UserError('Please set AFIP Authorization Mode and Code to continue!')
**Root Cause:**
- The code calls `_logger.error(repr(error))` on any exception at [1] during the AFIP verification attempt, causing an ERROR‐level log entry.
[1]- https://github.com/odoo/enterprise/blob/ca16c89c6f53b1c0adb0a1a061d985bdf3439e5e/l10n_ar_edi/models/account_move.py#L500
**Solution:**
- This commit handles `UserError` exceptions separately using a warning log to prevent error-level entries.
Sentry-6576006813Web Studio now shows a controlled user-friendly error when a report template view has been deleted or is unavailable. This prevents an unexpected crash when users open affected reports, making the issue easier to understand and resolve.
Original PR description
Currently, an error occurs when a report view is missing, which might happen if the view is deleted from the settings. Steps to produce: - Install `sale_management` and `web_studio` modules. - Activate developer mode from settings. - Navigate `Settings > Technical > User Interface > Views.` - Delete the `tax_groups_totals` view. - Open web studio in sales order. - Navigate to the Reports menu and open `sale.report_saleorder_raw` (Quotation / Order). `ValueError: External ID not found in the system: account.tax_groups_totals` An error occurs because the system attempts to load a report view at [1], but it is not available. To resolve this issue, raise a `UserError` if the report view is not available or has been deleted. [1] - https://github.com/odoo/enterprise/blob/dfbd6b577fb834bbe1253537fe71d56cd57ae437/web_studio/controllers/report.py#L599 sentry-6223517463
Miscellaneous changes
…followers **Description of the issue/feature this PR addresses:** Currently all followers without portal access are able to see the button, in the email notification, that redirects to the portal (to see the quotation or sale order). This may be confusing and misleading, as the button will redirect them to the login page of the portal, to which they do not have access. This PR leaves the followers group options as default (button access disabled for followers) which ensures that only port
Original PR description
…followers **Description of the issue/feature this PR addresses:** Currently all followers without portal access are able to see the button, in the email notification, that redirects to the portal…
…followers **Description of the issue/feature this PR addresses:** Currently all followers without portal access are able to see the button, in the email notification, that redirects to the portal (to see the quotation or sale order). This may be confusing and misleading, as the button will redirect them to the login page of the portal, to which they do not have access. This PR leaves the followers group options as default (button access disabled for followers) which ensures that only portal users have access. **Current behavior before PR:** The 'follower' group in _notify_get_recipients_groups is being explicitly marked with 'has_button_access': True. Therefore followers without portal access are having access to the button. **Steps to reproduce:** 1. Configure odoo to be able to send out emails. 2. Install sale_management. 3. Create a sale order for a customer and add as follower another partner that has no portal access. This follower needs to have an email you have access to. 4. Send a message to the follower. 5. Test in the received email that the "View Quotation/Order" button is shown and when clicked, the user is redirected to the login page. **Desired behavior after PR is merged:** Only followers with portal access will have access to the button. Note that followers with portal access are directly categorized as 'portal_customer', so that is why it would make sense to simply remove the code where the followers without portal access are given access to the button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208402
When creating an invoice with a german customer, the domestic fiscal position is not applied. Instead, it's the european one which cause the invoice to have 0% taxes by default. opw-4448821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192512
Original PR description
When creating an invoice with a german customer, the domestic fiscal position is not applied. Instead, it's the european one which cause the invoice to have 0% taxes by default. opw-4448821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192512
**Issue** When displaying related products for a product attribute, only unarchived products are shown, even when the archived filter is applied. Steps to Reproduce: 1. Install the Sales app 2. Select or create a product 3. Select or create an attribute and values 4. Archive the product 5. Go to the attribute page 6. Click on related products smart button 7. Set Archived filter 8. Observe that the archived product is not displayed. Expected Behavior: After applying the Archived
Original PR description
**Issue** When displaying related products for a product attribute, only unarchived products are shown, even when the archived filter is applied. Steps to Reproduce: 1. Install the Sales app 2.…
**Issue** When displaying related products for a product attribute, only unarchived products are shown, even when the archived filter is applied. Steps to Reproduce: 1. Install the Sales app 2. Select or create a product 3. Select or create an attribute and values 4. Archive the product 5. Go to the attribute page 6. Click on related products smart button 7. Set Archived filter 8. Observe that the archived product is not displayed. Expected Behavior: After applying the Archived filter, related products, including archived ones, should be displayed. Actual Behavior: Archived related products are not shown, even when the Archived filter is applied. **Root Cause** When the related products smart button is clicked, the action_open_related_products method is triggered. In this method, when applying the domain for related products, an implicit active_test=True filter is applied by default. This filter excludes archived records, meaning only active (unarchived) products are displayed. **Fix** The issue was resolved by explicitly modifying the context to include archived products by setting active_test=False when querying the related products. This ensures that both active and archived related products are shown, even when the Archived filter is applied. opw-4565133 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197513
Supersede https://github.com/odoo/odoo/pull/210378 Backport of https://github.com/odoo/odoo/pull/187946 @qrtl QT5390 Forward-Port-Of: odoo/odoo#212027
Original PR description
Supersede https://github.com/odoo/odoo/pull/210378 Backport of https://github.com/odoo/odoo/pull/187946 @qrtl QT5390 Forward-Port-Of: odoo/odoo#212027
Fix crash when autofilling columns which where created by autofill. Task: 4719884 Forward-Port-Of: odoo/enterprise#83314
Original PR description
Fix crash when autofilling columns which where created by autofill. Task: 4719884 Forward-Port-Of: odoo/enterprise#83314
The current implementation to handle the rate for multi-currency entries in CAMT creates problems when fetching the source rate from the file: the source rate can be taken from the SrcCcy or the TrgtCcy node, which should be compared with the source currency and target currency respectively. It is not done that way and is too restrictive (when the SrcCcy is found, it is always compared to the target currency, which leads to an incorrect transaction amount). Moreover, when the currency convers
Original PR description
The current implementation to handle the rate for multi-currency entries in CAMT creates problems when fetching the source rate from the file: the source rate can be taken from the SrcCcy or the TrgtCcy node, which should be compared with the source currency and target currency respectively. It is not done that way and is too restrictive (when the SrcCcy is found, it is always compared to the target currency, which leads to an incorrect transaction amount). Moreover, when the currency conversion introduces a exchange loss/gain, it is put back on the largest transaction of the entry. Backport of https://github.com/odoo/enterprise/pull/76828 and https://github.com/odoo/enterprise/pull/42763 opw-4672283 Forward-Port-Of: odoo/enterprise#83131