Odoo Changelog — 2024-08-09

Friday, August 9, 2024

34 changes · saas-17.4

Bug Fixes(4)

Resolved issues and error corrections

[FIX] mail: selecting an emoji should trigger notifyIsTyping

Coresaas-17.4mail

Selecting an emoji in a new chat now properly marks the sender as active, so sending an emoji-only message adds them to the conversation. This prevents missed membership updates and makes chat behavior more reliable for users.

Original PR description

Purpose of the commit:
Previously, when a new channel was created, sending an emoji as a message did not add the sender as a member. This was because selecting an emoji did not trigger the `notifyIsTyping`. To address this issue, `notifyIsTyping` is now triggered when an emoji is selected in the composer.

task-4100450

#chat#emoji#messaging

[FIX] l10n_de: fix singleton error on multiple attachments unlink

PR #176140

Coresaas-17.4l10n_de

This update prevents an error when users delete several PDF attachments linked to German invoices at the same time. It keeps attachment cleanup working reliably for German accounting records without changing normal invoicing behavior.

Original PR description

To reproduce (on runbot w/ demo datas) - Install l10n_de - Switch to "DE Company" - Create an invoice and add 2 or more PDF documents - Switch to debug mode - Go to menu: Settings / Technical /…

To reproduce (on runbot w/ demo datas)

- Install l10n_de
- Switch to "DE Company"
- Create an invoice and add 2 or more PDF documents
- Switch to debug mode
- Go to menu: Settings / Technical / Database Structure / Attachments
- Search for the added documents, select them all and try to delete them

=> This raise the following error:

```
Traceback (most recent call last):
  File "/data/build/odoo/odoo/models.py", line 5961, in ensure_one
    _id, = self._ids
    ^^^^
ValueError: too many values to unpack (expected 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  ..
  File "/data/build/odoo/odoo/addons/base/models/ir_attachment.py", line 610, in unlink
    res = super(IrAttachment, self).unlink()
  File "/data/build/odoo/odoo/models.py", line 4326, in unlink
    func(self)
  File "/data/build/odoo/addons/l10n_de/models/ir_attachment.py", line 25, in _except_audit_trail
    if move and move.posted_before and move.country_code == 'DE':
                ^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/fields.py", line 1204, in __get__
    record.ensure_one()
  File "/data/build/odoo/odoo/models.py", line 5964, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move(347, 347)
```

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[FIX] mail: flicker when expanding direct messages in sidebar

PR #176114

Coresaas-17.4mail

The Discuss sidebar now keeps the "Direct Messages" title steady when users expand or collapse the section. This removes a small visual distraction and makes navigation feel smoother.

Original PR description

**Current behavior before PR:**

The title "Direct Messages" in the discuss sidebar used to flicker (move up and down) when expanding or folding the section.

**Desired behavior after PR is merged:**

The flickering issue is fixed, so now the title "Direct Messages" remains in place when the section is expanded or folded.

**task**:4100682

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#discuss#sidebar#direct messages#user experience

[FIX] hr_attendance_gantt: non deterministic test (2)

PR #68143

Enterprisesaas-17.4hr_attendance_gantt

This update stabilizes automated checks for the Attendance Gantt view by preventing unrelated messaging timers from affecting test results. It helps reduce false test failures and improves confidence in future attendance planning changes, without changing user-facing functionality.

Original PR description

In AttendanceGanttModel, open ended records have their dateStopField set to the current moment. So, depending on the way time passes, the gantt pills can have different ending columns. In the…

In AttendanceGanttModel, open ended records have their dateStopField set
to the current moment. So, depending on the way time passes, the gantt
pills can have different ending columns.
In the hr_attendance_gantt tests, we use the hoot helper runAllTimers
that accelerates time based on the registered timeouts. Since https://github.com/odoo/odoo/pull/175422,
the service imStatusService registers timeouts with delay of 30 minutes.
So runAllTimers often needs to advance time by steps of 30 minutes,
sometimes more nondeterministically. This means that sometimes time has
to advance more than 1 hours and this make some assertions on the pill
ending columns fail.

Here similarly to what is done in https://github.com/odoo/enterprise/pull/67088,
we remove some services/main components only used by mail, so that
imStatusService is no longer there and does no longer interfer with ours
tests.

We also take the oportunity to replace some calls to selectGanttRange
by some clicks on the previous/next buttons. In that way, the intention
behind the tests is clearer and time has to advance a bit less.
This also corrects the wrong fix https://github.com/odoo/enterprise/pull/68033.

Build 66645450

Other(30)

Miscellaneous changes

[FW][FIX] payment: retry post processing for Integrity Errors

PR #176174

Coresaas-17.4payment

Original PR description

In some rare cases, the payment status poll can enter the post-processing of a given transaction and conflict with the post-processing triggered by a webhook notification, for the same transaction.

