Daily updates from Odoo
Wednesday, July 31, 2024
15 changes · master
Enhancements to existing features
Subscription tax estimates now use the current date instead of the original order date when checking taxes with Avalara. This helps portal totals reflect current tax rules or exemption changes, so customers see amounts closer to what they will actually be charged.
Original PR description
By default, we send date_order to Avatax when asking to calculate taxes. Avatax calculates the right taxes for that point in time. For non-recurring orders this is ok, but subscriptions are paid multiple times and date_order will remain the confirmation date of the subscription. This leads to confusion as taxes change over time (e.g. tax laws change or an exemption certificate is added with an effective date after date_order). Because customers are charged based on invoices we always charge them correctly, but the subscription total may not match what they're being charged. To solve this, always send the current date for subscriptions. This way customers can accurately see what they'll be charged in the portal. task-4078473
This update prevents certain background notifications from being triggered multiple times after a reset, reducing unnecessary processing. It helps improve reliability and efficiency across messaging, spreadsheet documents, live chat helpdesk, and WhatsApp-related flows without changing user-facing features.
Original PR description
\* = documents_spreadsheet, whatsapp Enterprise counter-part. After a reset, the last id is always 0. https://github.com/odoo/odoo/pull/174874
Payment method configuration now uses a clearer “none” value for refund support instead of the confusing “empty” label. This makes refund capabilities easier for users and administrators to understand when configuring online sales payments.
Original PR description
-> This commit improves the clarity and usability of the payment method configurations, specifically focusing on refund options. Before this commit: -> The type of refund supported was 'empty' which led to confusion. After this commit: -> Replace the support_refund field to 'none' from 'empty' which make more intuitive for users. Check the community PR for more details. task-3974054 See also: - https://github.com/odoo/odoo/pull/169473 - https://github.com/odoo/upgrade/pull/6162
Knowledge hierarchy views are now loaded only when needed, reducing initial loading work. This should make the Knowledge app feel more responsive while preserving the same user-facing functionality.
Original PR description
We make the hierarchy view and its extensions to be lazy loaded. Task ID: `3546321`
The Discuss app now shows who is currently in an active call directly in the sidebar, including each participant's call status such as speaking, muted, or deafened. This makes it easier for users to understand call activity at a glance without opening additional views.
Original PR description
This commit provides the Call Participants in the sidebar of the Discuss app. When a call is active, the sidebar will show the participants of the call, as well as the status of the participants (e.g. isTalking, isMuted, isDeafened). https://github.com/odoo/odoo/pull/174965
Point of Sale users now receive a confirmation when WhatsApp or email marketing actions are successfully sent. They can also launch standalone marketing directly from a PoS order, making customer outreach clearer and easier to manage.
Original PR description
Before this commit: ========== - There is no confirmation notification while using WhatsApp and Email marketing. - Also, there is no option for standalone marketing from the PoS order form view. After this commit: ========== - Confirmation notification appears after successfully triggering WhatsApp and Email marketing. - Now, we have an option for standalone marketing from the PoS order form view. task-4037963
Resolved issues and error corrections
A recent merge introduced a conflict that prevented the tax report from opening. This fix removes the outdated logic and calculates the taxable amount directly, restoring access for users who rely on tax reporting.
Original PR description
Two commit have been merged together causing a conflict on a function not present anymore `_prepare_dict_for_taxes_computation`. The fix is to remove that old function and compute the tax applied amount directly conflicting pr's: - https://github.com/odoo/enterprise/commit/29e30f5d941f2c9989833237dd7aade29e00a4c2 - https://github.com/odoo/odoo/commit/cd76aec1f722d32d2bc6c1a13ef73296ce00ecc5 task-4086928
This fixes an internal guided tour used in the Documents Accounting area after a related setting name changed. It helps keep automated checks and user guidance reliable, reducing the chance of broken onboarding or validation issues.
Original PR description
From https://github.com/odoo/odoo/pull/174548, tooltip has been renamed in tooltipPosition. This conversion for this tour has been missed. In https://github.com/odoo/odoo/pull/171756, the step schema is validated when a tour is added to the registry. This is why this bug was detected. task~3974087
Miscellaneous changes
## Before this commit: The schedule date is converted into a string in SQL and then parsed in Python using `Datetime.to_string`. However, it does not support parsing datetime with trailing milliseconds, such as '2024-05-22 10:09:45.5'. ## After this commit: Do not convert the schedule date to a string but put it in a PostgreSQL Array instead. Psycopg2 will convert it into a datetime object automatically, similar to the ORM's behaviour. opw-3932891 Forward-Port-Of: odoo/enterprise#67593
Original PR description
## Before this commit: The schedule date is converted into a string in SQL and then parsed in Python using `Datetime.to_string`. However, it does not support parsing datetime with trailing milliseconds, such as '2024-05-22 10:09:45.5'. ## After this commit: Do not convert the schedule date to a string but put it in a PostgreSQL Array instead. Psycopg2 will convert it into a datetime object automatically, similar to the ORM's behaviour. opw-3932891 Forward-Port-Of: odoo/enterprise#67593 Forward-Port-Of: odoo/enterprise#63065
When switching a bank journal to the new SEPA Pain version, existing payments in the batch may lack required data, such as the UETR field. ### Steps to Reproduce 1. Install `l10n_be`, `account_accountant`, and `account_sepa_pain_001_001_09`. 2. In the settings, enable 'SEPA Credit Transfer (SCT)'. 3. Switch to a Belgian company. 4. Set up an IBAN bank account on the bank journal. 5. Ensure a partner has an IBAN bank account defined. 6. Create and confirm an outgoing payment for that p
Original PR description
When switching a bank journal to the new SEPA Pain version, existing payments in the batch may lack required data, such as the UETR field. ### Steps to Reproduce 1. Install `l10n_be`,…
When switching a bank journal to the new SEPA Pain version, existing payments in the batch may lack required data, such as the UETR field. ### Steps to Reproduce 1. Install `l10n_be`, `account_accountant`, and `account_sepa_pain_001_001_09`. 2. In the settings, enable 'SEPA Credit Transfer (SCT)'. 3. Switch to a Belgian company. 4. Set up an IBAN bank account on the bank journal. 5. Ensure a partner has an IBAN bank account defined. 6. Create and confirm an outgoing payment for that partner, setting the payment method to 'SEPA Credit Transfer'. 7. In the Outgoing Payments tab of the bank journal, set the SEPA Pain Version to 'New generic version'. 8. Create a batch payment with the payment you just created. 9. Attempt to validate it. ### Expected Result The payment should be validated successfully. ### Actual Result A traceback occurs: `TypeError: Argument must be bytes or unicode, got 'bool'` ### Cause The payment in the batch was created before the SEPA PAIN version was updated on the bank journal. Consequently, the payment is missing some necessary data (specifically, the UETR field is not set) required for the new SEPA version. opw-3973374 Forward-Port-Of: odoo/enterprise#67665 Forward-Port-Of: odoo/enterprise#65614
When having multiple companies selected and that their tax id are not the same, then we put a banner on top of the tax report to warn the user that the companies selected don't have the same tax id. task: 3909005 Forward-Port-Of: odoo/enterprise#67576 Forward-Port-Of: odoo/enterprise#63275
Original PR description
When having multiple companies selected and that their tax id are not the same, then we put a banner on top of the tax report to warn the user that the companies selected don't have the same tax id. task: 3909005 Forward-Port-Of: odoo/enterprise#67576 Forward-Port-Of: odoo/enterprise#63275
The amount to settle was not shown in the tree view for the older column due to the [domain prepared](https://github.com/odoo/enterprise/blob/17.0/account_reports/models/account_aged_partner_balance.py#L380-L392) for the older column being capped between 30 days, similar to the other columns(1-30, 31-60, etc.) in the Aged Receivable report. **Step to reproduce:** - create an invoice with due date 150 days back - open the Aged receivable report and find that invoice - The record of `acco
Original PR description
The amount to settle was not shown in the tree view for the older column due to the [domain…
The amount to settle was not shown in the tree view for the older column due to the [domain prepared](https://github.com/odoo/enterprise/blob/17.0/account_reports/models/account_aged_partner_balance.py#L380-L392) for the older column being capped between 30 days, similar to the other columns(1-30, 31-60, etc.) in the Aged Receivable report. **Step to reproduce:** - create an invoice with due date 150 days back - open the Aged receivable report and find that invoice - The record of `account.move.line` will not be shown in the tree view (Amount to settle) This patch handle the domain for `period5`. **Before fix:**   **After fix:**  OPW - 4048535 Forward-Port-Of: odoo/enterprise#66884
Before this commit, the 'no content' message was showing in the entire display, taking the employee panel account. Now, it is fixed, the message just stay at the disabled workorders, and when the screen is less than md, the message is hidded. Previous PR: https://github.com/odoo/enterprise/pull/62997 ### Before  ### After  ### After  task: 3794286 Forward-Port-Of: odoo/enterprise#64435
Before this commit, when posting a manually modified closing entry, the entire move would be refreshed, and all user-modified information would be erased. This occurred because, when accessing the action_periodic_vat_entries, the current tax closing move was overwritten. This commit changes this behavior by adding a flag to the method, indicating whether it is called from the _close_tax_period function. If so, it only updates moves that are different from the tax closing of the current compan
Original PR description
Before this commit, when posting a manually modified closing entry, the entire move would be refreshed, and all user-modified information would be erased. This occurred because, when accessing the action_periodic_vat_entries, the current tax closing move was overwritten. This commit changes this behavior by adding a flag to the method, indicating whether it is called from the _close_tax_period function. If so, it only updates moves that are different from the tax closing of the current company. Additionally, when selecting only one company within a tax unit, it sometimes happened that, when closing the main company, the dependent closings to post (depending_closings_to_post) were empty because the moves were not generated yet for the other companies. Task: 3987807 Forward-Port-Of: odoo/enterprise#67299 Forward-Port-Of: odoo/enterprise#65645
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this product, with at least 2 quantities and confirm it; > - Create a second similar receipt (you can duplicate the first one) and confirm it; > - Add these two receipt in a new batch and confirm the batch; > - Go in the Barcode App and open the batch, you should have two lines, one for each picking; >
Original PR description
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this…
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this product, with at least 2 quantities and confirm it; > - Create a second similar receipt (you can duplicate the first one) and confirm it; > - Add these two receipt in a new batch and confirm the batch; > - Go in the Barcode App and open the batch, you should have two lines, one for each picking; > - Scan the product -> the first line should be selected; > - Scan a lot -> the lot is set on the first line and its qty is incremented; > - Scan another lot -> the lot is set on the second line and its qty is incremented. That's the issue. > > Expected behavior: When another lot is scanned after the first one, since we are picking quantity for the first picking, the line for the second picking shouldn't be selected until the first one is processed. To fix that, the search for a line following the scan will avoid to take a tracked line if its `picking_id` is not the same than the selected line and if the selected line is not completed. **[FIX] stock_barcode: increment right qty** > When a product tracked by lots is reserved and multiple lots are reserved, in the Barcode App, each line has a "+ qty" button where the quantity is the remaining quantity. That said, this remaining quantity was always computed regarding the difference between the move line's done and reserved quantity which means if the user scans a not reserved lot, those buttons aren't reliable anymore. > > How to reproduce: > - Create a product tracked by lots and set a barcode; > - Update the quantity on hand for this product like following: > - 3x lot1 > - 3x lot2 > - 3x lot3 > - Create a delivery for 6x this product and confirm it; > - Open the delivery in the Barcode App, unfold the line for the tracked product, you should have: > - 0/3 lot1, [+3] > - 0/3 lot2, [+3] > - Scan lot1 one time and lot3 three times, you now have: > - 3 lot3, [+1] > - 1/3 lot1, [+2] > - 0/3 lot2, [+3] > -> Since the total demand is 6 and 4 quantities have been processed, no button should display a quantity greater than 2 since it's the remaining quantity. > > To fix that, the quantity used by the increment button is also computed regarding the parent line's quantity. task-3688770 Forward-Port-Of: odoo/enterprise#67479 Forward-Port-Of: odoo/enterprise#54589