Daily updates from Odoo
Saturday, July 25, 2026
45 changes
4 changes
Resolved issues and error corrections
It currently deleted the inner mail.message, while it should actually remove mail.mail records. Removing messages is managed at mail.mail unlink level using the 'is_notification' field. Indeed a mass_mailing email should remove the linked mail.message, while a canceled notification email should not remove the chatter message. Followup of odoo/odoo#209494 Forward-Port-Of: odoo/odoo#278321 Forward-Port-Of: odoo/odoo#277993
Original PR description
It currently deleted the inner mail.message, while it should actually remove mail.mail records. Removing messages is managed at mail.mail unlink level using the 'is_notification' field. Indeed a mass_mailing email should remove the linked mail.message, while a canceled notification email should not remove the chatter message. Followup of odoo/odoo#209494 Forward-Port-Of: odoo/odoo#278321 Forward-Port-Of: odoo/odoo#277993
Currentyl the unsupported models will be checked like the following ```sql ia.res_model NOT IN ARRAY['model1', 'model2'] ``` This causes a syntax error. Use `ANY` to avoid the issue ```sql ia.res_model != ANY(ARRAY['model1', 'model2']) ``` Reproduce in Odoo shell ```python from odoo.tools import SQL query = SQL(""" SELECT ia.id FROM ir_attachment ia WHERE ia.res_model NOT IN %(unsupported_models)s LIMIT 1; """, unsupported_models=self.env['ir.atta
Original PR description
Currentyl the unsupported models will be checked like the following
```sql
ia.res_model NOT IN ARRAY['model1', 'model2']
```
This causes a syntax error. Use `ANY` to avoid the issue
```sql
ia.res_model != ANY(ARRAY['model1', 'model2'])
```
Reproduce in Odoo shell
```python
from odoo.tools import SQL
query = SQL("""
SELECT ia.id
FROM ir_attachment ia
WHERE ia.res_model NOT IN %(unsupported_models)s
LIMIT 1;
""",
unsupported_models=self.env['ir.attachment']._get_cloud_storage_unsupported_models(),
)
```
opw-6404861
Forward-Port-Of: odoo/odoo#277971Steps to reproduce ================== - Log in with the portal user (or any user without karma points). - Open a forum post. - Try to mark it as the best answer. Technical ========= From here https://github.com/odoo/odoo/pull/215145/changes/46e5ab20cb33536f0cf12d2fc3690beaa11697ee `htmlJoin` expects its first argument to be an iterable and its second argument separator to be a string. Passing the message string as the first argument causes it to be treated as an iterable of characters,
Original PR description
Steps to reproduce ================== - Log in with the portal user (or any user without karma points). - Open a forum post. - Try to mark it as the best answer. Technical ========= From here https://github.com/odoo/odoo/pull/215145/changes/46e5ab20cb33536f0cf12d2fc3690beaa11697ee `htmlJoin` expects its first argument to be an iterable and its second argument separator to be a string. Passing the message string as the first argument causes it to be treated as an iterable of characters, while the guideline markup passed as the second argument is unintentionally used as the separator. As a result, the guideline link is inserted between every character of the message instead of being appended after it. Wrap the message and the additional guideline text in an array when calling `htmlJoin` so the notification is rendered correctly. Task-6302585 Forward-Port-Of: odoo/odoo#276137
Because of this PR https://github.com/odoo/odoo/pull/235719 Audit Trail no longer functions as expected: 1) Tracking messages no longer show in the Audit Trail 2) Description is missing from Audit Trail This commit fixes these issues. task-6413110 Forward-Port-Of: odoo/odoo#278099
Original PR description
Because of this PR https://github.com/odoo/odoo/pull/235719 Audit Trail no longer functions as expected: 1) Tracking messages no longer show in the Audit Trail 2) Description is missing from Audit Trail This commit fixes these issues. task-6413110 Forward-Port-Of: odoo/odoo#278099
5 changes
Resolved issues and error corrections
Currentyl the unsupported models will be checked like the following ```sql ia.res_model NOT IN ARRAY['model1', 'model2'] ``` This causes a syntax error. Use `ANY` to avoid the issue ```sql ia.res_model != ANY(ARRAY['model1', 'model2']) ``` Reproduce in Odoo shell ```python from odoo.tools import SQL query = SQL(""" SELECT ia.id FROM ir_attachment ia WHERE ia.res_model NOT IN %(unsupported_models)s LIMIT 1; """, unsupported_models=self.env['ir.atta
Original PR description
Currentyl the unsupported models will be checked like the following
```sql
ia.res_model NOT IN ARRAY['model1', 'model2']
```
This causes a syntax error. Use `ANY` to avoid the issue
```sql
ia.res_model != ANY(ARRAY['model1', 'model2'])
```
Reproduce in Odoo shell
```python
from odoo.tools import SQL
query = SQL("""
SELECT ia.id
FROM ir_attachment ia
WHERE ia.res_model NOT IN %(unsupported_models)s
LIMIT 1;
""",
unsupported_models=self.env['ir.attachment']._get_cloud_storage_unsupported_models(),
)
```
opw-6404861
Forward-Port-Of: odoo/odoo#277971It currently deleted the inner mail.message, while it should actually remove mail.mail records. Removing messages is managed at mail.mail unlink level using the 'is_notification' field. Indeed a mass_mailing email should remove the linked mail.message, while a canceled notification email should not remove the chatter message. Followup of odoo/odoo#209494 Forward-Port-Of: odoo/odoo#278321 Forward-Port-Of: odoo/odoo#277993
Original PR description
It currently deleted the inner mail.message, while it should actually remove mail.mail records. Removing messages is managed at mail.mail unlink level using the 'is_notification' field. Indeed a mass_mailing email should remove the linked mail.message, while a canceled notification email should not remove the chatter message. Followup of odoo/odoo#209494 Forward-Port-Of: odoo/odoo#278321 Forward-Port-Of: odoo/odoo#277993
Steps to reproduce ================== - Log in with the portal user (or any user without karma points). - Open a forum post. - Try to mark it as the best answer. Technical ========= From here https://github.com/odoo/odoo/pull/215145/changes/46e5ab20cb33536f0cf12d2fc3690beaa11697ee `htmlJoin` expects its first argument to be an iterable and its second argument separator to be a string. Passing the message string as the first argument causes it to be treated as an iterable of characters,
Original PR description
Steps to reproduce ================== - Log in with the portal user (or any user without karma points). - Open a forum post. - Try to mark it as the best answer. Technical ========= From here https://github.com/odoo/odoo/pull/215145/changes/46e5ab20cb33536f0cf12d2fc3690beaa11697ee `htmlJoin` expects its first argument to be an iterable and its second argument separator to be a string. Passing the message string as the first argument causes it to be treated as an iterable of characters, while the guideline markup passed as the second argument is unintentionally used as the separator. As a result, the guideline link is inserted between every character of the message instead of being appended after it. Wrap the message and the additional guideline text in an array when calling `htmlJoin` so the notification is rendered correctly. Task-6302585 Forward-Port-Of: odoo/odoo#276137
Issue: When a shopper pays for an online order entirely using a reward (e.g. a discount code covering 100% of the total), the order total is zero. With automatic invoicing enabled, an invoice with an amount of 0 is created. But, the 0 invoice is never emailed to the customer. Whereas, for orders where the total is more than 0, an invoice is created, then emailed to the customer. The customer should be emailed the invoice, even if its amount is 0. Steps to reproduce: 1. Enable automatic invo
Original PR description
Issue: When a shopper pays for an online order entirely using a reward (e.g. a discount code covering 100% of the total), the order total is zero. With automatic invoicing enabled, an invoice with an…
Issue: When a shopper pays for an online order entirely using a reward (e.g. a discount code covering 100% of the total), the order total is zero. With automatic invoicing enabled, an invoice with an amount of 0 is created. But, the 0 invoice is never emailed to the customer. Whereas, for orders where the total is more than 0, an invoice is created, then emailed to the customer. The customer should be emailed the invoice, even if its amount is 0. Steps to reproduce: 1. Enable automatic invoicing. 2. Create a code for a 100% discount. 3. As a shopper, add a product to cart on the website. 4. While checking out, apply the 100% discount code to the order. 5. Complete the checkout. 6. Confirm that an invoice was created and posted, but was not emailed to the customer. Explanation: Normally, order confirmation and invoicing are handled by the `_post_process` method on the `payment.transaction` model. With automatic invoicing enabled, `_post_process` confirms the sale order, creates the invoice, and sends the invoice via `_send_invoice` (another method on the `payment.transaction` model). If `sale.async_emails` is enabled, `_post_process` will trigger a cron that invokes `_send_invoice` instead of invoking it directly. When an order is fully covered by a reward, there's nothing to pay. In this case, no payment.transaction record is ever created, and `_post_process` never runs. Instead, the order is confirmed through the `_validate_order` method on the `sale.order` model. The `sale_loyalty` module extends `_validate_order` so that, with automatic invoicing enabled, it will create and post an invoice for zero-amount orders. But, nothing in this path ever calls `_send_invoice` or an equivalent. So, the invoice is created and posted but never sent. Solution: This adds logic for sending invoices to the extension of `_validate_order` in the `sale_loyalty` module. We mirror the logic used in `_send_invoice` in the `payment.transaction` model. Notes: There is duplicated code from `_send_invoice` in this fix. That is because `_send_invoice`, a method on the `payment.transaction` model, can't be used in this flow. A fix that avoids code duplication would require serious refactoring. This will never trigger a cron to send the invoice, even if `sale.async_emails` is enabled. That is because the cron invokes `_send_invoice`. Since fully reward-covered orders are probably not common, any performance benefits of using a cron are probably not significant. But, making a new cron to be used in this case is also an option. opw-6363334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277678 Forward-Port-Of: odoo/odoo#275190
**STEP TO REPRODUCE** 1. Install l10n_fr_pdp and select the french company. 2. Go on a contact form, under invoicing, select 'by Approved Platform' for invoice sending. 3. Click on the eInvoice format selection, and notice the format 'France E-invoicing (UBL 2.1)' is not there. Note: with other invoice sending values, it shows up. **CAUSE** In the `_get_ubl_cii_formats_info()` override in `l10n_fr_pdp`, we declare the ubl_21_fr format as not being usable with the peppol invoice sending me
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_fr_pdp and select the french company. 2. Go on a contact form, under invoicing, select 'by Approved Platform' for invoice sending. 3. Click on the eInvoice format selection, and notice the format 'France E-invoicing (UBL 2.1)' is not there. Note: with other invoice sending values, it shows up. **CAUSE** In the `_get_ubl_cii_formats_info()` override in `l10n_fr_pdp`, we declare the ubl_21_fr format as not being usable with the peppol invoice sending method. However, the Approved Platform invoice sending (used to send ubl_21_fr) *is* the peppol invoice sending method in disguise. (we reused the peppol invoice sending method because pdp and peppol are very similar). opw-6387796 Forward-Port-Of: odoo/odoo#276276
28 changes
Enhancements to existing features
After this advisory: https://services.gst.gov.in/services/advisoryandreleases/read/661 It has become mandatory to pass `shipToGSTIN`, i.e. GST number of the ship-to partner during the generation of the e-waybill for `Bill-to-Ship-to` (type-2) and `Combination` (type-4) transaction types. task-6236778 Forward-Port-Of: odoo/odoo#266388
Original PR description
After this advisory: https://services.gst.gov.in/services/advisoryandreleases/read/661 It has become mandatory to pass `shipToGSTIN`, i.e. GST number of the ship-to partner during the generation of the e-waybill for `Bill-to-Ship-to` (type-2) and `Combination` (type-4) transaction types. task-6236778 Forward-Port-Of: odoo/odoo#266388
This commit adds `company_register` VAT Registry (VAT ID) to the invoice header for [legal reasons](https://lex.uz/ru/docs/4948595#5225819). Also, the condition for `TIN` has been updated to be 14 digits if the contact is a person and 9 digits if it is a company. task-6205255 Forward-Port-Of: odoo/odoo#273885
Original PR description
This commit adds `company_register` VAT Registry (VAT ID) to the invoice header for [legal reasons](https://lex.uz/ru/docs/4948595#5225819). Also, the condition for `TIN` has been updated to be 14 digits if the contact is a person and 9 digits if it is a company. task-6205255 Forward-Port-Of: odoo/odoo#273885
Resolved issues and error corrections
After saving or resetting a timesheet timer entry, the description field is automatically focused again. This removes an extra click for users entering multiple timesheets and makes repeated time entry smoother.
Original PR description
Steps to reproduce: - Install the timesheets application. - Open the timesheet timer menu from the systray. - Fill out the new timesheet entry. - Click the 'Save' or 'Reset' button (or use the keyboard hotkey). - Notice that the cursor focus is lost and the user must manually click back into the description field to start a new entry. Cause: - When a user clicks save or reset, the existing form is cleared via a DOM patch. Because the component is not remounted, the initial onMounted focus logic does not execute again. Fix: - Use onPatched to check if the save or discard button is the active element, and automatically re-focus the description input. task-6357438
This fixes an issue where accounting reports could fail to recognize that no report section had been opened yet. The change helps ensure reports start from the correct state and behave more reliably for users.
Original PR description
**Root Cause:**
At [1], the condition `this.lastOpenedSectionByReport === {}` always
return `false` because JavaScript compares objects by reference
rather than by value. As a result, the code never detects when
`lastOpenedSectionByReport` is empty.
**Fix:**
This commit ensures the code correctly detects an empty
`lastOpenedSectionByReport` object.
[1]:
https://github.com/odoo/enterprise/blob/ae4b461edb1d6b49c25d4e264380e7ae4b67f10c/account_reports/static/src/components/account_report/controller.js#L50
**No task ID**
Forward-Port-Of: odoo/enterprise#125325
Forward-Port-Of: odoo/enterprise#124223Timesheet automatic work suggestions now correctly link Discuss-related time to the Discuss app instead of the database record. This helps users see more accurate activity suggestions and avoids misclassified time entries.
Original PR description
## Previous Behavior: When generateing AW sugestions, discuss related time would be associated to the DB and not the discuss app inside the database. ## Task task-[5167914](https://www.odoo.com/odoo/project/4105/tasks/5167914/project.task/6381120/project.task/6409826)
Fixed a rounding issue that could show a tiny incorrect end balance in exported trial balance reports when the true balance was zero. This helps finance users avoid confusion from near-zero amounts appearing in XLSX exports.
Original PR description
Steps to reproduce -------------------- - Install account_reports module; - Create a new account; - Create a miscellanous operation for the previous month using thenew account with a credit amount of $8.28; - Create a second MISC for the current month with two lines using the account : debit = 262.67 and credit = 254.39; - Open the trial balance report and filter the new account (end balance should be 0); - Export the report as XLSX; The end balance value is 2.84e-14 due to float rounding issues. opw-6369016 Forward-Port-Of: odoo/enterprise#123896
The U.S. Profit and Loss report no longer crashes if a configurable summary line, such as Gross Profit, has been deleted. This keeps accounting reports accessible after customization while preserving the intended formatting for remaining standard lines.
Original PR description
## Steps to Reproduce: 1. Install the Accounting module with demo data. 2. Enable developer mode. 3. Go to Reporting > Profit and Loss. 4. Click Configuration and delete the 'Gross Profit' line. 5. Return to the report. ## Error: `ValueError: External ID not found in the system: l10n_us_reports.pl_gross_profit` ## Cause: The report assumes the summary lines always exist and tries to fetch XML IDs. If any of these lines has been deleted, looking up will raises an error. ## Fix: Only apply the bold class to summary lines whose XML IDs are available. sentry-7601831925 Forward-Port-Of: odoo/enterprise#124011
The French VAT report export now sends the BA zone using the expected free-text format instead of a standard value field. This helps ensure the report matches the required submission structure and reduces the risk of filing issues.
Original PR description
The value inside the BA zone needs to be a "TexteLibre1" and not a value no task id Forward-Port-Of: odoo/enterprise#125335
**Problem:** After partially invoicing a timesheet-delivered sale order line, a second invoice for the remaining delivered quantity can no longer be created. **Steps to reproduce:** 1. Install Sales and Timesheets 2. Sell a service invoiced on delivered timesheets 3. Log a timesheet covering the whole period 4. Create an invoice, reduce its quantity to part of the delivered amount, and post it 5. Create an invoice again for the rest **Current behavior:** "Cannot create an invoice. N
Original PR description
**Problem:** After partially invoicing a timesheet-delivered sale order line, a second invoice for the remaining delivered quantity can no longer be created. **Steps to reproduce:** 1. Install Sales…
**Problem:** After partially invoicing a timesheet-delivered sale order line, a second invoice for the remaining delivered quantity can no longer be created. **Steps to reproduce:** 1. Install Sales and Timesheets 2. Sell a service invoiced on delivered timesheets 3. Log a timesheet covering the whole period 4. Create an invoice, reduce its quantity to part of the delivered amount, and post it 5. Create an invoice again for the rest **Current behavior:** "Cannot create an invoice. No items are available to invoice." is raised, even though qty_delivered - qty_invoiced is still positive. **Expected behavior:** A second invoice is created for the remaining delivered quantity. **Cause of the issue:** Since opw-6001094, `_recompute_qty_to_invoice` runs on every invoice creation, not only when a timesheet period is provided. It re-derives `qty_to_invoice` from un-invoiced timesheets alone. Posting the first invoice already linked every timesheet of the line (the linking ignores the invoiced quantity), so no un-invoiced timesheet is left, and `qty_to_invoice` is forced to 0 — discarding the still-billable remainder. **Fix:** Forcing the quantity to zero is only meaningful when the invoice is restricted to a timesheet period, where a line whose timesheets all fall outside that period genuinely has nothing to invoice. Without a period, the standard delivered-versus-invoiced quantity is the authoritative measure of what remains to bill, so the timesheet-based recomputation must not override it. opw-6295941 Forward-Port-Of: odoo/odoo#274677
Steps to reproduce: ------------------------- 1. Install hr_timesheet and create a second company (e.g., Company B). 2. Create a global project (no company assigned) with timesheets enabled. 3. Share the project with edit access to a portal user belonging to Company A.4 4. Create a task, switch to Company B, and log a timesheet on the task. 5. Log in as the portal user and try to access the project. Issue: ------- An `Access to unauthorized or invalid companies exception` is raised,
Original PR description
Steps to reproduce: ------------------------- 1. Install hr_timesheet and create a second company (e.g., Company B). 2. Create a global project (no company assigned) with timesheets enabled. 3. Share…
Steps to reproduce: ------------------------- 1. Install hr_timesheet and create a second company (e.g., Company B). 2. Create a global project (no company assigned) with timesheets enabled. 3. Share the project with edit access to a portal user belonging to Company A.4 4. Create a task, switch to Company B, and log a timesheet on the task. 5. Log in as the portal user and try to access the project. Issue: ------- An `Access to unauthorized or invalid companies exception` is raised, preventing the portal user from accessing a project they are legitimately shared on. Cause: ---------- https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L159-L173 During `_prepare_project_sharing_session_info`, hr_timesheet overrides the company determination logic through `_get_project_sharing_company()`. https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/hr_timesheet/controllers/project.py#L13-L18 For global projects, the company is derived from an existing timesheet if one exists. As a result, creating a timesheet in another company causes that company to be injected into the sharing session as the current company. Since the portal user does not have access to that company, opening the project triggers an access error. Solution: ---------- Remove the `_get_project_sharing_company()` override. The base implementation already falls back to the portal user's own company when the project has no company assigned, ensuring the sharing session only contains companies the portal user is allowed to access. https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L141-L142 This allows portal users from Company A to continue accessing global projects without errors. opw-6253960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277640 Forward-Port-Of: odoo/odoo#272161
### Description of the issue/feature this PR addresses: - Opening Studio on a form containing a Many2many field using the many2many_tags_email widget crashes with an OWL prop validation error. - **Steps to reproduce:** 1. Open any form view (e.g., Contacts) and enter `Studio`. 2. Create a new `Many2many` custom field on a model such as `res.partner`. 3. Set the field's widget to `many2many_tags_email` and save the customization. 4. Exit Studio and populate the field with one or more
Original PR description
### Description of the issue/feature this PR addresses: - Opening Studio on a form containing a Many2many field using the many2many_tags_email widget crashes with an OWL prop validation error. -…
### Description of the issue/feature this PR addresses: - Opening Studio on a form containing a Many2many field using the many2many_tags_email widget crashes with an OWL prop validation error. - **Steps to reproduce:** 1. Open any form view (e.g., Contacts) and enter `Studio`. 2. Create a new `Many2many` custom field on a model such as `res.partner`. 3. Set the field's widget to `many2many_tags_email` and save the customization. 4. Exit Studio and populate the field with one or more related records. 5. Open Studio again on the same form view. This results in the following error: ```.js Error: Invalid props for component 'RecipientTag': 'onDelete' is undefined (should be a value) ``` ### Current behavior before PR: - When opening Studio on a form containing a `Many2many` field with the `many2many_tags_email` widget, the field is rendered with `onDelete` set to undefined by `Many2ManyTagsField`. Starting from `saas-19.1`, the `many2many_tags_email` widget uses the new [RecipientTag] component, which requires onDelete to be defined. As a result, Owl's prop validation fails when RecipientTag receives `onDelete = undefined`, causing Studio to crash with an I nvalid props for component 'RecipientTag' error. ### Desired behavior after PR is merged: - RecipientTag should allow onDelete to be optional so that it can also be used when the parent field does not provide a delete callback. This prevents the Owl prop validation error when opening Studio, while keeping the existing delete functionality unchanged for editable fields where onDelete is available. opw:6395209 [RecipientTag]: https://github.com/odoo/odoo/blob/saas-19.1/addons/mail/static/src/core/web/recipient_tag.js --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277934
Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left over from a previous loop (the last move line iterated) instead of the company of the group of lines being checked. Steps to reproduce: - in a multi-company database, create a product tracked by lots - create a lot with the same name for that product in each company - create one receipt per compan
Original PR description
Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left…
Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left over from a previous loop (the last move line iterated) instead of the company of the group of lines being checked. Steps to reproduce: - in a multi-company database, create a product tracked by lots - create a lot with the same name for that product in each company - create one receipt per company with that lot name typed in the detailed operations, select both receipts in the Transfers list view and validate them together The lines of one company are linked to the lot of the other company and the validation is blocked by "Incompatible companies on records". When the lot only exists in one of the companies, the search misses it and the validation fails on the lot uniqueness constraint while recreating a lot that already exists. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277227 Forward-Port-Of: odoo/odoo#276688
Steps: - Install sale app. - Create SO for portal user. - Login with portal user. - Vat field is not editable and warning is wrong. Issue: - Before https://github.com/odoo/odoo/pull/211043 and recent fix https://github.com/odoo/odoo/pull/275207 portal user can edit their Vat number even if they have confirmed documents (invoice or SO) if Vat field is not set. Since `is_company` refactoring having set parent_name on address create related company and making `is_commercial_address` False a
Original PR description
Steps: - Install sale app. - Create SO for portal user. - Login with portal user. - Vat field is not editable and warning is wrong. Issue: - Before https://github.com/odoo/odoo/pull/211043 and recent fix https://github.com/odoo/odoo/pull/275207 portal user can edit their Vat number even if they have confirmed documents (invoice or SO) if Vat field is not set. Since `is_company` refactoring having set parent_name on address create related company and making `is_commercial_address` False and because that `Vat` field became reaonly and after recent fix `is_commercial_address` was set from `can_edit_vat` and validation done based on `can_edit_vat` before that `Vat` was editable if they have confirmed documents Fix: - Only make `Vat` readonly if Vat is set and is not individual address Forward-Port-Of: odoo/odoo#277459
Steps to reproduce 1. Go to Website Settings. 2. Configure the "Contact Us" form to create an Opportunity. 3. Select a "Default Sales Team" (ensure this team has a Team Leader set). 4. Leave the "Default Salesperson" field empty (None). 5. Submit the "Contact Us" form on the website. Current behavior The resulting Opportunity is automatically assigned to the Team Leader. Expected behavior The Opportunity should remain unassigned, respecting the empty "Default Salesperson" configura
Original PR description
Steps to reproduce 1. Go to Website Settings. 2. Configure the "Contact Us" form to create an Opportunity. 3. Select a "Default Sales Team" (ensure this team has a Team Leader set). 4. Leave the…
Steps to reproduce 1. Go to Website Settings. 2. Configure the "Contact Us" form to create an Opportunity. 3. Select a "Default Sales Team" (ensure this team has a Team Leader set). 4. Leave the "Default Salesperson" field empty (None). 5. Submit the "Contact Us" form on the website. Current behavior The resulting Opportunity is automatically assigned to the Team Leader. Expected behavior The Opportunity should remain unassigned, respecting the empty "Default Salesperson" configuration. Issue In https://github.com/odoo-dev/odoo/commit/d136e79d1ea0a4793ba9d447603e6f0e29b40770, a fallback was introduced to explicitly assign the Team Leader (`team_id.user_id`) whenever a team was present but a salesperson was not, provided rule-based assignment was disabled: https://github.com/odoo/odoo/blob/d136e79d1ea0a4793ba9d447603e6f0e29b40770/addons/website_crm/models/crm_lead.py#L55-L56 This incorrectly overrides the intentional configuration in the website settings. Additionally, in https://github.com/odoo-dev/odoo/commit/ba6a5ddc8dec971f8b810dfad3d9934e7b581c91, the website_form_input_filter was made to fall back to request.website.crm_default_team_id and crm_default_user_id when the form did not submit those fields: https://github.com/odoo/odoo/blob/ba6a5ddc8dec971f8b810dfad3d9934e7b581c91/addons/website_crm/models/crm_lead.py#L14-L17 The Contact Us form already passes the configured team and salesperson as hidden inputs. When they are not configured, nothing is submitted for those fields. The fallback to request.website caused leads to be assigned a team even when neither field was intentionally configured, because crm_default_team_id defaults to the first sales team on website creation. opw-6050663 Forward-Port-Of: odoo/odoo#257134
There is a flickering when hovering the chart granularity popover. How to reproduce: - open a dashboard with a time-based chart (like the Sales dashboard) - hover it and click on the "Month" button - hover the popover with the granularity suggestions => flickering The issue seems to come from the way Chrome handles the <select> popover as the element is not recognized as a child element of the <select> parent. As such, the pseudo-class `:focus-within` does not work as intended and th
Original PR description
There is a flickering when hovering the chart granularity popover. How to reproduce: - open a dashboard with a time-based chart (like the Sales dashboard) - hover it and click on the "Month" button - hover the popover with the granularity suggestions => flickering The issue seems to come from the way Chrome handles the <select> popover as the element is not recognized as a child element of the <select> parent. As such, the pseudo-class `:focus-within` does not work as intended and the chart menu flickers between a visible/hidden state. As a fix, we rely on another pseudo-class `:open` that applies to the <select> tag, its open state being correctly handled by the browser. Task-6288876 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#274619
Description of the issue/feature this PR addresses: report_stock_quantity uses m.quantity instead of the done quantity converted to the product's base UoM when computing the forecast for done inter-warehouse moves. This causes incorrect forecast values when a done stock move uses a UoM with a factor greater than 1. Current behavior before PR: When a done inter-warehouse move uses a UoM with factor > 1 (e.g. a box of 25 units), the forecast only subtracts the raw done quantity (e.g. 2 bo
Original PR description
Description of the issue/feature this PR addresses: report_stock_quantity uses m.quantity instead of the done quantity converted to the product's base UoM when computing the forecast for done…
Description of the issue/feature this PR addresses: report_stock_quantity uses m.quantity instead of the done quantity converted to the product's base UoM when computing the forecast for done inter-warehouse moves. This causes incorrect forecast values when a done stock move uses a UoM with a factor greater than 1. Current behavior before PR: When a done inter-warehouse move uses a UoM with factor > 1 (e.g. a box of 25 units), the forecast only subtracts the raw done quantity (e.g. 2 boxes) instead of the converted quantity in the product's base UoM (e.g. 50 units). This causes the forecast chart to show incorrect negative values before the move date. Steps to reporduce: - Create a storable product with base UoM = Units - Create a UoM "Box of 25" with factor = 25 in the Units category, and add it to the product's allowed UoMs - Create a second warehouse - Do an inventory adjustment of 800 units into warehouse 1 - Create an inter-warehouse transfer of 2 "Box of 25" (= 50 units) from warehouse 1 to warehouse 2 and validate it - Open the forecast chart for the product filtered to warehouse 1 Desired behavior after PR is merged: The forecast report for done inter-warehouse moves correctly converts the done quantity to the product's base UoM using the move's UoM factor, so the forecast chart shows accurate values regardless of the UoM used on the move. opw-6266745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271766
Make sure to click on the correct action menu when tryin to delete the selected website page. If we do not specify this we could randomly click on the little gear menu that do not contain the delete option. It's actually already done like this in 19.3 here https://github.com/odoo/odoo/blob/c5d7a6a90be4730e18070826a9394ab10dfc6be8/addons/website/static/tests/tours/page_manager.js#L129 runbot-233357 Forward-Port-Of: odoo/odoo#276897
Original PR description
Make sure to click on the correct action menu when tryin to delete the selected website page. If we do not specify this we could randomly click on the little gear menu that do not contain the delete option. It's actually already done like this in 19.3 here https://github.com/odoo/odoo/blob/c5d7a6a90be4730e18070826a9394ab10dfc6be8/addons/website/static/tests/tours/page_manager.js#L129 runbot-233357 Forward-Port-Of: odoo/odoo#276897
### Issue: When sending an invoice to KSEF, the `AdresL1` field in the XML contains the country name for both buyer and seller The KSEF portal already derives the country name from `KodKraju` (country code), causing it to appear twice on portal documents ### Cause: `_display_address` uses the default PL `address_format` which includes `%(country_name)s` The format is not overridden for the FA3 XML export context, so the country name is always appended to `AdresL1` ### Steps to reproduc
Original PR description
### Issue: When sending an invoice to KSEF, the `AdresL1` field in the XML contains the country name for both buyer and seller The KSEF portal already derives the country name from `KodKraju` (country code), causing it to appear twice on portal documents ### Cause: `_display_address` uses the default PL `address_format` which includes `%(country_name)s` The format is not overridden for the FA3 XML export context, so the country name is always appended to `AdresL1` ### Steps to reproduce: - Install `l10n_pl_edi` - Configure KSEF (see video on the ticket) - Create and send an invoice to KSEF - Check `AdresL1` in the generated XML Before the fix, `AdresL1` includes the country name The KSEF portal also shows the country name twice for both buyer and seller opw-6369708 Forward-Port-Of: odoo/odoo#275922
Reverse charge taxes (Inversione Contabile) should have the translated code ending with 'IC' (the acronym), not 'CI'. Suggested by partner: eLBati task-none Forward-Port-Of: odoo/odoo#277892 Forward-Port-Of: odoo/odoo#276270
Original PR description
Reverse charge taxes (Inversione Contabile) should have the translated code ending with 'IC' (the acronym), not 'CI'. Suggested by partner: eLBati task-none Forward-Port-Of: odoo/odoo#277892 Forward-Port-Of: odoo/odoo#276270
When selling a product with the Ship Later option the COGS for the product were not recorded properly. Steps to reproduce: ------------------- * Create a product with fifo and real_time valuation * Open PoS and add the product to the order * Validate the order and set the Ship Later option * Go to the backend and validate the picking of the order * Go check the journal entries of the session > Observation: It doesn't contain the COGS line. Why the fix: ------------ Since the stock
Original PR description
When selling a product with the Ship Later option the COGS for the product were not recorded properly. Steps to reproduce: ------------------- * Create a product with fifo and real_time valuation * Open PoS and add the product to the order * Validate the order and set the Ship Later option * Go to the backend and validate the picking of the order * Go check the journal entries of the session > Observation: It doesn't contain the COGS line. Why the fix: ------------ Since the stock_valuation refactoring the COGS are not created anymore when validating the picking of the order. opw-5965021 Forward-Port-Of: odoo/odoo#259714
**PROBLEM** In some cases, third party checks are marked as being "on hand" but they are not. **CAUSE** We retrieve the last operation (accounting.payment) related to the check to determine the current journal of the check. To do this, we order the payment by date, then by write_date, and then by id. If the incoming and outgoing payment are done the same day, the last operation taken into account will be the one with the freshest write_date. If the incoming payment is modified, we wrongly c
Original PR description
**PROBLEM** In some cases, third party checks are marked as being "on hand" but they are not. **CAUSE** We retrieve the last operation (accounting.payment) related to the check to determine the current journal of the check. To do this, we order the payment by date, then by write_date, and then by id. If the incoming and outgoing payment are done the same day, the last operation taken into account will be the one with the freshest write_date. If the incoming payment is modified, we wrongly consider it as the last operation, assigning a journal to the check. **FIX** We check if there is more incoming operations than outgoing operations. If it's not the case, then the check is not on hand, so we remove the current journal. opw-6277377 Forward-Port-Of: odoo/odoo#275866
Problem: When computing inventory valuation or available quantities for a date in the past (using the context), the system calculates the past quantity by taking the current stock quants and rolling back the stock moves that occurred after the requested date. However, when the environment context specified an ownership filter (e.g., to calculate company-owned valuation), this filter was only being applied to the domain. The rollback domains for incoming and outgoing records remained comp
Original PR description
Problem: When computing inventory valuation or available quantities for a date in the past (using the context), the system calculates the past quantity by taking the current stock quants and rolling…
Problem: When computing inventory valuation or available quantities for a date in the past (using the context), the system calculates the past quantity by taking the current stock quants and rolling back the stock moves that occurred after the requested date. However, when the environment context specified an ownership filter (e.g., to calculate company-owned valuation), this filter was only being applied to the domain. The rollback domains for incoming and outgoing records remained completely open. As a result, the system would correctly see 0 company-owned current stock, but it would erroneously subtract incoming consigned stock moves from that balance. This resulted in an artificially negative past quantity and a negative inventory valuation for company-owned stock. Solution: This commit ensures the context is applied symmetrically by filtering the rollback moves via the field. The time-travel calculation will now only evaluate stock moves that match the queried ownership context. Steps to reproduce (runbot v19): - Consignment enabled - FIFO perpetual product w/ nonzero value 1. Create an inventory adjustment for an internal location, set the owner on the quant 2. Create a delivery for this product, but don't zero out all of the available stock 3. Go to Accounting > Review > Inventory Valuation, and set the At Date to something far in the past, before any move history in the db. The product's current on hand value will appear in ending stock, but negative. opw-6300582 Forward-Port-Of: odoo/odoo#270409
**Description of the issue/feature this PR addresses:** [FIX] account: prevent access error for branch users When a user restricted to a branch company opens the accounting dashboard, they may encounter an AccessError preventing the app from loading. This occurs because the dashboard logic attempts to read the `fiscalyear_lock_date` from the journal's company. In a branch setup, this configuration often belongs to the parent company, which the user typically does not have read acc
Original PR description
**Description of the issue/feature this PR addresses:** [FIX] account: prevent access error for branch users When a user restricted to a branch company opens the accounting dashboard, they may…
**Description of the issue/feature this PR addresses:** [FIX] account: prevent access error for branch users When a user restricted to a branch company opens the accounting dashboard, they may encounter an AccessError preventing the app from loading. This occurs because the dashboard logic attempts to read the `fiscalyear_lock_date` from the journal's company. In a branch setup, this configuration often belongs to the parent company, which the user typically does not have read access to. The system then blocks the action and gives an AccessError. This commit resolves the issue by adding `.sudo()` when reading the `fiscalyear_lock_date`. This safely bypasses the record rule restriction, allowing the dashboard to fetch the necessary accounting configuration without requiring the user to have broad access to the parent company. **Steps to reproduce:** - As Mitchell Admin: - Settings > Users & Companies > Companies > My Company (San Francisco) > Branches > create a branch - Settings > Users & Companies > Users > Marc Demo > Access Rights > change “Companies” and “Default Company” to only the newly created branch - As Marc Demo: - Attempt to access Accounting app > observe Access Error **Current behavior before PR:** - Users belonging to only a branch company are unable to access the Accounting dashboard **Desired behavior after PR is merged:** - Users belonging to only a branch company are able to access the Accounting dashboard opw-6369616 Forward-Port-Of: odoo/odoo#277877
Steps to reproduce ================== - Log in with the portal user (or any user without karma points). - Open a forum post. - Try to mark it as the best answer. Technical ========= From here https://github.com/odoo/odoo/pull/215145/changes/46e5ab20cb33536f0cf12d2fc3690beaa11697ee `htmlJoin` expects its first argument to be an iterable and its second argument separator to be a string. Passing the message string as the first argument causes it to be treated as an iterable of characters,
Original PR description
Steps to reproduce ================== - Log in with the portal user (or any user without karma points). - Open a forum post. - Try to mark it as the best answer. Technical ========= From here https://github.com/odoo/odoo/pull/215145/changes/46e5ab20cb33536f0cf12d2fc3690beaa11697ee `htmlJoin` expects its first argument to be an iterable and its second argument separator to be a string. Passing the message string as the first argument causes it to be treated as an iterable of characters, while the guideline markup passed as the second argument is unintentionally used as the separator. As a result, the guideline link is inserted between every character of the message instead of being appended after it. Wrap the message and the additional guideline text in an array when calling `htmlJoin` so the notification is rendered correctly. Task-6302585 Forward-Port-Of: odoo/odoo#276137
**STEP TO REPRODUCE** 1. Install l10n_fr_pdp and select the french company. 2. Go on a contact form, under invoicing, select 'by Approved Platform' for invoice sending. 3. Click on the eInvoice format selection, and notice the format 'France E-invoicing (UBL 2.1)' is not there. Note: with other invoice sending values, it shows up. **CAUSE** In the `_get_ubl_cii_formats_info()` override in `l10n_fr_pdp`, we declare the ubl_21_fr format as not being usable with the peppol invoice sending me
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_fr_pdp and select the french company. 2. Go on a contact form, under invoicing, select 'by Approved Platform' for invoice sending. 3. Click on the eInvoice format selection, and notice the format 'France E-invoicing (UBL 2.1)' is not there. Note: with other invoice sending values, it shows up. **CAUSE** In the `_get_ubl_cii_formats_info()` override in `l10n_fr_pdp`, we declare the ubl_21_fr format as not being usable with the peppol invoice sending method. However, the Approved Platform invoice sending (used to send ubl_21_fr) *is* the peppol invoice sending method in disguise. (we reused the peppol invoice sending method because pdp and peppol are very similar). opw-6387796 Forward-Port-Of: odoo/odoo#276276
It currently deleted the inner mail.message, while it should actually remove mail.mail records. Removing messages is managed at mail.mail unlink level using the 'is_notification' field. Indeed a mass_mailing email should remove the linked mail.message, while a canceled notification email should not remove the chatter message. Followup of odoo/odoo#209494 Forward-Port-Of: odoo/odoo#278321 Forward-Port-Of: odoo/odoo#277993
Original PR description
It currently deleted the inner mail.message, while it should actually remove mail.mail records. Removing messages is managed at mail.mail unlink level using the 'is_notification' field. Indeed a mass_mailing email should remove the linked mail.message, while a canceled notification email should not remove the chatter message. Followup of odoo/odoo#209494 Forward-Port-Of: odoo/odoo#278321 Forward-Port-Of: odoo/odoo#277993
**Steps to reproduce,** - log in as admin, handle notifications 'in odoo' - have a message related to a task and read it - reload the page, go to Discuss > History - find the read message mark it as unread **Current behavior before PR**, The message returned to the systray, but it lost its specific module icon and task priority. **Cause**, Since [1](https://github.com/odoo/odoo/pull/247765), inbox/systray fields are only sent when needed, but this missed the unread messages flow, s
Original PR description
**Steps to reproduce,** - log in as admin, handle notifications 'in odoo' - have a message related to a task and read it - reload the page, go to Discuss > History - find the read message mark it as unread **Current behavior before PR**, The message returned to the systray, but it lost its specific module icon and task priority. **Cause**, Since [1](https://github.com/odoo/odoo/pull/247765), inbox/systray fields are only sent when needed, but this missed the unread messages flow, so the server never sent them. **Desired behavior after PR is merged**, The message returned to the systray correctly shows the module icon and task priority. task-6188886 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Currentyl the unsupported models will be checked like the following ```sql ia.res_model NOT IN ARRAY['model1', 'model2'] ``` This causes a syntax error. Use `ANY` to avoid the issue ```sql ia.res_model != ANY(ARRAY['model1', 'model2']) ``` Reproduce in Odoo shell ```python from odoo.tools import SQL query = SQL(""" SELECT ia.id FROM ir_attachment ia WHERE ia.res_model NOT IN %(unsupported_models)s LIMIT 1; """, unsupported_models=self.env['ir.atta
Original PR description
Currentyl the unsupported models will be checked like the following
```sql
ia.res_model NOT IN ARRAY['model1', 'model2']
```
This causes a syntax error. Use `ANY` to avoid the issue
```sql
ia.res_model != ANY(ARRAY['model1', 'model2'])
```
Reproduce in Odoo shell
```python
from odoo.tools import SQL
query = SQL("""
SELECT ia.id
FROM ir_attachment ia
WHERE ia.res_model NOT IN %(unsupported_models)s
LIMIT 1;
""",
unsupported_models=self.env['ir.attachment']._get_cloud_storage_unsupported_models(),
)
```
opw-6404861
Forward-Port-Of: odoo/odoo#2779713 changes
Resolved issues and error corrections
Currentyl the unsupported models will be checked like the following ```sql ia.res_model NOT IN ARRAY['model1', 'model2'] ``` This causes a syntax error. Use `ANY` to avoid the issue ```sql ia.res_model != ANY(ARRAY['model1', 'model2']) ``` Reproduce in Odoo shell ```python from odoo.tools import SQL query = SQL(""" SELECT ia.id FROM ir_attachment ia WHERE ia.res_model NOT IN %(unsupported_models)s LIMIT 1; """, unsupported_models=self.env['ir.atta
Original PR description
Currentyl the unsupported models will be checked like the following
```sql
ia.res_model NOT IN ARRAY['model1', 'model2']
```
This causes a syntax error. Use `ANY` to avoid the issue
```sql
ia.res_model != ANY(ARRAY['model1', 'model2'])
```
Reproduce in Odoo shell
```python
from odoo.tools import SQL
query = SQL("""
SELECT ia.id
FROM ir_attachment ia
WHERE ia.res_model NOT IN %(unsupported_models)s
LIMIT 1;
""",
unsupported_models=self.env['ir.attachment']._get_cloud_storage_unsupported_models(),
)
```
opw-6404861
Forward-Port-Of: odoo/odoo#277971**STEP TO REPRODUCE** 1. Install l10n_fr_pdp and select the french company. 2. Go on a contact form, under invoicing, select 'by Approved Platform' for invoice sending. 3. Click on the eInvoice format selection, and notice the format 'France E-invoicing (UBL 2.1)' is not there. Note: with other invoice sending values, it shows up. **CAUSE** In the `_get_ubl_cii_formats_info()` override in `l10n_fr_pdp`, we declare the ubl_21_fr format as not being usable with the peppol invoice sending me
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_fr_pdp and select the french company. 2. Go on a contact form, under invoicing, select 'by Approved Platform' for invoice sending. 3. Click on the eInvoice format selection, and notice the format 'France E-invoicing (UBL 2.1)' is not there. Note: with other invoice sending values, it shows up. **CAUSE** In the `_get_ubl_cii_formats_info()` override in `l10n_fr_pdp`, we declare the ubl_21_fr format as not being usable with the peppol invoice sending method. However, the Approved Platform invoice sending (used to send ubl_21_fr) *is* the peppol invoice sending method in disguise. (we reused the peppol invoice sending method because pdp and peppol are very similar). opw-6387796 Forward-Port-Of: odoo/odoo#276276
Steps to reproduce ================== - Log in with the portal user (or any user without karma points). - Open a forum post. - Try to mark it as the best answer. Technical ========= From here https://github.com/odoo/odoo/pull/215145/changes/46e5ab20cb33536f0cf12d2fc3690beaa11697ee `htmlJoin` expects its first argument to be an iterable and its second argument separator to be a string. Passing the message string as the first argument causes it to be treated as an iterable of characters,
Original PR description
Steps to reproduce ================== - Log in with the portal user (or any user without karma points). - Open a forum post. - Try to mark it as the best answer. Technical ========= From here https://github.com/odoo/odoo/pull/215145/changes/46e5ab20cb33536f0cf12d2fc3690beaa11697ee `htmlJoin` expects its first argument to be an iterable and its second argument separator to be a string. Passing the message string as the first argument causes it to be treated as an iterable of characters, while the guideline markup passed as the second argument is unintentionally used as the separator. As a result, the guideline link is inserted between every character of the message instead of being appended after it. Wrap the message and the additional guideline text in an array when calling `htmlJoin` so the notification is rendered correctly. Task-6302585 Forward-Port-Of: odoo/odoo#276137
3 changes
Resolved issues and error corrections
backport of b07624fdae794ae129fbe31cebf7a158be8bf39e - Install l10n_it_edi - Create and confirm vendor bill - Use studio to make the field l10n_it_edi_transaction editable - Input any value - The reset to draft button disappears In _compute_show_reset_to_draft_button we hide the reset to draft button if l10n_it_edi_transaction is populated in order to filter out moves already sent to the tax agency. Normally invoices and bills sent to the SDI cannot be modified. However it is possib
Original PR description
backport of b07624fdae794ae129fbe31cebf7a158be8bf39e - Install l10n_it_edi - Create and confirm vendor bill - Use studio to make the field l10n_it_edi_transaction editable - Input any value - The reset to draft button disappears In _compute_show_reset_to_draft_button we hide the reset to draft button if l10n_it_edi_transaction is populated in order to filter out moves already sent to the tax agency. Normally invoices and bills sent to the SDI cannot be modified. However it is possible to import vendor bills from the SDI, and their transaction field is also imported. It should be possible to modified those imported invoices. opw-6385498 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277994
**STEP TO REPRODUCE** 1. Install l10n_fr_pdp and select the french company. 2. Go on a contact form, under invoicing, select 'by Approved Platform' for invoice sending. 3. Click on the eInvoice format selection, and notice the format 'France E-invoicing (UBL 2.1)' is not there. Note: with other invoice sending values, it shows up. **CAUSE** In the `_get_ubl_cii_formats_info()` override in `l10n_fr_pdp`, we declare the ubl_21_fr format as not being usable with the peppol invoice sending me
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_fr_pdp and select the french company. 2. Go on a contact form, under invoicing, select 'by Approved Platform' for invoice sending. 3. Click on the eInvoice format selection, and notice the format 'France E-invoicing (UBL 2.1)' is not there. Note: with other invoice sending values, it shows up. **CAUSE** In the `_get_ubl_cii_formats_info()` override in `l10n_fr_pdp`, we declare the ubl_21_fr format as not being usable with the peppol invoice sending method. However, the Approved Platform invoice sending (used to send ubl_21_fr) *is* the peppol invoice sending method in disguise. (we reused the peppol invoice sending method because pdp and peppol are very similar). opw-6387796 Forward-Port-Of: odoo/odoo#276276
In Discuss, clicking a livechat chatbot member from the member list can lead to a traceback because the avatar card is opened with member.persona.userId, while chatbot operators can be partner-only records with no related user. This happens when the bot member is not filtered out as is_bot, notably in the chatbot script test flow where the channel has no livechat_channel_id. We cannot simply block on a missing member.persona.userId: the user relation may exist but not be fetched yet. In
Original PR description
In Discuss, clicking a livechat chatbot member from the member list can lead to a traceback because the avatar card is opened with member.persona.userId, while chatbot operators can be partner-only records with no related user. This happens when the bot member is not filtered out as is_bot, notably in the chatbot script test flow where the channel has no livechat_channel_id. We cannot simply block on a missing member.persona.userId: the user relation may exist but not be fetched yet. In the is commit we resolve the partner through mail.store.getPartner() before opening the avatar card, so valid users are fetched lazily and true partner-only records are ignored. task-4642940 Forward-Port-Of: odoo/odoo#275284
2 changes
Enhancements to existing features
Comply with new provincial fiscal transparency regulations (CABA, Entre Ríos, Chubut, and other provinces still not defined) that mandate detailing Perception IIBB taxes on B2C invoices (Factura/Invoice B): - Some jurisdictions mandate a new description for IIBB perception taxes on the invoice, - We need to put the IIBB perception taxes in the special "Fiscal Transparency Regime" table, and exclude them from the standard tax table, task-6367087
Original PR description
Comply with new provincial fiscal transparency regulations (CABA, Entre Ríos, Chubut, and other provinces still not defined) that mandate detailing Perception IIBB taxes on B2C invoices (Factura/Invoice B): - Some jurisdictions mandate a new description for IIBB perception taxes on the invoice, - We need to put the IIBB perception taxes in the special "Fiscal Transparency Regime" table, and exclude them from the standard tax table, task-6367087
Resolved issues and error corrections
backport of b07624fdae794ae129fbe31cebf7a158be8bf39e - Install l10n_it_edi - Create and confirm vendor bill - Use studio to make the field l10n_it_edi_transaction editable - Input any value - The reset to draft button disappears In _compute_show_reset_to_draft_button we hide the reset to draft button if l10n_it_edi_transaction is populated in order to filter out moves already sent to the tax agency. Normally invoices and bills sent to the SDI cannot be modified. However it is possib
Original PR description
backport of b07624fdae794ae129fbe31cebf7a158be8bf39e - Install l10n_it_edi - Create and confirm vendor bill - Use studio to make the field l10n_it_edi_transaction editable - Input any value - The reset to draft button disappears In _compute_show_reset_to_draft_button we hide the reset to draft button if l10n_it_edi_transaction is populated in order to filter out moves already sent to the tax agency. Normally invoices and bills sent to the SDI cannot be modified. However it is possible to import vendor bills from the SDI, and their transaction field is also imported. It should be possible to modified those imported invoices. opw-6385498 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277994