If the transaction is linked to a sale.order, both transactions will try to add the partner as follower during the post-processing, leading to a violation of the unique constraint ensuring that two mail.followers rows won't target the same record and partner.

psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "mail_followers_mail_followers_res_partner_res_model_id_uniq"
DETAIL: Key (res_model, res_id, partner_id)=(sale.order, 20205, 94178) already exists.

This commit makes sure that this kind of psycopg exceptions are caught and retried so that this kind of error is not shown to the user and the polling is successfully triggered a second time.

opw-4000159

Forward-Port-Of: odoo/odoo#175836

Purpose of the commit: Previously, when a new channel was created, sending an emoji as a message did not add the sender as a member. This was because selecting an emoji did not trigger the `notifyIsTyping`. To address this issue, `notifyIsTyping` is now triggered when an emoji is selected in the composer. task-4100450

To reproduce (on runbot w/ demo datas) - Install l10n_de - Switch to "DE Company" - Create an invoice and add 2 or more PDF documents - Switch to debug mode - Go to menu: Settings / Technical / Database Structure / Attachments - Search for the added documents, select them all and try to delete them => This raise the following error: ``` Traceback (most recent call last): File "/data/build/odoo/odoo/models.py", line 5961, in ensure_one _id, = self._ids ^^^^ ValueError: too many values to unpack (expected 1) During handling of the above exception, another exception occurred: Traceback (most recent call last): .. File "/data/build/odoo/odoo/addons/base/models/ir_attachment.py", line 610, in unlink res = super(IrAttachment, self).unlink() File "/data/build/odoo/odoo/models.py", line 4326, in unlink func(self) File "/data/build/odoo/addons/l10n_de/models/ir_attachment.py", line 25, in _except_audit_trail if move and move.posted_before and move.country_code == 'DE': ^^^^^^^^^^^^^^^^^^ File "/data/build/odoo/odoo/fields.py", line 1204, in __get__ record.ensure_one() File "/data/build/odoo/odoo/models.py", line 5964, in ensure_one raise ValueError("Expected singleton: %s" % self) ValueError: Expected singleton: account.move(347, 347) ``` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Current behavior before PR:** The title "Direct Messages" in the discuss sidebar used to flicker (move up and down) when expanding or folding the section. **Desired behavior after PR is merged:** The flickering issue is fixed, so now the title "Direct Messages" remains in place when the section is expanded or folded. **task**:4100682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

In AttendanceGanttModel, open ended records have their dateStopField set to the current moment. So, depending on the way time passes, the gantt pills can have different ending columns. In the hr_attendance_gantt tests, we use the hoot helper runAllTimers that accelerates time based on the registered timeouts. Since https://github.com/odoo/odoo/pull/175422, the service imStatusService registers timeouts with delay of 30 minutes. So runAllTimers often needs to advance time by steps of 30 minutes, sometimes more nondeterministically. This means that sometimes time has to advance more than 1 hours and this make some assertions on the pill ending columns fail. Here similarly to what is done in https://github.com/odoo/enterprise/pull/67088, we remove some services/main components only used by mail, so that imStatusService is no longer there and does no longer interfer with ours tests. We also take the oportunity to replace some calls to selectGanttRange by some clicks on the previous/next buttons. In that way, the intention behind the tests is clearer and time has to advance a bit less. This also corrects the wrong fix https://github.com/odoo/enterprise/pull/68033. Build 66645450

In some rare cases, the payment status poll can enter the post-processing of a given transaction and conflict with the post-processing triggered by a webhook notification, for the same transaction. If the transaction is linked to a sale.order, both transactions will try to add the partner as follower during the post-processing, leading to a violation of the unique constraint ensuring that two mail.followers rows won't target the same record and partner. psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "mail_followers_mail_followers_res_partner_res_model_id_uniq" DETAIL: Key (res_model, res_id, partner_id)=(sale.order, 20205, 94178) already exists. This commit makes sure that this kind of psycopg exceptions are caught and retried so that this kind of error is not shown to the user and the polling is successfully triggered a second time. opw-4000159 Forward-Port-Of: odoo/odoo#175836

