Daily updates from Odoo
Thursday, January 9, 2025
44 changes · 18.0
Enhancements to existing features
The mass production wizard now creates follow-up manufacturing orders in a clearer confirmed state with serial numbers already assigned. This improves traceability for partially produced items and helps avoid unintended component consumption.
Original PR description
In this commit: ==================== - The changes ensure better traceability by generating back-orders in a 'confirmed" state with serial numbers assigned, preventing unintended consumption of components. This approach enhances clarity and aligns with user expectations for managing partial production. task-4280758
Manufacturing users can now prepare back-orders from the Produce All action for final products tracked by serial number. This reduces workflow interruptions by avoiding unnecessary blocking from quality instructions tied to work orders.
Original PR description
In this commit: ==================== - Adjusted the workflow to enable users to prepare manufacturing orders (MOs) for back-orders when clicking 'Produce All' for final products linked with serial numbers (SN), without blocking for quality checks when instructions are associated with any work order. task-4280758
Subscription invoice payment processing now uses a lighter database lock to avoid blocking related updates unnecessarily. This reduces the risk of deadlocks during automated subscription billing, improving reliability without changing user-facing workflows.
Original PR description
Before this commit, the transaction row was locked when payment was performed in the subscription invoice cron. Using `SELECT FOR UPDATE` locks the entire row, primary key included (id in our case). As a result, it could prevent insertion or update or other table refering to the id too. As it is not necessary and could trigger unnecessary deadlock, it is better to rely on `SELECT FOR NO KEY UPDATE` which allow the update of foreign keys. https://www.postgresql.org/docs/16/explicit-locking.html#LOCKING-ROWS See https://github.com/odoo/enterprise/pull/74078#discussion_r1873729342 taskid: 4391755
Resolved issues and error corrections
Discuss call notifications are now only sent while a call is active. This prevents stray peer-to-peer notifications after a call has ended, reducing confusing or unnecessary communication behavior for users.
Original PR description
Before this commit, a race condition could allow attempts to send peer notification to go through despite not having a call. This could happen if a `_busNotify()` call follows a promise that is resolved after the end of a call. This commit fixes this issue by ensuring that notifications can only be sent when a call is active.
Fixes a live chat chatbot issue where a visitor's selected answer could briefly fail to appear correctly after being posted. This improves reliability in chatbot conversations and reduces flicker or inconsistent message display for website visitors.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/192076 PR above fixes issues regarding question-answer step of chatbot: to detect which answer was picked, it was comparing item selected text content…
Follow-up of https://github.com/odoo/odoo/pull/192076 PR above fixes issues regarding question-answer step of chatbot: to detect which answer was picked, it was comparing item selected text content with each possible answers. This worked as long as each possible answer had mutually exclusive text content. If one proposition had X and another had no X, one option could be unreachable. To solve the issue, PR above tracks the `select_answer_id`. When the user posts a message, the selected answer is returned in RPC response as store data. The selected answer is put in the question message of chatbot. This means the `message_post` store data contains 2 messages. The implementation of message_post in JS is naive and assumes the data contains only 1 message. Therefore when inserting the store data, it was assuming the 1st inserted message in store was the newly posted message. However in this particular case, the 1st inserted message was the question message of chatbot, not the user answer message. As a result, the test `test_complete_chatbot_flow_ui` had the following non-deterministic issue because of this: ``` Failed to find 1 of ".o-mail-Message" inside a specific target with text "I'd like to buy the software" (as parent). Found 0 instead. ``` This commit fixes the issue by putting the message_post message (the answer of user) before the question message of chatbot. This is the chosen fix as this is minimal. The destruct of store.insert() in message_post is too naive and should be changed by something more robust in the future. Note that this problem was not present in practice: the visitor message was visible but with minimal flicker. This is because the bus notification was adjusting the UI from the erroneous message_post result. runbot-111747
This fix ensures that when users create or edit bank statements from the transaction or reconciliation screens, manually entered statement names are no longer overwritten automatically. It also allows draft or newly imported bank statements to be saved before any transaction lines are added, reducing save errors during import workflows.
Original PR description
Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo…
Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo just didn't keep your name at all The reason is that the module account_bank_statement_extract forces the recomputation of the name when the statement's date changes which happens at the creation (and triggers our bug) but also when the OCR fills that value (in which case we still want that). So to fix that, * the default name of the statement line now check if the statement date is falsy, to avoid having a default name as 'BNK1 Statement False', and fallback on the create_date * when filling the OCR values, we check if the statement still has the same structure, we can assume it wasn't manually changed and we can safely replace the default name ticket-4424021 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
This fixes an error that occurred when multiple stock lot records were created at once through external integrations. Businesses using automated inventory workflows can now create batches of lot records reliably without running into a missing argument failure.
Original PR description
Before this commit: creating stock lot records (multi) via the xml.rpc resulted in a bug: missing argument 'vals_list'. After this commit: It is possible to create multiple stock lot records without this bug --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Self-ordering now sends the assigned stand number to the server when an order is meant to be served at a table. This helps staff identify where to deliver orders and prevents missing location details in the point-of-sale flow.
Original PR description
Before this commit, if the order was set to be served at a table, the assigned stand number was not sent to the server because the draft order was sent to the server before opening the stand number page. opw-4457394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users in an active Discuss or live chat call now get a browser confirmation prompt before refreshing, closing the tab, or navigating away. This helps prevent accidental call drop-offs and keeps conversations connected when users change pages by mistake.
Original PR description
Before this commit, when there's an ongoing Discuss call in a browser tab, page refresh or closing the tab was quitting the call immediately. Sometimes the closing of tab happens by mistake, but when navigating on the website with livechat, visitors in a call were likely to quit the call from loading another page in place. This commit prevents the closing of tab when there's an ongoing call, so that user can dismiss it if this was a mistake and wants to stay in call. Note that the dialog text is generic, as it cannot be customised on browsers. Partial port of https://github.com/odoo/odoo/pull/189428 Task-4453087
This fixes a database upgrade issue in the Vietnam localization that could block upgrades with an error. It restores the correct migration logic so affected customers can upgrade more reliably.
Original PR description
The post-migration script _fix_accounts_type attempted to use the field company_id, which no longer exists in the account.account model in the 18 version. This caused a traceback ValueError: Invalid field during the database upgrade process. The original fix was introduced here: https://github.com/odoo/odoo/pull/190187, but it was accidentally reverted by this pull request: https://github.com/odoo/odoo/pull/191324 [reference](https://github.com/odoo/odoo/commit/854c3b2#diff-19ef5a530c506fdee93fe0d113e61946b87fae7dd2d360558da69c0014f766b2R102) tbg-1602 upg-2406964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated website editor test that could fail depending on timing when switching languages. The change helps keep quality checks stable, reducing false failures during development and releases.
Original PR description
In this commit, we fix the tour snippet_translation_changing_lang. The problem is that we don't wait for the DOM to be re-rendered before clicking on the dropdown to open the editing dropdown. So, if we click before the DOM is re-rendered, it also re-renders the dropdown menu and it disappears. So depending on the execution speed of the tour, it may fail. This commit fixes this behavior. 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
The Point of Sale now refreshes product cards based on the selected order, so separate free orders no longer show the wrong product when quantities match. This helps cashiers avoid confusion and reduces the risk of processing an incorrect order.
Original PR description
Steps to reproduce: 1. Create a new free order and add 2 quantities of any product. 2. Create another free order and add 2 quantities of any product different from 1st order. 3. Switch to orders 1 and 2, and you'll see the same product and quantity loading in both orders. Issue: - Both free orders show same product card if quantity is same. Fix: - UseEffect was set to update on order rather than quantity. task-4438675
Odoo now keeps a user-entered bank statement name when statements are created from the transaction list. Default names are only regenerated when appropriate, preventing manual names from being overwritten while still using OCR dates when available.
Original PR description
…nsaction list view Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo just didn't keep your name at all The reason is that the module account_bank_statement_extract forces the recomputation of the name when the statement's date changes which happens at the creation (and triggers our bug) but also when the OCR fil> So to fix that, * the default name of the statement line now check if the statement date is falsy, to avoid having a default name as 'BNK1 Statement False', and fallback on the create_date. Same for the journal_code since journal_id isn't required. * when filling the OCR values, we assume it wasn't manually changed (why whould it be?) and we replace the default name since we now know the real date ticket-4424021
Fixes issues in Knowledge article comments where comment highlights could disappear while zooming and newly created comments could open unexpectedly after clicking the article overlay. This makes reviewing and adding comments more reliable and less disruptive for users.
Original PR description
## [FIX] knowledge: fix disappearing comments overlay This commit fixes an issue with the comments overlay when zooming and dezooming on the article. At certain sizes the overlay of the comment would…
## [FIX] knowledge: fix disappearing comments overlay This commit fixes an issue with the comments overlay when zooming and dezooming on the article. At certain sizes the overlay of the comment would disappear without reason. This is caused by the rect computations done to identify the correct overlay to draw. The target selected by the coordinates given to the `elementFromPoint` method would be incorrect. This happens because the coordinates weren't the center of the rectangle but the top. Which means that for certain resolutions the element selected is the whole body instead of the correct paragraph/text node. Now, the coordinates are computed so that we are indeed at the center of the rect. ## [FIX] knowledge: avoid opening new comments on click This commit fixes an issue with the knowledge comments small UI. When you create a comment in small UI and click on the overlay in the body of the article, the newly created comments open its popover. This behavior shouldn't happen in any circumstances except when in readonly mode. task-4463401
Starting or resuming a timer in the timesheet grid now correctly shows which row has the active timer, including after refreshing the page. This helps users see their current tracked work at a glance and avoids confusion when recording time.
Original PR description
Before this commit, when the user starts a new timer on the grid view and a timesheet is created, the timer is not marked as running on the row contained the project. Same issue when a timer is running and the user refreshes the page. This commit adds the needed data to make sure the grid view finds which row has the timer running.
The sales external tax test now clears pricelist settings before running so expected prices stay consistent. This prevents false test failures when a pricelist would otherwise change product values during the portal tour.
Original PR description
Since #76586 the tour checks for exact values, if a pricelist happens to apply, then the product value will be altered and not match expectations. Reset pricelists to ensure consistent execution environment.
Documents can no longer be saved after renaming without a valid name. This prevents unnamed documents from displaying as “False” and helps users catch the issue immediately with a clear save warning.
Original PR description
When we rename any doc without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4367684
This fix prevents an error when users create a foreign fiscal position after generating a tax closing entry. It keeps accounting configuration workflows working smoothly for companies managing foreign tax registrations.
Original PR description
After creating the tax closing, users attempting to create a foreign fiscal position will see a traceback Steps to reproduce: - Go to Accounting / Reporting / Statement Reports / Tax Return - Click 'Closing Entry' and generate the report - Go to Accounting / Configuration / Accounting / Fiscal Positions - Create a new Fiscal position with: - Detect Automatically: true - Country: Germany - Foreign Tax ID: DE123456789 - Save Issue: Traceback will raise `AttributeError: 'account.fiscal.position' object has no attribute 'filter_multi_company'` opw-4376837
Fixes an issue where the Trial Balance could not display additional balance-related columns after a performance change in version 18.0. This helps users see the expected financial figures without losing the speed improvements from the earlier update.
Original PR description
Since 18.0[^1], the ending balance is done by summing the values fetched instead of querying the database again. While this is a great performance gain, it also means that we can't get other values like the balance. Note that the Trial Balance has been refactored in 18.1[^2], so a simple fix is enough. opw-4435450 [^1]: e598fcb48b5e4f0126406a4008f175a88528ba85 [^2]: a7e1ec20e07efc39bca44d3ae613a54770175273
Swiss ISO 20022 payment files will now include the recipient bank identifier when it is available, instead of always omitting it. This helps avoid rejected EUR payments at banks that require this information while keeping it optional where not needed.
Original PR description
The fix previously done[^1] was always removing the BIC number because it is "optional". While it should be optional, some banks require it for payments done in EUR. The reason the previous fix was done was to avoid having the `Othr` tag, but that tag won't be used outside of methods returning `False` explicitly for `_skip_CdtrAgt`. opw-4423834 [^1]: 1a221f2f3160a48dc7ba08ea59c6781071b1adf3
This update makes the Italian point of sale payment setup include the split payment index field so it can be configured properly. It helps prevent checkout errors caused by multiple payments sharing the default value.
Original PR description
This field is used to manage split payments on the PoS. If this field is not set and remains at its default value (`0`), it causes an error on the PoS. Error message: `OwlError: Got duplicate key in t-foreach: 0`
Code cleanup and technical improvements
This update reorganizes how default project values are set for field service tasks. It keeps the behavior easier to maintain while reducing the risk of inconsistent task setup in future changes.
Miscellaneous changes
We improve the image reliability by: - Improving handlers cleanup (we only removed os-specific handlers but downloaded all), - Forcing Odoo service to restart after checkout, even if an error occurred. Task: 4433461 Forward-Port-Of: odoo/odoo#191928
Original PR description
We improve the image reliability by: - Improving handlers cleanup (we only removed os-specific handlers but downloaded all), - Forcing Odoo service to restart after checkout, even if an error occurred. Task: 4433461 Forward-Port-Of: odoo/odoo#191928
In modules l10n_cz and l10n_hu_edi the currency rate computation on the invoice lines was changed. Instead of using the standard date (i.e. Invoice Date) for the currency conversion we use the Taxable Supply Date (for l10n_cz / CZ) or Delivery Date (for l10n_hu_edi / HU). The way this was done conflicts with a change in 17.3: Since then we store and display the currency rate on invoices (See commit bedffa80beb61c134e8f476ef2ca71f2bd66f554 for more details). The rate for each line shoul
Original PR description
In modules l10n_cz and l10n_hu_edi the currency rate computation on the invoice lines was changed. Instead of using the standard date (i.e. Invoice Date) for the currency conversion we use the…
In modules l10n_cz and l10n_hu_edi the currency rate computation on
the invoice lines was changed. Instead of using the standard date
(i.e. Invoice Date) for the currency conversion we use the
Taxable Supply Date (for l10n_cz / CZ) or Delivery Date
(for l10n_hu_edi / HU).
The way this was done conflicts with a change in 17.3:
Since then we store and display the currency rate on invoices
(See commit bedffa80beb61c134e8f476ef2ca71f2bd66f554 for more details).
The rate for each line should then just be taken from the rate stored on the move.
Currently the rate on the invoice is still computed with the standard date (invoice date)
in any case.
So e.g. with l10n_cz installed it can happen happen that the lines of a CZ invoice
- compute the currency rate individually "themselves" instead of taking it from the invoice
(which is one of the things the change in 17.3 wanted to prevent)
- use a different different date for the currency rate conversion than the invoice
(in case the Taxable Supply Date is set)
I.e. the rate stored and displayed on the invoice may have nothing to do with the rate
that was actually used for the conversion.
Example that goes wrong currently for l10n_cz on runbot
1. Install l10n_cz
2. Select CZ Company
3. Ensure the USD currency is as follows:
- Starting on 2024-12-01 there is 10 units per CZK rate
- There is no other currency rate defined
4. Create an invoice
- in USD
- with invoice date 2024-11-01
- Taxable Supply Date 2024-12-01
- a single invoice line with price 100 and no taxes
5. The invoice displays:
- "1 CZK = 1.000000 USD" (Since we ignore the Taxable Supply Date)
- total: 100 USD
6. The "Journal Items" tab displays only 10 CZK total.
(Since we use the Taxable Supply Date for the actual conversion)
Related commits: The currency rate computations for move lines were overridden
in commits e3bac6461500d34425697eed5a263c605f6f9de5 (l10n_cz) and
b1e07d27da27aad86049c8eae42e1803cf24bd3f (l10n_hu_edi) respectively.
This commit fixes the currency rate computation for these localizations:
We revert the changes to the currency rate computation on the lines and
adapt the date used for the currency rate computation on the invoice.
The invoice then displays the correct rate and the lines just take the (correct)
rate from the invoice.
Further for l10n_cz the taxable supply date is hidden on non-invoices and
ignored for currency computations on non-invoices.
task-4367605
related upgrade PR: https://github.com/odoo/upgrade/pull/6853
Forward-Port-Of: odoo/odoo#189023* STEP TO REPRODUCE: install event (only CE code), go to Registration Desk then hit button < to go back -> The system warning there are no gantt view * Solution: using existing action `action_event_view` with `clearBreacrumbs` which will help display the menu correctly 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
Original PR description
* STEP TO REPRODUCE: install event (only CE code), go to Registration Desk then hit button < to go back -> The system warning there are no gantt view * Solution: using existing action `action_event_view` with `clearBreacrumbs` which will help display the menu correctly 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#191376 Forward-Port-Of: odoo/odoo#191295
If you create a pricelist rule with a discount that has a valid date range, that discount is only applied if the SO was created in that range. Even if it is confirmed within the valid date range. Fix: For website_sale orders we consider the date to be the current time when computing the price. opw-4375643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192858 Forward-Port-Of: odoo/odoo#191538
Original PR description
If you create a pricelist rule with a discount that has a valid date range, that discount is only applied if the SO was created in that range. Even if it is confirmed within the valid date range. Fix: For website_sale orders we consider the date to be the current time when computing the price. opw-4375643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192858 Forward-Port-Of: odoo/odoo#191538
Steps to reproduce: -------------------- - Go my account - Click on tasks - Search Issue: ------ The client when searching without selecting a scope cannot search. This is direct incidence of the [changes](https://github.com/odoo/odoo/commit/2a0ff2ae7bd46666) Since the default search_in was set to content that has been removed. Fix: --- Setting the search_in defaulting to name. (Name is the closest to what content did) opw-4396491 --- I confirm I have signed the CLA
Original PR description
Steps to reproduce: -------------------- - Go my account - Click on tasks - Search Issue: ------ The client when searching without selecting a scope cannot search. This is direct incidence of the [changes](https://github.com/odoo/odoo/commit/2a0ff2ae7bd46666) Since the default search_in was set to content that has been removed. Fix: --- Setting the search_in defaulting to name. (Name is the closest to what content did) opw-4396491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191150
The unit tests were having a dependency from account_reports module which is not a dependency of the l10n_jo_edi module nor even a community module. This commit removes this dependency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192893
Original PR description
The unit tests were having a dependency from account_reports module which is not a dependency of the l10n_jo_edi module nor even a community module. This commit removes this dependency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192893
As we updated the camera interface's logic, we need to add the new library to the IoT Box image. We also removed the python lib patching part, as it was only used by the old camera detection logic. Enterprise PR: [https://github.com/odoo/enterprise/pull/76511](https://github.com/odoo/enterprise/pull/76511) Task: 4432584 Forward-Port-Of: odoo/odoo#192449
Original PR description
As we updated the camera interface's logic, we need to add the new library to the IoT Box image. We also removed the python lib patching part, as it was only used by the old camera detection logic. Enterprise PR: [https://github.com/odoo/enterprise/pull/76511](https://github.com/odoo/enterprise/pull/76511) Task: 4432584 Forward-Port-Of: odoo/odoo#192449
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines.  **Expected:** Accountants should be allowed to manage the products database. **Steps to reproduce:** - Activate Invoicing app; - Configure a branch to the company; - Create a user with an accounting `Accountant` role and set the branch company as only entry in Allowed Companies and as Default C
Original PR description
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines. …
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines.  **Expected:** Accountants should be allowed to manage the products database. **Steps to reproduce:** - Activate Invoicing app; - Configure a branch to the company; - Create a user with an accounting `Accountant` role and set the branch company as only entry in Allowed Companies and as Default Company;  - Log in as that new user; - Try create a new product through a Customer Invoice or a Vendor Bill. **Cause:** The `Accountant` role itself has no right on products. **Fix:** Reset a previously removed (february 2023 (saas-16.2) odoo/odoo@512574861691f425ec6a17f20fe4b586bb88a299) access right on `product_template` for group `group_account_manager`.  **Note:** This PR replaces https://github.com/odoo/enterprise/pull/75453 after discussion with reviewer. opw-4293151 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192445 Forward-Port-Of: odoo/odoo#190360
Currently below error occurs when creating a time-off type. Error: `ValueError: invalid literal for int() with base 10: '84,000'` Steps to reproduce :- - Open 'Time Off' >> Go to 'Configuration' >> Click 'Time off Types' >> Click 'New' . - Give 'Time off Type' a name >> Enable 'Allow Negative Cap' >> Set 'Maximum Excess Amount' >> Hit 'Save'. - The error appears in the log. This commit solves the above issue by removing the `widget`. sentry-6184334906 Forward-Port-Of: odoo/odoo#1
Original PR description
Currently below error occurs when creating a time-off type. Error: `ValueError: invalid literal for int() with base 10: '84,000'` Steps to reproduce :- - Open 'Time Off' >> Go to 'Configuration' >> Click 'Time off Types' >> Click 'New' . - Give 'Time off Type' a name >> Enable 'Allow Negative Cap' >> Set 'Maximum Excess Amount' >> Hit 'Save'. - The error appears in the log. This commit solves the above issue by removing the `widget`. sentry-6184334906 Forward-Port-Of: odoo/odoo#191978
In journal items, when grouping by 'Internal Group', a traceback appears due to referencing a non-existent table `account_account` as it has been joined with `account_move_line`. This commit ensures the referenced table is correctly updated in the case of joins. opw-4405281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192489
Original PR description
In journal items, when grouping by 'Internal Group', a traceback appears due to referencing a non-existent table `account_account` as it has been joined with `account_move_line`. This commit ensures the referenced table is correctly updated in the case of joins. opw-4405281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192489
Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the public user, `user_id = 4`) is assigned, which may not match the intended company if the payment is being processed for a company other than the default one. This mismatch between the journal's company and the mandate's `company_id` prevents the payment from being completed. Fix: The `company_id` i
Original PR description
Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the…
Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the public user, `user_id = 4`) is assigned, which may not match the intended company if the payment is being processed for a company other than the default one. This mismatch between the journal's company and the mandate's `company_id` prevents the payment from being completed. Fix: The `company_id` is properly set during mandate creation, aligning it with the payment link's associated company and preventing unexpected behavior. Steps: 1) Configure two companies with accounting setups. 2) Open the Payment Providers menu. 3) Select SEPA, activate test mode, and ensure it is published. 4) Duplicate the SEPA payment provider, set the company_id to the second company, activate test mode, and ensure it is published. 5) Go to any sales order in the first company, generate a payment link, open it, and select SEPA. Enter any fake IBAN — it will process successfully. 6) Switch to the second company and repeat step 5. You will encounter an error message because the mandate is incorrectly assigned to the first company, preventing payment completion. Forward-Port-Of: odoo/enterprise#76705
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery creations handled in _post_invoice_hook are all done at the end of the last batch, without any commit. If the database has a lot of invoices to generate (ex: ~200), it would take a few minutes before the delivery creations to start. This is enough time for the CRON "payment: post-process transaction
Original PR description
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery…
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery creations handled in _post_invoice_hook are all done at the end of the last batch, without any commit. If the database has a lot of invoices to generate (ex: ~200), it would take a few minutes before the delivery creations to start. This is enough time for the CRON "payment: post-process transactions" to start and handle all the invoices & payments created by "_create_recurring_invoice". The 2 CRON were then likely to create SerializationFailure due to a concurrent update. With this commit, each batch creates its own deliveries before triggering the next batch. If the delivery creations do fail: - The error is caught as to not prevent the next batch from being triggered. - An exception activity is created on the subscription to notify the customer about the error. - A contextual action is available to manually trigger the delivery. OPW-4319019 --- When the delivery creation failed, you can easily spot it on the list view thanks to the activity warning:  --- ## Example log ``` 2024-11-14 07:48:53,757 96554 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (30.353s). 2024-11-14 07:58:26,142 96886 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 07:58:57,145 96886 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (31.003s). 2024-11-14 08:05:51,910 97204 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:06:46,734 97204 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (54.823s). 2024-11-14 08:06:53,143 97262 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:07:46,207 97262 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (53.064s). 2024-11-14 08:07:55,496 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:08:30,928 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 08:08:44,957 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (49.461s). 2024-11-14 08:08:50,945 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:09:18,543 97300 ERROR customer-database odoo.addons.base.models.ir_cron: Call from cron Sale Subscription: generate recurring invoices and payments for server action #705 failed in Job #10 2024-11-14 08:15:52,854 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (441.926s). 2024-11-14 08:18:31,161 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 08:21:16,823 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (165.662s). 2024-11-14 08:28:31,865 99066 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. ``` - At the beginning: `payment: post-process transactions` take ~30 secs - Then, `Sale Subscription: generate recurring invoices and payments` runs a few times (as expected). - `payment: post-process transactions` re-runs, and it takes 441.926. During this time, `Sale Subscription: generate recurring invoices and payments` starts and failed. --- ## A few points of information/discussion: - The SerializationFailure is systematic on the customer database, who has ~200 subscriptions invoiced each day. - The added action "Subscription: Generate delivery" is optional, I am amenable to remove it from this PR, but we would just block the customer with undelivered stock. - In master, it would be better to automatically detect the deliveries not done and re-generate each day. However, I was unable to find a proper way to do it without adding a field or changing the behavior of an existing one. - I originally wanted to create to add a button to the form view like "Create Delivery", however, like above I was unable to properly detect undelivered subscriptions. - The exception activity does not directly notify the users via discuss, do you think I should add the option? - I did not (yet) created tests for this error. To properly do so, I would need to reproduce a SerializationFailure which I'm unsure of how to do without doing commits. I could simply fake it by overwriting the `_action_launch_stock_rule` to raise an Error... TBD Forward-Port-Of: odoo/enterprise#75402 Forward-Port-Of: odoo/enterprise#73911
Bug === When posting on Instagram, it will download the image from the URL gave to the API, this process can be sometimes slower than excepted in d2d5ddcdb1613a4f83a2d90e02e2856f87cb5c05, and so we increase the timeout of the requests. Other API calls can also take more times than excepted, so we also increase the other timeouts. Task-3109395 Backport of https://github.com/odoo/enterprise/commit/50762761a59c1dbc41c43540d504b1d3f55626dd opw-4213307 Forward-Port-Of: odoo/enterprise#
Original PR description
Bug === When posting on Instagram, it will download the image from the URL gave to the API, this process can be sometimes slower than excepted in d2d5ddcdb1613a4f83a2d90e02e2856f87cb5c05, and so we increase the timeout of the requests. Other API calls can also take more times than excepted, so we also increase the other timeouts. Task-3109395 Backport of https://github.com/odoo/enterprise/commit/50762761a59c1dbc41c43540d504b1d3f55626dd opw-4213307 Forward-Port-Of: odoo/enterprise#76325
Steps to reproduce: ------------- - Install Sales, Field Service, and Stock, - Go into Field service and open any task that has products. - Through stat button on the top access the product catalog. - Click on burger menu on any service type product. Issue: - View Availability option should not be shown for service type products Cause: - No condition to make it invisible. Solution: - Added a condition when product type is service to the option invisible. task-3801551
Original PR description
Steps to reproduce: ------------- - Install Sales, Field Service, and Stock, - Go into Field service and open any task that has products. - Through stat button on the top access the product catalog. - Click on burger menu on any service type product. Issue: - View Availability option should not be shown for service type products Cause: - No condition to make it invisible. Solution: - Added a condition when product type is service to the option invisible. task-3801551 Forward-Port-Of: odoo/enterprise#76144 Forward-Port-Of: odoo/enterprise#58817
With the changes done to `account.external.tax.mixin` the name of ir.logging is now the module name and not 'Avatax' anymore. So us logs resulted in Avatax US and were not shown by default when opening the window with the window actions. opw-4429151 Forward-Port-Of: odoo/enterprise#76557
Original PR description
With the changes done to `account.external.tax.mixin` the name of ir.logging is now the module name and not 'Avatax' anymore. So us logs resulted in Avatax US and were not shown by default when opening the window with the window actions. opw-4429151 Forward-Port-Of: odoo/enterprise#76557
When [adding this module], the translations were forgotten. We are adding them here. [adding this module]: https://github.com/odoo/enterprise/commit/055ed588dd7558c568373fbaa6d24208d0aeeb87 opw-4425163 Forward-Port-Of: odoo/enterprise#76646 Forward-Port-Of: odoo/enterprise#76612
Original PR description
When [adding this module], the translations were forgotten. We are adding them here. [adding this module]: https://github.com/odoo/enterprise/commit/055ed588dd7558c568373fbaa6d24208d0aeeb87 opw-4425163 Forward-Port-Of: odoo/enterprise#76646 Forward-Port-Of: odoo/enterprise#76612
Starting from saas-17.4, the default transaction code in settings shows the commidity code instead of transaction codes. This commit applies the domain for showing transaction codes instead. opw-4419718 Forward-Port-Of: odoo/enterprise#76519
Original PR description
Starting from saas-17.4, the default transaction code in settings shows the commidity code instead of transaction codes. This commit applies the domain for showing transaction codes instead. opw-4419718 Forward-Port-Of: odoo/enterprise#76519
Following the "nice urls" [task][1] It may happen that the studio's systray item is re-rendered while the actionService is loading a URL with multiple actions In this case, there may be a crash because the SystrayItem would check if the current action (in this case from the virtual controller) is editable. After this commit, there is no crash. part of task-4391729 [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f Forward-Port-Of: odoo/enterprise#76
Original PR description
Following the "nice urls" [task][1] It may happen that the studio's systray item is re-rendered while the actionService is loading a URL with multiple actions In this case, there may be a crash because the SystrayItem would check if the current action (in this case from the virtual controller) is editable. After this commit, there is no crash. part of task-4391729 [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f Forward-Port-Of: odoo/enterprise#76694
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create an invoice with a Mexican partner and confirm - Create a Payment - In the invoice form view, go to the "CFDI" page - Click "Update CFDI" - The payment appears, click on "Show" - The button "Request Cancel" does nothing ### Cause: the method `button_request_cancel` on move is called from the payment model but does not return anything: ``` def button_request_cancel(self): self.move_id.button_requ
Original PR description
### Steps to reproduce:
- Install "l10n_mx" and switch to a Mexican company
- Create an invoice with a Mexican partner and confirm
- Create a Payment
- In the invoice form view, go to the "CFDI" page
- Click "Update CFDI"
- The payment appears, click on "Show"
- The button "Request Cancel" does nothing
### Cause:
the method `button_request_cancel` on move is called from the payment model but does not return anything:
```
def button_request_cancel(self):
self.move_id.button_request_cancel()
```
But the `button_request_cancel` from `l10n_mx_edi` is returning a wizard that is never caught.
### Solution:
When clicking the "Request cancel" button, the method `action_request_cancel` is called instead of `action_cancel` which will dispatch the request depending on the type of move being cancelled.
opw-4332483
Forward-Port-Of: odoo/enterprise#75714Camera driver was not working, so we updated the logic to detect camera devices, and improved the one to take pictures. We also caught the opportunity to move IoT Handlers corresponding to `quality` modules to `quality_iot`. Community PR: [https://github.com/odoo/odoo/pull/192449](https://github.com/odoo/odoo/pull/192449) Task: 4432584 Forward-Port-Of: odoo/enterprise#76511
Original PR description
Camera driver was not working, so we updated the logic to detect camera devices, and improved the one to take pictures. We also caught the opportunity to move IoT Handlers corresponding to `quality` modules to `quality_iot`. Community PR: [https://github.com/odoo/odoo/pull/192449](https://github.com/odoo/odoo/pull/192449) Task: 4432584 Forward-Port-Of: odoo/enterprise#76511
[FIX] account_reports: sections tour The sections' tour was breaking with the change of year. We use the generic tax report for doing the testing. The generic tax report has a periodicity of 1 month and opens at the previous period. Our tests where based on the current date year. It works fine except on the change of year. Indeed, we will be on January of year XXXX but the report will open on December of year YYYY. Now, we correctly remove 1 month to our dates to make sure we have
Original PR description
[FIX] account_reports: sections tour The sections' tour was breaking with the change of year. We use the generic tax report for doing the testing. The generic tax report has a periodicity of 1 month and opens at the previous period. Our tests where based on the current date year. It works fine except on the change of year. Indeed, we will be on January of year XXXX but the report will open on December of year YYYY. Now, we correctly remove 1 month to our dates to make sure we have the correct year. We also took the time to replace the usage of Date of plain javascript with DateTime of the luxon library. Forward-Port-Of: odoo/enterprise#76606
In project sharing, when the user changes a planned date in task form, a traceback occurs, because the portal user doesn't have the rights on `resource.calendar.attendance`. To solve that, we call the method that get those records with sudo (`_get_tasks_by_resource_calendar_dict`). task-3973305 Forward-Port-Of: odoo/enterprise#72695
Original PR description
In project sharing, when the user changes a planned date in task form, a traceback occurs, because the portal user doesn't have the rights on `resource.calendar.attendance`. To solve that, we call the method that get those records with sudo (`_get_tasks_by_resource_calendar_dict`). task-3973305 Forward-Port-Of: odoo/enterprise#72695