Daily updates from Odoo
Wednesday, August 13, 2025
130 changes
15 changes
Resolved issues and error corrections
Subscriptions that were paused and manually invoiced now resume with the correct next billing date. This prevents businesses from skipping billing periods or invoicing against dates that were already handled manually.
Original PR description
Version: - saas-18.4 Before: - If a subscription was paused and a manual invoice was created, resuming the subscription would set the next invoice date incorrectly. - It would often pick a date that…
Version: - saas-18.4 Before: - If a subscription was paused and a manual invoice was created, resuming the subscription would set the next invoice date incorrectly. - It would often pick a date that had already been invoiced manually, skipping over the pause period. - This happened because the user_pause_start is not reset after posting the manual invoice. After: - Now, when a manual invoice is posted during a pause, the pause state is cleared right away. - This makes sure the next_invoice_date is calculated properly when the subscription is resumed, without missing the pause period. Impact: - Fixes issues where subscriptions skipped billing periods after a manual invoice during a pause. - Keeps the billing period accurate when pausing and resuming subscriptions. Steps to reproduce: - Create and confirm a subscription. - Pause the subscription. - Post a manual invoice. - Resume the subscription. task-4946268 Forward-Port-Of: odoo/enterprise#90395
Rental orders now create and publish planning shifts more reliably, including creating one shift per unit when products are ordered by unit. The update also prevents staff from adding shifts to rental order lines that are already fully planned, helping avoid overbooking and planning errors.
Original PR description
## [FIX] sale_renting_planning: make sure shift generated by RO is published ## [FIX] sale_renting_planning: generate shifts when confirming rental order based on uom Before this commit, when the…
## [FIX] sale_renting_planning: make sure shift generated by RO is published ## [FIX] sale_renting_planning: generate shifts when confirming rental order based on uom Before this commit, when the user creates room product to generate shifts when a rental order is confirmed with that product, we expect to generate one shift per quantity ordered if the UoM is Unit instead of Hours/Days. This commit improves the shifts generation to take into account the UoM set on the SOL linked to rental order confirmed. That is, if the UoM set is Unit then one slot per unit ordered of the product will be generated. Otherwise, one shift will be generated for the SOL as it is currently the case. ## [FIX] sale_renting_planning: make sure to not overload the rental service Before this commit, when the user creates a new shift and clicks on `Add to Last Order` the shift will be added to the SOL contained one of products linked to the role set on the shift. The problem is we don't check if there is still something to plan for that SOL. This commit makes sure the SOL to set to the shift has something to plan to be sure it is not overloaded. task-4916537 Forward-Port-Of: odoo/enterprise#91327
This fix prevents the French FEC import from overwriting account names when multiple accounts share similar codes but have different labels. It helps preserve accounting data accuracy during imports and avoids manual corrections after importing files.
Original PR description
Steps to reproduce: - import a fec with different account 164*** with different names Issue: All the account's name will be overriden Cause: Before 18.0, apparently, code and name were joined and was not an issue solution: update the code to the new logic by filtering out the name from the override (`_apply_template`) opw-4690284 Forward-Port-Of: odoo/enterprise#92149 Forward-Port-Of: odoo/enterprise#86809
The POS Belgian blackbox module now keeps existing employee clock-ins when another employee clocks in from a different device. This prevents accidental clock-outs during device synchronisation, helping stores track staff attendance accurately.
Original PR description
- Fixes an issue where clocking in a second employee on a different device would automatically clock out the first one. This was due to `self` being unset during POS session leading to incorrect loading of `users_clocked_ids` and `employees_clocked_ids`. - The issue was appearing when `pos_session._post_read_pos_data` is triggered from `pos_config.notify_synchronisation`. task-id: 4902090 Forward-Port-Of: odoo/enterprise#89273
Fixed a layout issue in accounting reports where control panel filters could appear pushed to the right. The change keeps the settings button visible while allowing the filters to remain properly centered, improving usability and visual consistency.
Original PR description
Issues: - The control panel filters were appearing right-sided instead of being properly centered. This issue arose from a previous fix that added `flex-basis: min-content` to the breadcrumbs to ensure cog button visibility, but this caused the breadcrumbs to take excessive space and push filters to the right. Fix Applied: - Replaced `flex-basis: min-content` with `min-width: fit-content` on the breadcrumbs container. This maintains cog button visibility while allowing the breadcrumbs to use only the space they actually need, enabling the filters to center naturally in the remaining space. Task-4985129
This fix makes an automated barcode inventory test wait for the destination location update to appear before continuing. It reduces random test failures, helping keep stock barcode workflows stable during development and releases.
Original PR description
A non-deterministic error has been occurring across all versions starting from 18.0 when running the `test_split_line_on_destination_scan`. problem: The issue lies in one of the steps of the tour,…
A non-deterministic error has been occurring across all versions starting from 18.0 when running the
`test_split_line_on_destination_scan`.
problem:
The issue lies in one of the steps of the tour, where the destination location of the remaining quantity is changed from WH/Stock to shelf1 (LOC-01-01-00). Right after this change, the test proceeds to assertLineDestinationLocation. However, the test step was previously waiting for the presence of the .o_validate_page.btn-primary element — an element that is already visible before the destination location update is actually applied. As a result, the tour sometimes skips to the next step prematurely, without ensuring the location change has occurred, leading to test failure.
Fix:
We replaced the trigger .o_validate_page.btn-primary with a more reliable condition: waiting for an element containing the destination text .../Section 1 (.o_line_destination_location:contains(".../Section 1")). This ensures that the step only proceeds once the destination update has been reflected in the UI.
Runbot-145458
Forward-Port-Of: odoo/enterprise#92130
Forward-Port-Of: odoo/enterprise#91927The Argentina electronic invoicing test setup now stops retrying after a small number of failed connection attempts instead of looping indefinitely. This reduces unnecessary external connection attempts and makes test failures clearer and faster to identify.
Original PR description
In 18.0 and above test hasn't worked in months, half the time it fails because pretty much nothing works in it and half the time it's because it keeps looping on trying to set up the connection and failing (possibly because we're getting blacklisted due to how much spamming we do). For now restrict to just trying 5 times (per class since it's called from a `setUpClass`) with an exponential backoff. This may yet end up in removing the entire test directory as it doesn't seem like anyone cares. Forward-Port-Of: odoo/enterprise#92226 Forward-Port-Of: odoo/enterprise#92207
Batch transfer route planning now opens the intended map view, restoring the ability to rearrange pickings from that screen. This helps logistics teams organize deliveries correctly without being sent to a map view that does not support the needed ordering.
Original PR description
Commit ade5e5085df2 move the `default_order` value as it was defined in the wrong module. Consequence is the map view defined in `stock_enterprise` cannot be reordered anymore. This is an issue as the one in `stock_fleet_enterprise` is never used. The action window is patched to take a picking map view but without specifying witch one. This commit force the map view defined in `stock_fleet_enterprise` to be used in the action of `stock_fleet_enterprise`. Consequence is that the picking can be rearranged again in the map view coming from a batch transfer and not coming from the picking list. Forward-Port-Of: odoo/enterprise#91999
This change makes the automated accounting reports tour more reliable by using more precise steps during testing. It helps reduce false test failures, supporting smoother maintenance and more dependable release checks.
Original PR description
In this commit, we fix tour by using less generic triggers.
The portal now shows total hours based only on validated timesheets when that invoicing policy is selected. This prevents customers from seeing inflated hours that include unvalidated work, keeping task totals consistent with the timesheet lines displayed.
Original PR description
### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines…
### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines shown is the validated ones only but the Hours spent includes the non-validated ones too ### Current behavior before PR: The total hours spent for timesheets in portal view when setting the invoicing policy to 'Validate Timesheets Only' is calculated wrongly as it takes the non validated ones into account. This is happening as when passing the values to the view we pass 'task_sudo' variable which will have the SUPERUSER as the env.user https://github.com/odoo/odoo/blob/saas-17.2/addons/project/controllers/portal.py#L569 so it won't pass the condition if the user is portal or not https://github.com/odoo/enterprise/blob/saas-17.2/sale_timesheet_enterprise/models/project_task.py#L33:L35 and it will calculate all the timesheet without taking validation into condisderation. ### Desired behavior after PR is merged: As we are using those computed fields only in portal views so we don't have to check if the user is portal user as even if an internal user is showing the same view for testing he should be able to see the same data as the portal user. opw-4193842 Forward-Port-Of: odoo/enterprise#70557
The Documents app button is now shown to internal users who can already access shared documents through other entry points. This makes access easier and clarifies that a full Documents User role is not required for documents shared with all internal users.
Original PR description
The app is accessible to all internal users via smart buttons and their portal already, showing the button is helpful in two ways: 1/ Easier access to the app, duh. 2/ Makes it explicit that you don't need to be a "Documents User" to have access to documents shared with all **internal users**, even those that are not documents user (that didn't have the app button available). In 18.0 so that new installations have it. Task-4889053 Forward-Port-Of: odoo/enterprise#92124 Forward-Port-Of: odoo/enterprise#90937
A stock barcode test now sets an email address for the admin user so quantity update notifications can be sent as expected. This helps ensure warehouse notification behavior is properly validated even when demo data is not available.
Original PR description
Updating the initial demand of a stock move notify the users. Without email address, the notification cannot be send. As the email address of the admin user is only fill in the demo data, this commit adds one specially for the test. runbot: 226778 Forward-Port-Of: odoo/enterprise#91103 Forward-Port-Of: odoo/enterprise#89722
The Cash Flow report now handles grouping by account codes consistently, preventing an error that could stop the report from loading in some configurations. This helps finance users access cash flow information reliably when account code fields are customized or present.
Original PR description
The term used by GROUP BY should be the same term in the SELECT, avoiding the posible error like: ERROR: column "account_move_line__account_id.code_store" must appear in the GROUP BY clause or be used in an aggregate function That appears when a column named account_code is created for the model account_move_line. opw-4963180 Forward-Port-Of: odoo/enterprise#91915
This fix ensures subscription effective dates set during order processing are properly written to the database. It prevents cases where the date could appear saved internally but be missing later, improving reliability for subscription records.
Original PR description
Since https://github.com/odoo/enterprise/commit/ff8e55ed83d4905584b7ea10b60ded0d7afbd0cf setting the effective date is done in a precommit hook. Problem, the precommit don't automatically flush. The value set in the cache may be never reflected in the database. Solution: Explicitly flush in the precommit hook Forward-Port-Of: odoo/enterprise#92283
Point of Sale orders in the Mexican e-invoicing flow now round totals using the currency's own precision. This prevents valid discounted orders from being blocked by small rounding differences during validation.
Original PR description
Issue: With specific prices and discounts, we can get an rounding issue that does not pass the Validation Error. Purpose of this PR: To round the amount total based on the currency's rounding precision to pass the check. Steps to Reproduce on Runbot: install pos, l10n_mx create products prices with 75.00 and 60.00 respectively. create discount 100% on order change decimal accuracy to 3, change tax to Include with Price create PoS order with products and apply discount receive ValidationError even though the amount total should be rounded to 0.0. opw-4944830 Forward-Port-Of: odoo/enterprise#92141
15 changes
Resolved issues and error corrections
The self-order table selection popup now shows restaurant tables in a predictable order by floor and table number. This makes it easier for customers or staff to find the right table and reduces confusion during ordering.
Original PR description
Task [#4991803](https://www.odoo.com/odoo/my-tasks/4991803) Runbot: https://runbot.odoo.com/runbot/bundle/18-0-incremental-order-table-pop-pos-self-order-ltra-391429 --- When selecting a table in the POS self-order, we sort the tables by `floor_id` and then by `table_number` in ascending order. This ensures a consistent and user-friendly experience when choosing a table.
Leave validation no longer fails for employees who do not have a fixed working schedule. The system now uses the employee resource timezone as a fallback, helping managers process time off reliably for fully flexible staff.
Original PR description
Currently, if we try to validate a leave for a fully flexible employee (employee without a working schedule), we get a traceback when fetching the timezone from the working schedule. To rectify this issue, we default to the timezone of the resource. opw-4979974
The Point of Sale now reuses an existing empty order when staff select New Order from the receipt screen, rather than creating another blank order. This keeps sessions cleaner and avoids accumulating unnecessary empty orders.
Original PR description
- When clicking `New order` on the receipt screen, we now want to reuse an empty order (not finalized and no order lines) before creating a new one. This avoids creating many useless empty orders. task-id: 5003010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now restore an earlier task description from history, make further edits, and save without seeing an incorrect history-related error. This prevents disruption when using task version history and helps keep project work updates reliable.
Original PR description
Problem: When applying a specific version from history in `task.description`, then updating and saving it, an error appears stating the content was saved from a different history model. Cause: When inserting versioned content, the required `data-last-history-steps` attribute is not included. Solution: Ensure the latest `data-last-history-steps` is added when restoring a version. Steps to reproduce: - Open Project > any task - Change the description - Save - Open version history and apply any version - Update the description - Save - Error appears opw-4829553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error when a user linked to one company views an e-commerce website or products belonging to another company. It ensures the website can read the company currency needed for product display, improving reliability for multi-company online stores.
Original PR description
A multi-company issue can occur when a user from another company tries to access products belonging to a different company. Steps to reproduce: 1. Create a e-commerce website without a pricelist on company A 2. Create a user assigned with only access to company B 3. Connect with this user and try to access the products on the website of company A An error will be raised because the user does not have access to company A. opw-4983506 Forward-Port-Of: odoo/odoo#222457
Peru PLE reports 5.1 and 6.1 now keep the original account move name exactly as entered, including spaces and slashes. This helps ensure exported report data remains complete and audit-ready for tax authority reviews.
Original PR description
Problem: For PLE reports 5.1 and 6.1, the value for `glosa` was being modified (i.e. blank spaces and slashes removed). Although SUNAT accepts the modified value, no information should be removed in the case it might lead to issues with tax authorities during an audit. Solution: The value for `glosa` on the reports should be the exact account move name. opw-4803060 Forward-Port-Of: odoo/enterprise#92167 Forward-Port-Of: odoo/enterprise#91967
Shared document links that have been moved or redirected now send users to the correct content. This preserves access for older links and reduces broken-link issues for document users.
Original PR description
We do not currently check for `documents.redirect` records when accessing the `/documents/content/<access_token>` endpoint. This commit fixes this by redirecting if a `document.redirect` with the appropriate `access_token` was created for backwards compatibility. opw-4517698
A manufacturing work order test now turns on the required lot tracking settings before running. This prevents false failures when demo data is not available, helping keep quality checks reliable without changing user-facing behavior.
Original PR description
The mrp lot generation test lacked the settings to properly add and process lot data, causing it to fail without demo data. This commit aims to address that. Error: https://runbot.odoo.com/odoo/error/229706
The German EC Sales List CSV export now includes the required version information expected by the Elster portal. This prevents valid reports from being rejected during upload and helps businesses submit their EU sales declarations without manual correction.
Original PR description
When uploading the EC Sales List csv to Elster.de portal, users will see the file rejected with the following error (EN translated) """ Your CSV file was created for an older version of the CSV interface. Please refer to the version table in the import help for the latest version of the interface and any changes. If the version information is correct, please check the encoding of your CSV file. The permitted encoding is UTF-8. """ This occurs because the csv is missing the version strings identifying the versions of data format References: https://www.elster.de/eportal/helpGlobal?themaGlobal=zmdo_import_eop https://www.datev-community.de/t5/Betriebliches-Rechnungswesen/Import-CSV-Daten-nacvh-Elster-f%C3%BCr-ZM/td-p/480079 opw-4850314
Fixes an error that could occur when users enabled the Account Types filter and expanded an account in the General Ledger report. This improves reliability for finance teams using filtered ledger views, especially for payable and receivable accounts.
Original PR description
Steps to reproduce:
- Open general ledger configuration
- Under Options tab, set filter Account Types as "Payable and receivable"
- Open General Ledger report
- Unfold an account
Traceback will raise
```
File "[...]/odoo/tools/query.py", line 101, in add_join
assert self._joins[alias] == (sql_kind, table, condition)
AssertionError
```
Because of the account types filter we already add a "LEFT JOIN" between account_move_line and account_account
Then, trying to add a "JOIN" between the same tables, the system find a different type of JOIN and fails the assert
opw-4742411The recurring invoice job now checks a larger set of subscriptions so eligible subscriptions are less likely to be skipped when some records are filtered out. This helps businesses avoid missed subscription invoices during scheduled billing runs while keeping performance safeguards in place.
Original PR description
**Steps to reproduce** With the default batch size of 30: - create 1 subscription not requiring payment and confirm it - create 31 subscriptions requiring payment and confirm them - launch the…
**Steps to reproduce** With the default batch size of 30: - create 1 subscription not requiring payment and confirm it - create 31 subscriptions requiring payment and confirm them - launch the "Generate recurring invoices" cron - the first subscription is not invoiced **Cause** Issue since commit https://github.com/odoo/enterprise/commit/9bad2716c3903ff89dad5f1d4bc0a2fb39c76293 Since the search with the `_recurring_invoice_domain` only returns the first batch_size + 1 records, and a subsequent filtering by `_get_subscriptions_to_invoice` is applied, `len(all_subscriptions) > batch_size` doesn't guarantee that there aren't more subscriptions to invoice not returned by search. **Solution** Increase the limit's size so that `need_cron_trigger` is True in the case where some records are filtered by `get_subscriptions_to_invoice`. In the case where a lot of subscriptions are filtered and the issue still persists, increasing the `batch_size` to process all subscriptions is necessary. The limit is not removed for performance reasons. opw-4766637
This fix ensures Mexican point-of-sale orders use the correct currency rounding when checking totals. It prevents fully discounted orders from being incorrectly blocked by a validation error caused by tiny rounding differences.
Original PR description
Issue: With specific prices and discounts, we can get an rounding issue that does not pass the Validation Error. Purpose of this PR: To round the amount total based on the currency's rounding precision to pass the check. Steps to Reproduce on Runbot: install pos, l10n_mx create products prices with 75.00 and 60.00 respectively. create discount 100% on order change decimal accuracy to 3, change tax to Include with Price create PoS order with products and apply discount receive ValidationError even though the amount total should be rounded to 0.0. opw-4944830
This update fixes an automated test so it no longer fails depending on the time of day or the user's timezone. It helps keep quality checks stable without changing any customer-facing timesheet or holiday behavior.
Original PR description
Before this commit, when the `test_timer_methods_handle_project_access_restrictions` test is executed after 22h in UTC the test failed because the timezone of the current user is the belgian one. This commit makes sure the date and timezone no longer affects this test since it is not the purpose of this test. runbot-error-230490
The Argentina electronic invoicing test setup now stops after a limited number of connection attempts instead of retrying indefinitely. This reduces wasted test time and helps avoid repeatedly hitting external services when they are unavailable.
Original PR description
In 18.0 and above test hasn't worked in months, half the time it fails because pretty much nothing works in it and half the time it's because it keeps looping on trying to set up the connection and failing (possibly because we're getting blacklisted due to how much spamming we do). For now restrict to just trying 5 times (per class since it's called from a `setUpClass`) with an exponential backoff. This may yet end up in removing the entire test directory as it doesn't seem like anyone cares. Forward-Port-Of: odoo/enterprise#92207
The portal now shows total hours based only on validated timesheets when that invoicing policy is selected. This keeps the displayed total consistent with the visible timesheet lines and avoids overstating billable or tracked work for customers.
Original PR description
### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines…
### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines shown is the validated ones only but the Hours spent includes the non-validated ones too ### Current behavior before PR: The total hours spent for timesheets in portal view when setting the invoicing policy to 'Validate Timesheets Only' is calculated wrongly as it takes the non validated ones into account. This is happening as when passing the values to the view we pass 'task_sudo' variable which will have the SUPERUSER as the env.user https://github.com/odoo/odoo/blob/saas-17.2/addons/project/controllers/portal.py#L569 so it won't pass the condition if the user is portal or not https://github.com/odoo/enterprise/blob/saas-17.2/sale_timesheet_enterprise/models/project_task.py#L33:L35 and it will calculate all the timesheet without taking validation into condisderation. ### Desired behavior after PR is merged: As we are using those computed fields only in portal views so we don't have to check if the user is portal user as even if an internal user is showing the same view for testing he should be able to see the same data as the portal user. opw-4193842