Steps to reproduce ================== As Admin: - Install project - Go to project - Click on the three dots on a project card - Select "Share" - Copy the link - Select the edit mode - Add "Joel Willis" to the recipients - Click on "Send" As portal in another browser (or in private navigation) - Paste the link - Type some random characters in the search bar so that no records are matched - remove the current filter => Every single column is displayed, for example `<field name="sequence" readonly="1" column_invisible="True"/>` As Admin: - Go to the shared project settings - Disable the "Milestones" checkbox As portal: - Refresh the page => The milestone column is still displayed Cause of the issue ================== The difference between invisible and column_invisible is that `invisible` is meant to hide a cell in a row and is evaluated with the record data (`record.evalContextWithVirtualIds`). `column_invisible` is meant to remove a column completely for the list, but is is not evaluated with the record. It only uses the context and a few more keys (`this.model.root.evalContext`). It is thus not possible to hide an entire column depending on record values. It makes sense as the values could be different for every record displayed. In this case though, there are a few fields that have the same values for every record. They are in fact related fields, declared on the project. Those fields are - allow_milestones - allow_timesheets The [ProjectSharingListRenderer] has been created to hide some columns from being displayed when a feature is disabled on the project displayed. It works by evaluating the column_invisible with the first record. If there are no records, we skip any column_invisible processing, When calling `setColumns` from `onWillUpdateProps`, we use `nextProps` for the columns, but still `this.props` to get the first record. This means that we use an outdated first record, and this is why every column is displayed after removing the filter. Another issue is that During [View-Pocalypse], In 16.0, the milestone_id field was ```xml <field name="milestone_id" attrs="{'column_invisible': [('allow_milestones', '=', False)]}"/> ``` In 17.0, it is ```xml <field name="milestone_id" invisible="not allow_milestones" context="{'default_project_id': project_id}" groups="project.group_project_milestone" optional="hide"/> ``` Solution ======== As there are some limitations to the js approach (when no records are in the list for example) and there is already a context key for the [allow_timesheets], we use a simpler approach to add the missing keys. Finally, we put back the column_invisible attributes --- [ProjectSharingListRenderer]: https://github.com/odoo/odoo/commit/ab2b5d1fd1f09d804ab410bc326cfebf26d5a7c6 [View-Pocalypse]: https://github.com/odoo/odoo/pull/104741 [allow_timesheets]: https://github.com/odoo/odoo/blob/d2a428c07fd728691e3ddd60fe4b7cc5e94455a6/addons/hr_timesheet/models/project_project.py#L290 opw-4015035 Forward-Port-Of: odoo/odoo#175906 Forward-Port-Of: odoo/odoo#172645

This commit fixes an issue regarding down-payment calculation. ZATCA defines one rule to govern the way prepaid amounts (down-payment) is calculated, where PrepaidAmount = SUM([LINE.TaxableAmount + LINE.TaxAmount for LINE in invoice.invoice_line_ids]), obviously this poses a problem when we have a mix of down-payment and normal lines on our invoice since the formula does not differentiate between those. To fix this, we make sure that only down-payment lines actually include a Tax Subtotal breakdown (TaxableAmount & TaxAmount) Description of the issue/feature this PR addresses: PrepaidAmount value in invoice XML, representing down-payment amounts, is Wrong, both on the XML and QR code associated, even though ZATCA returns a Valid submission status Current behavior before PR: PrepaidAmount value in invoice XML, representing down-payment amounts, is Wrong, both on the XML and QR code associated, even though ZATCA returns a Valid submission status Desired behavior after PR is merged: PrepaidAMount is calculated correctly on the XML invoice submitted to ZATCA and also represented correctly on the QR code --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174960

Due to the `qty_to_order` field on `stock.orderpoint` being a stored computed field, it needs to be recalculated every time one or more of its dependencies could have changed, to keep a consistent record in the database. It is, however, dependent on the `qty_forecast` field which is a non-stored computed field, depending itself on all the stock moves that are linked to the product set on the orderpoint. This results in a complete recalculation of the `qty_on_hand`, `qty_forecast` and `qty_to_order` on ALL the orderpoints linked to a product every time some `stock.move` has been touched or created with that product. Even if many of those orderpoints may not even be located in the concerned warehouse. This situation can create a performance bottleneck when just processing pickings, as its constantly (and often pointlessly) recalculating these field values to store. This becomes a major issue in case the concerned database contains many warehouses with many different orderpoints. This issue is remedied in a more permanent way for master in [1], but due to the stable policy we use a different approach here: The `qty_to_order` field on `stock.orderpoint` is now no longer dependent on `qty_forecast`. Instead, when creating `stock.moves` or writing on its `state`, `product_uom_qty` or `date` fields, we manually trigger a recalculation of the `qty_to_order` on all the orderpoints on the relevant product, but only in the relevant warehouses. In case there is no relevant warehouse for the `stock.move` (none on the source or destination move), we fall back to the previous behavior of recalculating `qty_to_order` for all orderpoints linked to the product. [1] https://github.com/odoo/odoo/pull/159432 task-3822497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176073 Forward-Port-Of: odoo/odoo#164300

