Daily updates from Odoo
Navigate
Branch
Saturday, June 7, 2025
16 changes
3 changes
Resolved issues and error corrections
This fix removes redundant tooltip titles from message dropdown actions where the icon and label already explain the action. It reduces visual obstruction and makes message menus easier to use.
Original PR description
Message dropdown actions show both icon and label in text content. There's no need to have a redundant title as the text content that's annoying because it obstructs the list.
Miscellaneous changes
2 fix in this PR: ## [FIX] l10n_be_reports: 281.50 pdf use debtor where required The aim of this commit is to display the debtor info on the 281.50 pdf report instead of the sender info. Context: If there is a representative for the company, he will be set as the sender of the 281.50 and 325 instead of the company. Before this commit: The sender information was used in the pdf instead of the debtor information. After this commit: The debtor information are used as required.
Original PR description
2 fix in this PR: ## [FIX] l10n_be_reports: 281.50 pdf use debtor where required The aim of this commit is to display the debtor info on the 281.50 pdf report instead of the sender info. Context: If…
2 fix in this PR: ## [FIX] l10n_be_reports: 281.50 pdf use debtor where required The aim of this commit is to display the debtor info on the 281.50 pdf report instead of the sender info. Context: If there is a representative for the company, he will be set as the sender of the 281.50 and 325 instead of the company. Before this commit: The sender information was used in the pdf instead of the debtor information. After this commit: The debtor information are used as required. opw-4852895 ## [FIX] l10n_be_reports: 281.50 pdf add national number if available The aim of this commit is to add the national number on the 281.50 pdf if it is available. Context: The customer expects it to be filled if they filled it and it helps the authorities to identify the receiver. Before this commit: The national number wasn't added even if we had it. After this commit: The national number is added to the pdf if it is available for that partner. opw-4852895 Forward-Port-Of: odoo/enterprise#87253 Forward-Port-Of: odoo/enterprise#87109
Before this commit:- - In GST Return Return Period 'Push to GSTN' button triggers a cron to send GSTR-1 data, but on UI there is no information about whether the cron is running in backend or not? After this commit:- - Raise ValidationError if that required cron is disabled. - Show acknowledgement notification(ir.actions.client) after the cron is triggered. task-4653538 Forward-Port-Of: odoo/enterprise#87202 Forward-Port-Of: odoo/enterprise#84125
Original PR description
Before this commit:- - In GST Return Return Period 'Push to GSTN' button triggers a cron to send GSTR-1 data, but on UI there is no information about whether the cron is running in backend or not? After this commit:- - Raise ValidationError if that required cron is disabled. - Show acknowledgement notification(ir.actions.client) after the cron is triggered. task-4653538 Forward-Port-Of: odoo/enterprise#87202 Forward-Port-Of: odoo/enterprise#84125
8 changes
Enhancements to existing features
Spreadsheet-related screens were updated to stay compatible with the latest spreadsheet engine. Mobile users will no longer see unusable side-panel options, and spreadsheet views now better handle the on-screen keyboard so work areas resize correctly.
Miscellaneous changes
2 fix in this PR: ## [FIX] l10n_be_reports: 281.50 pdf use debtor where required The aim of this commit is to display the debtor info on the 281.50 pdf report instead of the sender info. Context: If there is a representative for the company, he will be set as the sender of the 281.50 and 325 instead of the company. Before this commit: The sender information was used in the pdf instead of the debtor information. After this commit: The debtor information are used as required.
Original PR description
2 fix in this PR: ## [FIX] l10n_be_reports: 281.50 pdf use debtor where required The aim of this commit is to display the debtor info on the 281.50 pdf report instead of the sender info. Context: If…
2 fix in this PR: ## [FIX] l10n_be_reports: 281.50 pdf use debtor where required The aim of this commit is to display the debtor info on the 281.50 pdf report instead of the sender info. Context: If there is a representative for the company, he will be set as the sender of the 281.50 and 325 instead of the company. Before this commit: The sender information was used in the pdf instead of the debtor information. After this commit: The debtor information are used as required. opw-4852895 ## [FIX] l10n_be_reports: 281.50 pdf add national number if available The aim of this commit is to add the national number on the 281.50 pdf if it is available. Context: The customer expects it to be filled if they filled it and it helps the authorities to identify the receiver. Before this commit: The national number wasn't added even if we had it. After this commit: The national number is added to the pdf if it is available for that partner. opw-4852895 Forward-Port-Of: odoo/enterprise#87253 Forward-Port-Of: odoo/enterprise#87109
Currently when auto-configuring IoT with pos printers we take the first available receipt printer we assign to PoS we chose. However if the printer is usb-connected it should take priority over network printers for the reliability reasons. task-4853231 Forward-Port-Of: odoo/enterprise#87183
Original PR description
Currently when auto-configuring IoT with pos printers we take the first available receipt printer we assign to PoS we chose. However if the printer is usb-connected it should take priority over network printers for the reliability reasons. task-4853231 Forward-Port-Of: odoo/enterprise#87183
**Issue:** When an email with an attachment was sent to a project alias (configured to create tasks and documents in a specific project), and the target project's Documents folder was explicitly owned by a company (`Company2`) distinct from the current system company (`Company1`), the alias creation process for the resulting documents would fail. The error message indicated a domain mismatch: "We could not create alias Inactive Alias because domain company1.com belongs to company YourCompany
Original PR description
**Issue:** When an email with an attachment was sent to a project alias (configured to create tasks and documents in a specific project), and the target project's Documents folder was explicitly…
**Issue:** When an email with an attachment was sent to a project alias (configured to create tasks and documents in a specific project), and the target project's Documents folder was explicitly owned by a company (`Company2`) distinct from the current system company (`Company1`), the alias creation process for the resulting documents would fail. The error message indicated a domain mismatch: "We could not create alias Inactive Alias because domain company1.com belongs to company YourCompany while the owner document belongs to company Company2." **Proposed Solution and Justification:** The chosen solution centralizes the `company_id` assignment for new documents within the `_get_document_vals` method of the `documents.mixin.DocumentMixin` abstract model. This method is the primary entry point for determining default values when any model inheriting `DocumentMixin` creates a linked `documents.document` record. The fix ensures that when `document_vals` are prepared, the `company_id` of the new document is explicitly pulled from the `company_id` of its designated `folder` (retrieved via `_get_document_folder()`). **Unit Test Placement Justification:** The accompanying unit test has been placed within the `documents_project` module for the following reasons: * **Module Scope:** The bug specifically manifests when the 'Project' and 'Documents' modules interact via email aliases, a workflow directly supported by the `documents_project` module. Placing the test here ensures it covers the integrated functionality. * **Dependency Guarantee:** By placing it in `documents_project`, the test runner ensures that both `project` and `documents` modules (and their dependencies) are installed and loaded, providing the correct environment to reproduce and verify the fix for the multi-module interaction. * **Functional Relevance:** The test setup mirrors a real-world user workflow (creating a project alias for tasks and documents) that is enabled by the `documents_project` module. **Steps to reproduce:** 1. Install the 'Project' and 'Documents' modules on a fresh Odoo 18 database with demo data. 2. Create two distinct companies via the UI (e.g., Company1, Company2). 3. Ensure each company has a distinct alias domain configured (e.g. @company1domain.com for Company1, @company2domain.com for Company2). 4. Switch to 'Company2'. In the Projects app, create a new project in the Kanban view. 5. During the project configuration wizard, fill out the "Create tasks by sending an email to" field, creating an email alias for the project (e.g. `project@company2domain.com`). 6. In the project settings, ensure the project is restricted to 'Company2' only. 7. Go to 'Documents' -> 'Projects'. Find the folder specific to the newly created project and also restrict it to 'Company2' only. 8. Send a test email with a PDF attachment to the project's alias (e.g. `project@company2domain.com`). 9. Observe the traceback in the server logs, showing the company mismatch error. opw-4727873 Forward-Port-Of: odoo/enterprise#87021 Forward-Port-Of: odoo/enterprise#86389
Before this commit:- - In GST Return Return Period 'Push to GSTN' button triggers a cron to send GSTR-1 data, but on UI there is no information about whether the cron is running in backend or not? After this commit:- - Raise ValidationError if that required cron is disabled. - Show acknowledgement notification(ir.actions.client) after the cron is triggered. task-4653538 Forward-Port-Of: odoo/enterprise#87202 Forward-Port-Of: odoo/enterprise#84125
Original PR description
Before this commit:- - In GST Return Return Period 'Push to GSTN' button triggers a cron to send GSTR-1 data, but on UI there is no information about whether the cron is running in backend or not? After this commit:- - Raise ValidationError if that required cron is disabled. - Show acknowledgement notification(ir.actions.client) after the cron is triggered. task-4653538 Forward-Port-Of: odoo/enterprise#87202 Forward-Port-Of: odoo/enterprise#84125
There was a corner case where a single partner should match a statement line but would not. The case was when the statement line account number matches multiple accounts that are linked to the same active partner. This commit fixes this issue by relying on the number of partners instead of the number of banks while matching. task-4826477 Forward-Port-Of: odoo/enterprise#87214
Original PR description
There was a corner case where a single partner should match a statement line but would not. The case was when the statement line account number matches multiple accounts that are linked to the same active partner. This commit fixes this issue by relying on the number of partners instead of the number of banks while matching. task-4826477 Forward-Port-Of: odoo/enterprise#87214
Currently, the "Invite" button is visible to portal users. When a portal user clicks this button, the system attempts to open a wizard using the `knowledge.invite` model. However, because portal users lack access rights to this model, the system raises an "Access Error". Steps to reproduce: 1. Log in as a portal user 2. Open an article 3. Click on the "Share" button 4. Click on the "Invite" button => Traceback: Access Error on the model `knowledge.invite` To fix the issue, we will s
Original PR description
Currently, the "Invite" button is visible to portal users. When a portal user clicks this button, the system attempts to open a wizard using the `knowledge.invite` model. However, because portal users lack access rights to this model, the system raises an "Access Error". Steps to reproduce: 1. Log in as a portal user 2. Open an article 3. Click on the "Share" button 4. Click on the "Invite" button => Traceback: Access Error on the model `knowledge.invite` To fix the issue, we will simply hide the "Invite" button for the portal user as it was the case before the permission panel refactoring. See: odoo/enterprise#76261 Task-4636494 Forward-Port-Of: odoo/enterprise#86086
This commit will revert part of this commit: https://github.com/odoo/enterprise/commit/6a2716e4d58f3b8d913a785f263e910eb5334ea0 Where we removed a domain that was hiding the number of reconcile entries for line that don't have partners. The number showed was wrong (for example displaying 15 but you have like 70 in the wizard) and the perf impact was huge (18s in average to compute the reconcile number) no task id Forward-Port-Of: odoo/enterprise#87099
Original PR description
This commit will revert part of this commit: https://github.com/odoo/enterprise/commit/6a2716e4d58f3b8d913a785f263e910eb5334ea0 Where we removed a domain that was hiding the number of reconcile entries for line that don't have partners. The number showed was wrong (for example displaying 15 but you have like 70 in the wizard) and the perf impact was huge (18s in average to compute the reconcile number) no task id Forward-Port-Of: odoo/enterprise#87099
5 changes
Resolved issues and error corrections
Chat windows now keep their intended size more consistently in Safari. This prevents the chat panel from becoming too narrow when the browser window has limited vertical space, improving usability for Safari users.
Original PR description
Before this commit, chat window size on Safari sometimes look off. The intended sizing is 380px in width and 9/15 ratio, with height being limited by 95vh. Safari `aspect-ratio` has strange behavior: instead of shrinking just the height from max-height, it gives too much priority on enforcing the aspect-ratio, thus the chat window becomes thinner and thinner the less vertical space there are. This commit fixes the issue by replacing the `aspect-ratio` style by a max-height that is computed with ratio and 95vh.
This fix prevents portal users from seeing an error when they click Comment to reply in the chatter. Replies now correctly show the user's avatar and keep the conversation flow working as expected.
Original PR description
Before this commit, clicking on "Comment" button in portal chatter to reply to a message leads to the following crash: ``` TypeError: Cannot read properties of null (reading 'effectiveSelf') ``` This…
Before this commit, clicking on "Comment" button in portal chatter to reply to a message leads to the following crash: ``` TypeError: Cannot read properties of null (reading 'effectiveSelf') ``` This happens because it opens the composer to reply to the message. Replying to a message should normally use the composer of thread and rely on `props.messageToReplyTo` from the `useMessageToReplyTo` hook, but portal chatter instead makes a composer linked to the message. The problem is that a message linked to a composer is actually meant to say the composer is for editing the message, and when editing the message the composer shows no avatar as this is shown by the `Message` component. Portal chatter reply to comment should display avatar of self user, but the problem is that the component `Composer` isn't directly linked to `thread`, therefore the LOC `thread.effectiveSelf` crashes in template. This commit fixes the issue by using the `message` linked to composer when no immediate thread is found in order to display the `effectiveSelf` avatar. A composer is necessarily linked to either a thread or composer, thus this ensures the `effectiveSelf` is defined.
Miscellaneous changes
When the user tries to send & print the invoice, A traceback will appear. Steps to reproduce the error: - Create a new Customer: A > Country: Netherlands > In Invoicing, Format: NLCIUS Peppol e-address (EAS): 0106 > Save - Create a new invoice > Customer: A > Confirm > Send & Print > Select NLCIUS > Send & Print Traceback: ``` TypeError: object of type 'bool' has no len() ``` https://github.com/odoo/odoo/blob/d123df0a0aacd88d89cefb51a795e7865374a46d/addons/account_edi_ubl_ci
Original PR description
When the user tries to send & print the invoice, A traceback will appear. Steps to reproduce the error: - Create a new Customer: A > Country: Netherlands > In Invoicing, Format: NLCIUS Peppol e-address (EAS): 0106 > Save - Create a new invoice > Customer: A > Confirm > Send & Print > Select NLCIUS > Send & Print Traceback: ``` TypeError: object of type 'bool' has no len() ``` https://github.com/odoo/odoo/blob/d123df0a0aacd88d89cefb51a795e7865374a46d/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L84-L87 Here, If ``nl_id`` is False, It results in the traceback mentioned above. opw-4840552 sentry-6653896965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212904
Before this commit, if the module was installed, the delivered quantity for non-rental products in a sale order paid through PoS would be doubled. opw-4805368 Forward-Port-Of: odoo/enterprise#87175
Original PR description
Before this commit, if the module was installed, the delivered quantity for non-rental products in a sale order paid through PoS would be doubled. opw-4805368 Forward-Port-Of: odoo/enterprise#87175
2 fix in this PR: ## [FIX] l10n_be_reports: 281.50 pdf use debtor where required The aim of this commit is to display the debtor info on the 281.50 pdf report instead of the sender info. Context: If there is a representative for the company, he will be set as the sender of the 281.50 and 325 instead of the company. Before this commit: The sender information was used in the pdf instead of the debtor information. After this commit: The debtor information are used as required.
Original PR description
2 fix in this PR: ## [FIX] l10n_be_reports: 281.50 pdf use debtor where required The aim of this commit is to display the debtor info on the 281.50 pdf report instead of the sender info. Context: If…
2 fix in this PR: ## [FIX] l10n_be_reports: 281.50 pdf use debtor where required The aim of this commit is to display the debtor info on the 281.50 pdf report instead of the sender info. Context: If there is a representative for the company, he will be set as the sender of the 281.50 and 325 instead of the company. Before this commit: The sender information was used in the pdf instead of the debtor information. After this commit: The debtor information are used as required. opw-4852895 ## [FIX] l10n_be_reports: 281.50 pdf add national number if available The aim of this commit is to add the national number on the 281.50 pdf if it is available. Context: The customer expects it to be filled if they filled it and it helps the authorities to identify the receiver. Before this commit: The national number wasn't added even if we had it. After this commit: The national number is added to the pdf if it is available for that partner. opw-4852895 Forward-Port-Of: odoo/enterprise#87234 Forward-Port-Of: odoo/enterprise#87109