**Current behavior:** There are several related bugs when operating in a multi-company environment with the barcode app: *Given:* we have three companies in the selector (A, B, C) where company A is the first/default/primary of the three. ***Case 1: (CompanyB and CompanyC are checked, either can be focused)*** 1) Scanning the barcode for CompanyC's manufacturing operation and then, within the barcode view, scanning a product which belongs exclusively to CompanyB will make it impossible to use the back button (despite the product correctly not being added as a line in the operation). 2) Repeating the setup with a different operation type (e.g., receipt) *will* add the product to the picking but it will not be possible to validate/take out of draft from either the barcode app nor from the backend. ***Case 2: (only CompanyC checked and focused)*** 1) Scanning the barcode for CompanyC's manufacturing operation type will open the barcode operation view for CompanyA's manufacture operation. Products available to CompanyC can be added. Trying to validate the order will cause an access error, however the MO is still created in the backend. 2) Scanning the barcode for either CompanyB or CompanyA's non-manufacturing operations will show an access error dialog, but an (empty) transfer will still be created in the backend for the respective company. --- **Expected behavior:** In case 1, scanning a product which is not available to the current company should not trap the user in the barcode operation view. It should also not add these inaccessible products to a picking thereby making them unable to be validated. In case 2, we should respect the company defined on a manufacturing operation type which corresponds to a scanned barcode. Additionally, it should not be possible to create empty transfers for companies which are not currently checked/active. --- **Cause of the issue:** Problem 1: production records (unlike pickings) cannot be created until a product is added in the barcode view. Because of this different flow, they are created with less context than other operation types and there was no mechanism by which their `company_id` could be inferred. This caused them to use the default value as defined in the `MrpProduction` model (`self.env.company`)- which is problematic in the barcode app, as this field does not actually correspond to the focused/active company. Problem 2: when scanning a picking type from the main menu of the barcode app, the company of the picking type was not getting respected which would cause a new picking record to be created even when the current user/environment did not have permission. --- **Fix:** 1. Create production records using a default `company_id` value informed by their `picking_type_id` rather than the environment 2. In the main_menu barcode scan route, use the current user's allowed company ids (from their cookies) to restrict searchable records 3. When scanning products in a barcode operation view, use the company_id of the opened operation type to restrict the domain of searchable records. opw-3999622 Forward-Port-Of: odoo/enterprise#67134 Forward-Port-Of: odoo/enterprise#65433

Bug Fixes(4)

[FIX] mail: selecting an emoji should trigger notifyIsTyping

[FIX] l10n_de: fix singleton error on multiple attachments unlink

[FIX] mail: flicker when expanding direct messages in sidebar

[FIX] hr_attendance_gantt: non deterministic test (2)

Other(30)

[FW][FIX] payment: retry post processing for Integrity Errors

Bug Fixes(4)

[FIX] mail: selecting an emoji should trigger notifyIsTyping

[FIX] l10n_de: fix singleton error on multiple attachments unlink

[FIX] mail: flicker when expanding direct messages in sidebar

[FIX] hr_attendance_gantt: non deterministic test (2)

Other(30)

[FW][FIX] payment: retry post processing for Integrity Errors

[FW][FIX] project_account: rename other costs section to avoid conflict

[FW][FIX] l10n_in_ewaybill_stock: fix traceback on generating ewaybill

[FW][FIX] project: always evaluate column_invisible in action_project_sharing

[FW] FIX] web: infinity error loop when errors on multiple actions in the URL

[FW][FIX] bus: do not check outdated version for non browsers

[FW][FIX] l10n_sa_edi: fix down-payment value calculations

[FW][FIX] web_editor: restore single quote escaping in _compute_image_src

[FW][FIX] website: fix logo resizing and fixed header

[FW][FIX] pos_sale: correctly unreserve sale order before reserving pos line

[FW][FIX] pos_self_order: make sure default_user is set when needed

[FW][FIX] point_of_sale: use correct fp for taxed list price computation

[FW][FIX] pos_sale: Handle special characters in partner name search

[FW][FIX] point_of_sale: discount not applied to group taxes

[FW][FIX] account: move validate context

[FW][FIX] mail, hr_holidays: channel members categorise correctly

[FW][FIX] web: control panel sticky on small screen

[FW][FIX] point_of_sale,pos_loyalty: apply taxes on gift card rewards

[FW][PERF] stock: only recompute orderpoint quantities for relevant WH

[FW][FIX] l10n_in_pos: hsn doesn't displayed on reciept

[FW][FIX] l10n_fi: wrong invoice label for new 25.5% tax

[FW][IMP] l10n_nl_reports: Adjustable XAF docRef len

[FW][FIX] industry_fsm_sale: add allow_billable to portal project context

[FW][FIX] l10n_mx_{edi,reports}: xml declaration

[FW][FIX] sale_amazon: better error message if location missing info

[FW][FIX] l10n_ec_reports_ats: Misc fixes ATS

[FW][FIX] l10n_ar_edi: remove `PKCS7_sign` usage

[FW][FIX] industry_fsm_stock: create SML from correct child location

[FW][FIX] stock_barcode{,_mrp}: respect operation cid

[FW][FIX] appointment: fix traceback when user gives existing email in guest email