Daily updates from Odoo
Friday, August 14, 2026
211 changes
27 changes
Resolved issues and error corrections
The attendance Gantt view now keeps today visible when users switch between time scales, such as week and day. This prevents the schedule from jumping away from the current day, making daily planning smoother and less confusing.
Original PR description
**Steps to Reproduce:** 1. Open attendnace Gantt view. 2. Set the scale to Week. 3. Set the scale back to Day. The view loses focus on today. **Reason:** * Before, when changing the scale on Gantt views and shrinking it, the view would always reset to today. * This behaviour was recently changed by the JS framework team to instead anchor the new time period around the date currently centered in the viewport. **Solution:** * If the current range includes today, scale while preserving today in the range. * Otherwise, keep the current behaviour and use the center of the viewport. Task: 6346363
Fixes an issue where enabling Equipment did not refresh linked stock lot information on draft field service planning shifts. This keeps equipment-related inventory details accurate after a recent internal status rename.
Original PR description
After odoo/enterprise#113153 renamed planning.slot states `draft` to `1_draft`, enabling Equipment no longer recomputed lot_ids on draft shifts because set_values/post_init still searched for state `draft`
Fixes an issue that prevented users from downloading the General Ledger report as a CSV when using French. The export now uses the correct translation context, so localized accounting reports download reliably instead of failing with an error.
Original PR description
Currently an exception is generated when the user tries to export (downlaod) a `CSV` file of the `General Ledger` report as the below step: - Install the `accountant` module with demo data - Enable…
Currently an exception is generated when the user tries to export (downlaod) a `CSV` file of the `General Ledger` report as the below step: - Install the `accountant` module with demo data - Enable and change to the `French` language - Go to `Comptabilité` > `Analyse` > `General Ledger` - Click the cog icon in the menu > Click on `CSV` - An error occurs in the log, and nothing is downloaded Error: `TypeError: 'NoneType' object is not subscriptable` This issue occurs after the recent refactoring changes in [1]. When `_generate_csv_lazy_export` is called, it uses the `_()` method for translation, which accesses `self.env`. However, at this point, the cursor is already closed. As a result, when the code at [2] is reached from `ormcache`, it raises the above error because `model.env.transaction.ormcaches__` is `None` (code ref [3]). This commit fixes the above issue by performing the translation using the existing `handler` variable, which contains an environment with the new cursor (see code ref [4]). [1]: https://github.com/odoo/odoo/commit/13c3adf3a8b5ba6325190d6b9aea45fb8a6a8b2f [2]: https://github.com/odoo/odoo/blob/5ef7829895b2e05650da394c1e35dfdc3a23c066/odoo/orm/cache.py#L111 [3]: https://github.com/odoo/odoo/blob/5ef7829895b2e05650da394c1e35dfdc3a23c066/odoo/orm/environments.py#L1012 [4]: https://github.com/odoo/enterprise/blob/912a47b8f0828ef8316b7e4ecdabf8a2f305b313/account_reports/models/account_general_ledger.py#L524 Sentry-7608119520
Australian Single Touch Payroll submissions now check that required payroll details are present before sending data to the ATO. Instead of a system traceback when an empty record is submitted, users receive a clear validation message so they can correct the record.
Original PR description
When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module -…
When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module - Switch to ``My australian Company`` - Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth - Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO Traceback: ```py IndexError: tuple index out of range ``` https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233 The traceback occurs because ``_get_fiscal_year_start()`` assumes that the STP record always contains at least one payslip or one employee. When these recordsets are empty, indexing the first element raises an IndexError. Solution: This commit validates that the required payslips or employees are present before the submission and raises a validation error instead of a traceback. Forward-Port-Of: odoo/enterprise#127733 Forward-Port-Of: odoo/enterprise#124096
This fixes an automated payroll payrun test so it works reliably when confirming payruns and when country-specific payroll modules are installed. The change helps prevent false test failures without changing payroll behavior for end users.
Original PR description
This commit fixes a couple things with this tour: 1. We need to confirm the dialog that appears when we try to confirm the payrun itself 2. Depending on whether or not a particular l10n_XX module is…
This commit fixes a couple things with this tour:
1. We need to confirm the dialog that appears when we try to confirm the payrun itself
2. Depending on whether or not a particular l10n_XX module is installed, the trigger that we were previously using to check whether or not a payslip had been confirmed, `.btn[name='action_payment_report']` might not be there; i.e., l10n_us_hr_payroll, among others: https://github.com/odoo-dev/enterprise/blob/7767024956325d52fb30239967025b04999a9188/l10n_us_hr_payroll_account/views/hr_payslip_run_views.xml#L11-L13
It can be seen there ^ that that button is invisible under a slightly different condition than the base `hr_payroll` version of that button, causing an inconsistency in this test when that module is installed: https://github.com/odoo-dev/enterprise/blob/7767024956325d52fb30239967025b04999a9188/hr_payroll/vie
ws/hr_payslip_run_views.xml#L175
We resolve this by checking for either button in that step: `trigger: ".btn[name='action_paid'], .btn[name='action_payment_report']"`
runbot-243607Fixed an issue that caused audit report PDF exports from Accountant Knowledge to fail on systems using the newer PDF engine. Users can now generate these PDFs reliably, including on newer Python environments.
Original PR description
…ern pypdf backend `export_article_to_pdf` calls `writer.setPageMode("/UseOutlines")` on the `PdfFileWriter` instance to make the outline/bookmarks panel visible by default when the generated PDF is…
…ern pypdf backend
`export_article_to_pdf` calls `writer.setPageMode("/UseOutlines")` on the `PdfFileWriter` instance to make the outline/bookmarks panel visible by default when the generated PDF is opened. the old PyPDF2
`odoo.tools.pdf` picks its backend dynamically it first tries to import PyPDF2==2.12.1 and only falls back to the modern `pypdf` library if PyPDF2 is not importable, which is the case on Python 3.13 per requirements.txt, or on any worker where PyPDF2 failed to install.
The PyPDF2-based writer still exposes `setPageMode`, so the bug was never seen on backends using it. The modern pypdf-based writer replaced that method with a `page_mode` property (getter/setter) and never kept a camelCase alias for it
As a result, any request hitting this code got a beautiful HTTP 500
`AttributeError: 'BrandedFileWriter' object has no attribute 'setPageMode'`
`setPageMode` is not called anywhere else so
this fixes the call site directly instead of adding a new alias to the shared _pypdf.py
opw-6382905
Forward-Port-Of: odoo/enterprise#124480This fixes an issue in Odoo Sign where certain empty values could cause an error instead of being handled normally. Users should see fewer interruptions when preparing or processing signature requests with fields that do not have automatic values.
Original PR description
Forward-Port-Of: odoo/enterprise#127426
Fixes an issue where users without certain accounting permissions could be blocked from confirming sales orders when a Studio approval rule used a related accounting field. Approval checks now run with the necessary access so valid business workflows are not interrupted by unrelated permission limits.
Original PR description
continuation of [PR](https://github.com/odoo/enterprise/pull/121856) Issue: Inside _get_approval_spec filtered_domain is called a few times and due to a related field that calls an access rights group that the user who used the action isnt apart of is blocked by the filtered_domain. To Replicate: 1) Install studio, sale, Accounting and make sure "account_followup" is installed 2) create a related field on the sales.order form related to "customer -> follow up status" 3) Save 4) Create a "Studio Approval Rule" (studio.approval.rule) with a domain using the new related studio field -> method : "action_confirm" -> approver:admin 5)create a test user with no accounting access rights 6) in an incognito browser try and create a sales order, and then confirm it. it will throw the access rights error Solution: Go one up the stack where _get_approval_spec is called and add a syudo for those calls opw-6316069 Forward-Port-Of: odoo/enterprise#127412
Managers without full HR access can now launch appraisal campaigns for employees they oversee. The fix ensures selected employees are read correctly, preventing appraisals from being accidentally created for everyone when access rules hide the selection.
Original PR description
**Issue**: -User without hr rights is not allowed to launch campaigns for employees under him in the hierarchy. -This issue appears only in master, but it discovered another issue from 19.3, where the value for `employee_ids` was not accessed by the normal user. Thus, appraisals are created for all employees in the list, because not selecting an employee means selecting "All Employees". **Solution**: -SUDOing the read to allow the compute to see what the user has selected. Forward-Port-Of: odoo/enterprise#127391
When projects and tasks are created from templates, archived users are now excluded from task assignments linked to project roles. This prevents inactive employees or former team members from being assigned work through sales-created projects.
Original PR description
Steps to reproduce: ------------------------------------------------- 1. Install the `sale_project` module 2. Create a test user with Project User rights 3. Create a Project Role with the Created…
Steps to reproduce:
-------------------------------------------------
1. Install the `sale_project` module
2. Create a test user with Project User rights
3. Create a Project Role with the Created User as a Team Member
4. Create a Template Project as follows:
* Add one task to the template project
* Add the created Project role to the Task
5. Create a Service Type Product with:
* Create on order: Project
* Project Template: Created Template
6. Archive the Created User
7. Create and Confirm the Sale Order with the Created Product
Observation:
-------------------------------------------------
The generated task is assigned to the archived user, although the archived user is no longer part of the Project Role.
Issue:
-------------------------------------------------
While creating Project and Tasks from template, the context disable active record filtering (e.g., `active_test=False`), causing the assignment logic to fetch both active and inactive/archived users linked to the role. https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/odoo/orm/models.py#L4868
After that, during the `copy_data` method, It takes all the users from the roles without checking weather user is active or not
https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/addons/project/models/project_task.py#L890-L904
And even if we pass only Active users from this method, on moving further, it reassigns the users from roles without checking the Active field of the user
https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L501-L503
https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L544-L553
Due to this, the Archived User is also assigned to the tasks from the project roles
Solution:
-------------------------------------------------
Apply a `filtered('active')` check directly on the project role's users `(role.user_ids)` within the core task-copying logic in both `project` and `project_enterprise` modules. This ensures archived users are universally excluded from task assignments during template copying, regardless of what triggers the template instantiation.
Related Community PR: https://github.com/odoo/odoo/pull/274426
opw-6350841
Forward-Port-Of: odoo/enterprise#125637The Timesheet Assistant now recognizes time spent checking the Discuss inbox and labels the suggestion as "Checking Inbox". This replaces a confusing previous label, making timesheet suggestions easier for users to understand and confirm.
Original PR description
## Previous Behavior When the Timesheet Assistant detected a user spending time in their Discuss inbox, it generated a suggestion labeled "Discussing in/with Inbox". The name of this suggestion was judged to not make much sense. ## New Expected Behavior When the Timesheet Assistant detects a user spending time in their Discuss inbox, it will now generate a suggestion labeled "Checking Inbox" due to a new assistant rule. task-[6420655](https://www.odoo.com/odoo/project/4105/tasks/6420655) Forward-Port-Of: odoo/enterprise#126328
Planning managers without HR access can now change the resource on a planning slot without accidentally publishing it. The fix uses public employee information for the permission check, keeping planning updates aligned with the user's intended action.
Original PR description
For planning manager without HR access, if the user change the resource of the planning slot it will publish it automatically as the employee_ids field cannot be used without HR access. Prefer to use public employee to have better condition without using explicit sudo Caused-by: https://github.com/odoo/enterprise/commit/e88dcd0e545183b3f03e06b62158c52a1e6d2103 Forward-Port-Of: odoo/enterprise#127503
French VAT reimbursement declaration 3519 now includes the bank account holder name in the account details section. This helps meet required filing information and reduces the risk of rejected or incomplete reimbursement declarations.
Original PR description
For reimbursement declarations, the name of the holder of the account is required This commits adds holder's name to the account data zone no-task-id Forward-Port-Of: odoo/enterprise#127708 Forward-Port-Of: odoo/enterprise#127554
Payroll configuration now hides Mexico-specific CFDI settings when users are working in a non-Mexican company. This avoids confusion by showing these localization options only where they are relevant.
Original PR description
Steps to reproduce: 1. Switch to a non-Mexican company. 2. Go to Payroll > Configuration > Settings. 3. The CFDI settings block is visible. Reason: The CFDI block was missing a country check. Solution: Restrict the CFDI block visibility to Mexican companies. Task-6448440 Forward-Port-Of: odoo/enterprise#127022
The Timesheet Assistant now includes very small calendar events by adding their time to a matching larger event instead of ignoring them. This helps suggested timesheets reflect the full amount of time worked and reduces underreported totals.
Original PR description
## Previous Behavior Before this PR: When events were to small to suggestion Timesheet Assistant would completely discard these events. This lead to a suggestion haveing a lower total time than it should. ## New Expected Behavior After this PR: When an event is too small to suggest and shares its name and group with one or more larger event, the duration of the smaller event is added to the last event with the same name and groupe. task-[6452987](https://www.odoo.com/odoo/project/4105/tasks/6452987) Forward-Port-Of: odoo/enterprise#127167
The Point of Sale Urban Piper ticket screen now shows the order information button on mobile devices as well as desktop. This makes order details easier to access for staff using smaller screens, reducing friction during in-store or restaurant operations.
Original PR description
Before this commit: ------------ - The order info button was not visible on the ticket screen in the mobile UI. After this commit: ------------ - Display the order info button in both the mobile and desktop views of the ticket screen. Related: - Community: https://github.com/odoo/odoo/pull/276568 Task-6388045 Forward-Port-Of: odoo/enterprise#124485
This fix ensures signature fields stay in the correct visible position when signing PDFs that were created with unusual page origins. It prevents users from downloading signed documents where signatures or fields appear missing, improving reliability of the Sign workflow.
Original PR description
Steps to reproduce (version 16+): 1) Obtain a pdf with a negative origin point: This can occur when a customer exports a pdf from another software, or it can be made manually using a python script 2) In the sign app, upload the pdf and create a new template, add a signature field to the document. 3) Sign the document. The preview will load correctly and the signature will be visible 4) Download and open the signed pdf. The signature is not on the document Notes: Issue occurs because the signature was added to the pdf outside of the visible area. The preview works because the signature is rendered on top of the unsigned document in the correct location. The issue can be fixed applying a translation to the canvas. Ticket: [6317223](https://www.odoo.com/odoo/project/49/tasks/6317223?debug=assets) Forward-Port-Of: odoo/enterprise#127302 Forward-Port-Of: odoo/enterprise#121960
Before this commit, the Chat action of the meeting view could keep its unread dot instead of showing "1" after "Mark as Unread": FAILED: [14/21] Tour discuss.meeting_view_tour Step .o-mail-Meeting [title='Chat']:has(.badge:contains(1)). Element (.o-mail-Meeting [title='Chat']:has(.badge:contains(1))) has not been found. TIMEOUT step failed to complete within 10000 ms. This happens because a mark as read carries the id of the newest message the client knew when it re
Original PR description
Before this commit, the Chat action of the meeting view could keep its unread dot instead of showing "1" after "Mark as Unread": FAILED: [14/21] Tour discuss.meeting_view_tour Step .o-mail-Meeting…
Before this commit, the Chat action of the meeting view could keep its unread dot instead of showing "1" after "Mark as Unread":
FAILED: [14/21] Tour discuss.meeting_view_tour
Step .o-mail-Meeting [title='Chat']:has(.badge:contains(1)).
Element (.o-mail-Meeting [title='Chat']:has(.badge:contains(1)))
has not been found.
TIMEOUT step failed to complete within 10000 ms.
This happens because a mark as read carries the id of the newest message the client knew when it requested it, and under load it can reach the server after a newer message was posted. The new message separator then moves back before that message, which makes it unread before the user even asks for it. The click on "Mark as Unread" writes the separator the counter is already computed from, so the counter does not change, and the client, which holds the counter it displays while the user reads the thread, never refreshes it.
This commit moves the new message separator forward only, so reading messages never makes another one unread.
https://runbot.odoo.com/odoo/error/945958
Forward-Port-Of: odoo/odoo#281988This PR adapts log levels to avoid spamming sentry if bluetooth adaptor isn't ready
Original PR description
This PR adapts log levels to avoid spamming sentry if bluetooth adaptor isn't ready
Before this commit, `waitStoreFetch` returns before the answer is in the store: right after `waitStoreFetch("channels_as_member")`, the store holds no record for a channel that answer carries, on a hundred runs out of a hundred. A test that then asserts on the fetched data depends on timing. This happens because `listenStoreFetch` steps from the `onRpc` callback, which runs before the route is served. The `microTick` at the end of `waitStoreFetch` is meant to cover the rest of the round trip,
Original PR description
Before this commit, `waitStoreFetch` returns before the answer is in the store: right after `waitStoreFetch("channels_as_member")`, the store holds no record for a channel that answer carries, on a hundred runs out of a hundred. A test that then asserts on the fetched data depends on timing.
This happens because `listenStoreFetch` steps from the `onRpc` callback, which runs before the route is served. The `microTick` at the end of `waitStoreFetch` is meant to cover the rest of the round trip, but the answer only reaches the store six microtasks later.
This commit steps from `Store.fetchStoreData` instead, whose promise resolves once the answer is in the store, and drops the tick. The `onRpc` option keeps its route hooks, as tests use it to delay a request.
Forward-Port-Of: odoo/odoo#282155
Forward-Port-Of: odoo/odoo#281499Steps to reproduce: 1. Install CRM 2. Activate the Arabic language with English 3. Create a lead with a new email, a new company name, and the Arabic language 4. Save and try to send a message from the chatter Issue: - After the message is sent, the language of Lead is changed to EN from Arabic - Contacts created with the English language Cause: - When we send a message from the chatter of a Lead that has an email_from, a partner_name, and the Arabic language, this forces the creati
Original PR description
Steps to reproduce: 1. Install CRM 2. Activate the Arabic language with English 3. Create a lead with a new email, a new company name, and the Arabic language 4. Save and try to send a message from…
Steps to reproduce: 1. Install CRM 2. Activate the Arabic language with English 3. Create a lead with a new email, a new company name, and the Arabic language 4. Save and try to send a message from the chatter Issue: - After the message is sent, the language of Lead is changed to EN from Arabic - Contacts created with the English language Cause: - When we send a message from the chatter of a Lead that has an email_from, a partner_name, and the Arabic language, this forces the creation of a new contact First child contact is created with arabic language, but `parent_name` is present in the creation dictionary, so this triggers `_create_parent_from_name` that builds a dictionary to create the parent company, but it does not pass the language. As a result, the parent company is created with the English language. then `_create_parent_from_name` links the child to this new parent and this linking triggers the `_compute_lang` on the child and overwrites the child's language with the parent's language At last, Lead's own computed field `_compute_lang_id` triggers and sets the language to English Solution: - pass the language in the dictionary to create the parent company opw-6449407 Forward-Port-Of: odoo/odoo#281747
**ISSUE** When running` _cron_migrate_local_to_cloud_storage` manually,` cron._trigger` is called, which schedules the cron to be triggered later by a worker. To check whether the cron is being run manually or not, we check if there is a request. In SaaS, staging, and duplicate databases, the request is only truthy when the cron is run manually and falsy when run by a worker. In a SH production database, however, the request is truthy both when run manually and when run by a worker due to a spe
Original PR description
**ISSUE** When running` _cron_migrate_local_to_cloud_storage` manually,` cron._trigger` is called, which schedules the cron to be triggered later by a worker. To check whether the cron is being run manually or not, we check if there is a request. In SaaS, staging, and duplicate databases, the request is only truthy when the cron is run manually and falsy when run by a worker. In a SH production database, however, the request is truthy both when run manually and when run by a worker due to a specific cron worker configuration in that environment. As a result,` cron._trigger `is called infinitely and nothing gets uploaded to the cloud. **FIX** Instead of calling `cron._trigger()` to reschedule the job, `limit_time_real` is used when `request` is truthy, and `limit_time_real_cron` otherwise. opw-6330674 Forward-Port-Of: odoo/odoo#279581
Before this commit: --- - When a sale order line contained extra attribute addons, those values were not transferred to the POS order line while settling the sales order. After this commit: --- - Preserved extra attribute addons when creating POS order lines from SO. task-6204583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282160 Forward-Port-Of: odoo/odoo#276143
Original PR description
Before this commit: --- - When a sale order line contained extra attribute addons, those values were not transferred to the POS order line while settling the sales order. After this commit: --- - Preserved extra attribute addons when creating POS order lines from SO. task-6204583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282160 Forward-Port-Of: odoo/odoo#276143
Steps to reproduce: - 1. In the website editor, open the portal "My Account" page and, in the Customize panel, disable the "Timesheets" option. 2. As a portal user, open My Account > Tasks for a project whose tasks have allocated time and logged timesheets. 3. Look at the task list, then open one of those tasks. Issue: - The task list still shows the per-group "Total: spent / allocated", and the task detail page still shows "Allocated Time", even though timesheets are hidden in the port
Original PR description
Steps to reproduce: - 1. In the website editor, open the portal "My Account" page and, in the Customize panel, disable the "Timesheets" option. 2. As a portal user, open My Account > Tasks for a project whose tasks have allocated time and logged timesheets. 3. Look at the task list, then open one of those tasks. Issue: - The task list still shows the per-group "Total: spent / allocated", and the task detail page still shows "Allocated Time", even though timesheets are hidden in the portal. Fix: - - Add `_show_portal_timesheets()` to the condition of the list "Total" column. - Gate the `portal_my_task_allocated_hours` block on `_show_portal_timesheets()` in the task detail page. task-6140807 Forward-Port-Of: odoo/odoo#272043
As the `requirements.txt` file path changed from `addons/iot_box_image` to `setup/iot_box_builder` the checkout from 19 to saas-19.4 can't find the file (looking at the former path instead of the new one). As a workaround, we add `sentry_sdk` requirement in v19.0. Forward-Port-Of: odoo/odoo#282122 Forward-Port-Of: odoo/odoo#282001
Original PR description
As the `requirements.txt` file path changed from `addons/iot_box_image` to `setup/iot_box_builder` the checkout from 19 to saas-19.4 can't find the file (looking at the former path instead of the new one). As a workaround, we add `sentry_sdk` requirement in v19.0. Forward-Port-Of: odoo/odoo#282122 Forward-Port-Of: odoo/odoo#282001
Steps to reproduce: - make a few sales in the PoS and refund one of them - close the session - select all those orders, including the refund, and create a consolidated invoice Issue: The invoice is refused with "You cannot validate an invoice with a negative total amount. You should create a credit note instead.", while the total of the selected orders is positive. If a cash rounding method is set on the PoS config, no error is raised but the posted document is a credit note carrying a r
Original PR description
Steps to reproduce: - make a few sales in the PoS and refund one of them - close the session - select all those orders, including the refund, and create a consolidated invoice Issue: The invoice is…
Steps to reproduce: - make a few sales in the PoS and refund one of them - close the session - select all those orders, including the refund, and create a consolidated invoice Issue: The invoice is refused with "You cannot validate an invoice with a negative total amount. You should create a credit note instead.", while the total of the selected orders is positive. If a cash rounding method is set on the PoS config, no error is raised but the posted document is a credit note carrying a rounding line equal to twice the order total (a credit note of 20.00 with a 40.00 "Rounding" line for sales of 10.00 + 20.00 and a refund of 10.00). Cause: _prepare_invoice_vals picked the move type from the presence of a refund in the group instead of its net amount: any group holding an order with is_refund set, or a negative amount_total, became an 'out_refund'. _get_invoice_lines_values then negates the quantities of every order whose direction differs from the move type, so the sales end up as negative lines of a credit note and the document totals -20.00 instead of +20.00. account.move refuses to post it. When invoice_cash_rounding_id is set, the cash rounding line is computed to bring the document back to a total valid for its type, so it absorbs the whole sign error and the wrong credit note is posted silently. Fix: Choose the move type from the net amount_total of the group, as was done up to saas-18.3, and keep is_refund only as the tie-break when that net is zero so a lone zero-total refund still gives a credit note. The sign handling of the lines is unchanged: it already keys on each order's own direction, which is what makes a sale a negative line of a credit note and a refund a negative line of an invoice. opw-6452996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281703
Steps to reproduce the bug: - Enable 2-step delivery (pick + ship) on a warehouse. - Set both rules on the delivery route to "Pull" (instead of the default Pull + Push): - Pick rule (Stock -> Output): action = Pull, procure_method = make_to_stock - Ship rule (Output -> Customers): action = Pull, procure_method = make_to_order - Create a sale order for qty 1 and confirm it. - Validate the Pick transfer. - Return the Pick transfer. - Cancel the sale order. - Set it back to quotati
Original PR description
Steps to reproduce the bug: - Enable 2-step delivery (pick + ship) on a warehouse. - Set both rules on the delivery route to "Pull" (instead of the default Pull + Push): - Pick rule (Stock ->…
Steps to reproduce the bug:
- Enable 2-step delivery (pick + ship) on a warehouse.
- Set both rules on the delivery route to "Pull" (instead of the default Pull + Push):
- Pick rule (Stock -> Output): action = Pull, procure_method = make_to_stock
- Ship rule (Output -> Customers): action = Pull, procure_method = make_to_order
- Create a sale order for qty 1 and confirm it.
- Validate the Pick transfer.
- Return the Pick transfer.
- Cancel the sale order.
- Set it back to quotation and confirm it again.
Problem:
The newly created delivery (ship) move ends up asking for a wrong, inflated quantity instead of the ordered one (e.g. 3 times the ordered qty for the scenario above; the multiplier depends on the number of prior confirm/cancel/return cycles).
`_action_cancel` (addons/sale_stock/models/sale_order.py) only cancels pickings that are not `done`, so after the pick is validated and returned, cancelling the SO only cancels the still-pending ship move. The pick move and its return stay `done` and linked to the sale order line.
`SaleOrderLine._get_outgoing_incoming_moves` determines which rule "started" the pull/push chain by picking the rule of the first surviving (non-cancelled) move, grouped by warehouse: https://github.com/odoo/odoo/blob/d7bad3dc6c068ffe8643ecb01da1865d743bfb8f/addons/sale_stock/models/sale_order_line.py#L338-L347
Once the ship move is cancelled, it is excluded from that computation, so the Pick rule is wrongly identified as the "triggering" rule instead of the Ship rule. The done pick move and its return share that rule, so they both end up wrongly classified as incoming (returned) quantities instead of being excluded from the computation like before the cancellation, corrupting `_get_qty_procurement`. On reconfirm, `_action_launch_stock_rule` computes
`product_qty = product_uom_qty - qty`, inflating the quantity requested on the new ship move.
Solution:
Identify the triggering rule from the sale order line's full move history, including cancelled moves, so cancelling a move later doesn't change which rule is considered to have started the chain.
opw-6364113
Forward-Port-Of: odoo/odoo#281709
Forward-Port-Of: odoo/odoo#28028019 changes
Resolved issues and error corrections
Weekly rentals selected for exactly one week were sometimes counted as two weeks because default pickup and return times made the period slightly longer than seven days. The fix aligns those default times for weekly rentals so customers see the correct rental duration and price.
Original PR description
A product with a weekly rental periodicity is booked for 2 weeks when we actually book it for a single week Steps to reproduce: 1. Install Rental and eCommerce 2. Go to Rental > Products and create a new product 'test', in the Sales tab, set the rental periodicity to 'Weeks' 3. Click on the smart button 'Go to Website' 4. Change the rental period so that it exactly covers a week (e.g. from Monday to Monday) 5. The website shows that you're booking for 2 weeks Issue: The default pickup time is 9h and the default return time is 18h. When we select exactly one week for the rental duration, the true duration of the rental is greater than 1 week (because of the pickup and return time) so it is rounded as 2 weeks. Solution: Also swap `pickup_time` and `return_time` when swapping from weeks periodicity. opw-6397786
Fixes an issue that could prevent users from exporting audit report articles as PDFs in environments using the newer PDF processing backend. This restores reliable PDF export behavior and avoids server errors during a business reporting workflow.
Original PR description
…ern pypdf backend `export_article_to_pdf` calls `writer.setPageMode("/UseOutlines")` on the `PdfFileWriter` instance to make the outline/bookmarks panel visible by default when the generated PDF is…
…ern pypdf backend
`export_article_to_pdf` calls `writer.setPageMode("/UseOutlines")` on the `PdfFileWriter` instance to make the outline/bookmarks panel visible by default when the generated PDF is opened. the old PyPDF2
`odoo.tools.pdf` picks its backend dynamically it first tries to import PyPDF2==2.12.1 and only falls back to the modern `pypdf` library if PyPDF2 is not importable, which is the case on Python 3.13 per requirements.txt, or on any worker where PyPDF2 failed to install.
The PyPDF2-based writer still exposes `setPageMode`, so the bug was never seen on backends using it. The modern pypdf-based writer replaced that method with a `page_mode` property (getter/setter) and never kept a camelCase alias for it
As a result, any request hitting this code got a beautiful HTTP 500
`AttributeError: 'BrandedFileWriter' object has no attribute 'setPageMode'`
`setPageMode` is not called anywhere else so
this fixes the call site directly instead of adding a new alias to the shared _pypdf.py
opw-6382905Belgian point-of-sale self-orders are now signed using the designated self-ordering user, so mobile orders can be validated even when no cashier is logged in. This prevents fiscal device rejections and keeps self-order sales compliant while printing remains handled separately.
Original PR description
In this PR (github.com/odoo/enterprise/pull/126611) we removed the blackbox printingQueue, cause the pritning is now handled via Obox. - This commit reintroduce a signingQueue, but only for self-orders, as the printing is now handled via Obox. - It also fix the issue where signing a mobile self-order while no cashier is connected (login screen) was rejected by the FDM: signExternalOrder took the INSZ number from getCashier(), so signSale was sent without its required employeeId. - Self-orders are now signed with the INSZ number of the self-ordering default user, like the kiosk already does. FW of : https://github.com/odoo/enterprise/pull/126695
The Timesheet Assistant now recognizes time spent checking the Discuss inbox and labels the suggestion as “Checking Inbox.” This makes timesheet suggestions clearer and easier for users to understand.
Original PR description
## Previous Behavior When the Timesheet Assistant detected a user spending time in their Discuss inbox, it generated a suggestion labeled "Discussing in/with Inbox". The name of this suggestion was judged to not make much sense. ## New Expected Behavior When the Timesheet Assistant detects a user spending time in their Discuss inbox, it will now generate a suggestion labeled "Checking Inbox" due to a new assistant rule. task-[6420655](https://www.odoo.com/odoo/project/4105/tasks/6420655)
Creating an employee declaration without selecting an employee no longer triggers an application error. This prevents an avoidable interruption in Belgian payroll reporting and makes the declaration workflow more reliable.
Original PR description
When creating an employee declaration without selecting an employee, a traceback occurs. Steps to reproduce the error: - Install ``l10n_be_hr_payroll`` module with demo data - Switch to Belgian…
When creating an employee declaration without selecting an employee, a traceback occurs. Steps to reproduce the error: - Install ``l10n_be_hr_payroll`` module with demo data - Switch to Belgian company - Go to Payroll > Reporting > Individual Accounts > Create a new Individual Account > Click on Eligible Employees > Create a new employee declaration without employee > Save Traceback: ```py ValueError: Expected singleton: hr.employee() ``` https://github.com/odoo/enterprise/blob/000544c3d5b93e194264e15bb73d9599525106e3/hr_payroll/models/hr_payroll_employee_declaration.py#L71 The ``_compute_version_id()`` method calls ``_get_version()``. When ``employee_id`` is empty, ``_get_version()`` is invoked on an empty ``hr.employee`` record, and its ``ensure_one()`` call raises the above traceback at [1]. [1]: https://github.com/odoo/odoo/blob/3c358ae2badad69b125695a97b4a14e8ab77fccd/addons/hr/models/hr_employee.py#L745-L750 sentry-7625826444 Forward-Port-Of: odoo/enterprise#125175
Spanish VAT record book exports now work for accounting users even when the report includes Point of Sale data. This prevents access errors during tax reporting while keeping the POS data use limited to building the report.
Original PR description
Steps to reproduce:
- With an ES Company
- Open a POS session, add product with tax and pay
- As a user with only accounting access
- Go to Accouting > Reporting > Tax report
- Select Generic Tax report
- Print "VAT record Books"
Issue:
An AccessError will raise
```
Access Error
You are not allowed to access 'Point of Sale Session' (pos.session) records.
This operation is allowed for the following groups:
- Point of Sale/User
Contact your administrator to request access if necessary.
```
Analysis:
Vat Record Books handler for POS needs to read pos.session and pos.order records. Currently, the action is performed with the rights of the user running the report, so accounting-only user face an error.
As POS records are only read internally to build the report, we add sudo call to get the data.
opw-5862529
Forward-Port-Of: odoo/enterprise#126590
Forward-Port-Of: odoo/enterprise#125980French VAT reimbursement declaration 3519 now includes the bank account holder's name in the account details section. This helps meet filing requirements and reduces the risk of rejected or incomplete reimbursement declarations.
Original PR description
For reimbursement declarations, the name of the holder of the account is required This commits adds holder's name to the account data zone no-task-id Forward-Port-Of: odoo/enterprise#127708 Forward-Port-Of: odoo/enterprise#127554
The Timesheet Assistant no longer drops very short calendar events when building time suggestions. If a short event matches a larger event by name and group, its time is added to the related suggestion so totals are more accurate.
Original PR description
## Previous Behavior Before this PR: When events were to small to suggestion Timesheet Assistant would completely discard these events. This lead to a suggestion haveing a lower total time than it should. ## New Expected Behavior After this PR: When an event is too small to suggest and shares its name and group with one or more larger event, the duration of the smaller event is added to the last event with the same name and groupe. task-[6452987](https://www.odoo.com/odoo/project/4105/tasks/6452987)
Managers without HR permissions can now launch appraisal campaigns for employees they manage. The fix also prevents campaigns from accidentally applying to all employees when selected employee records were not readable by the user.
Original PR description
**Issue**: -User without hr rights is not allowed to launch campaigns for employees under him in the hierarchy. -This issue appears only in master, but it discovered another issue from 19.3, where the value for `employee_ids` was not accessed by the normal user. Thus, appraisals are created for all employees in the list, because not selecting an employee means selecting "All Employees". **Solution**: -SUDOing the read to allow the compute to see what the user has selected.
This fixes an issue where users without Accounting permissions could be blocked from confirming sales orders when a Studio approval rule used certain customer follow-up fields. Approval checks now run with the right elevated access so normal business workflows are not interrupted by unrelated permission limits.
Original PR description
continuation of [PR](https://github.com/odoo/enterprise/pull/121856) Issue: Inside _get_approval_spec filtered_domain is called a few times and due to a related field that calls an access rights group that the user who used the action isnt apart of is blocked by the filtered_domain. To Replicate: 1) Install studio, sale, Accounting and make sure "account_followup" is installed 2) create a related field on the sales.order form related to "customer -> follow up status" 3) Save 4) Create a "Studio Approval Rule" (studio.approval.rule) with a domain using the new related studio field -> method : "action_confirm" -> approver:admin 5)create a test user with no accounting access rights 6) in an incognito browser try and create a sales order, and then confirm it. it will throw the access rights error Solution: Go one up the stack where _get_approval_spec is called and add a syudo for those calls opw-6316069 Forward-Port-Of: odoo/enterprise#127412
Recruitment officers without payroll permissions can now generate and open Belgian salary offers without running into an access error. This fixes a workflow blocker caused by a payroll-related warning check that used information recruiters are not allowed to read directly.
Original PR description
The field `hr.contract.salary.offer.l10n_be_is_below_scale_warning` is accessible to users outside of the payroll groups but its computation requires a read access to payroll only fields on the related `hr.version`. Steps to reproduce: 1- log in with a user that has the group Recruitment/ Officer, and no payroll privileges. 2- go to an applicant and click generate offer 3- The offer will be created but the user will not have access to it and the redirection will fail reported by our recruitment officers
Submitting Australian Single Touch Payroll records without payslips or employees now shows a clear validation message instead of causing an unexpected error. This helps payroll users understand what information is missing before sending data to the ATO.
Original PR description
When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module -…
When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module - Switch to ``My australian Company`` - Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth - Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO Traceback: ```py IndexError: tuple index out of range ``` https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233 The traceback occurs because ``_get_fiscal_year_start()`` assumes that the STP record always contains at least one payslip or one employee. When these recordsets are empty, indexing the first element raises an IndexError. Solution: This commit validates that the required payslips or employees are present before the submission and raises a validation error instead of a traceback. Forward-Port-Of: odoo/enterprise#127733 Forward-Port-Of: odoo/enterprise#124096
WhatsApp channel members can once again access Advanced Settings to manage membership. This fixes a regression in version 19.3 where the option was hidden, preserving a familiar and more suitable workflow for WhatsApp channels.
Original PR description
Show the advanced-settings thread action for WhatsApp channel members, since channel_role is only supported on channel/group types which controls this button. Advanced Settings have long been used to manage channel membership. Their removal in 19.3+ introduced a regression, while channel roles are more cumbersome and do not integrate well with WhatsApp concern similarly to livechat: https://github.com/odoo/enterprise/pull/112959#discussion_r3593831089. so keeping Advanced Settings for WhatsApp for now.
Payroll configuration now only shows Mexico-specific CFDI settings when the active company is based in Mexico. This prevents irrelevant tax invoicing options from appearing for companies in other countries, reducing confusion during setup.
Original PR description
Steps to reproduce: 1. Switch to a non-Mexican company. 2. Go to Payroll > Configuration > Settings. 3. The CFDI settings block is visible. Reason: The CFDI block was missing a country check. Solution: Restrict the CFDI block visibility to Mexican companies. Task-6448440 Forward-Port-Of: odoo/enterprise#127022
This fix prevents batch invoice sending to SUNAT from being blocked when some Peruvian invoices contain lines without taxes. Instead of a generic technical failure, the system handles the issue consistently with single-invoice sending so other invoices can continue processing.
Original PR description
In l10n_pe_edi, invoices containing lines without tax can't be submitted to SUNAT.
When sending a single invoice, an error message is displayed. However, sending multiple invoices processes them in the background by a cron job. In this case, EDI document creation fails without error handling, raising a generic parsing error and blocking the cron from processing other invoices.
Steps to reproduce:
1. Create and post two invoices with no tax on some lines.
2. From the list view, select both invoices and click "Send" and mark "SUNAT".
3. An exception is raised: `ValueError: XMLSyntaxError("Start tag expected, '<' not found, line 1, column 1")`.
opw-6390480
Forward-Port-Of: odoo/enterprise#125143When edit_translations is set, convert_to_record wraps translated terms in branding spans. Related (non-stored) fields re-read that already-wrapped value and ran the same wrapping again, producing nested spans. Only wrap terms for stored fields so related Html inherits the source branding unchanged. Also keep data-oe-translation-state in HTML safe_attrs so sanitization does not strip it. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior af
Original PR description
When edit_translations is set, convert_to_record wraps translated terms in branding spans. Related (non-stored) fields re-read that already-wrapped value and ran the same wrapping again, producing nested spans. Only wrap terms for stored fields so related Html inherits the source branding unchanged. Also keep data-oe-translation-state in HTML safe_attrs so sanitization does not strip it. 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#281729 Forward-Port-Of: odoo/odoo#280397
Steps to reproduce: --- - Install `website_sale_collect` without demo data. - Create and publish a product. - Add the product to the cart and proceed to checkout. - Complete the main address. - Select a `Pick Up in Store` delivery method and click checkout. Issue: --- The checkout redirects back to the address form instead of continuing to the payment step. Root cause: --- During checkout, `shop/checkout`[1] calls `_check_cart_and_addresses()`, which eventually invokes `_check_ad
Original PR description
Steps to reproduce: --- - Install `website_sale_collect` without demo data. - Create and publish a product. - Add the product to the cart and proceed to checkout. - Complete the main address. -…
Steps to reproduce: --- - Install `website_sale_collect` without demo data. - Create and publish a product. - Add the product to the cart and proceed to checkout. - Complete the main address. - Select a `Pick Up in Store` delivery method and click checkout. Issue: --- The checkout redirects back to the address form instead of continuing to the payment step. Root cause: --- During checkout, `shop/checkout`[1] calls `_check_cart_and_addresses()`, which eventually invokes `_check_addresses()`[2]. That method then calls `_check_delivery_address()`[3] to verify that all mandatory delivery address fields are present. When db is initialized without demo data, the pickup location address may not contain all mandatory fields (such as ZIP code). As a result, the validation fails and the checkout incorrectly redirects the customer back to the address form, even though the delivery address is a pickup location that should not be edited by the customer. Solution: --- Override `_can_be_edited_by_current_customer()` to treat the selected pickup location as a non-editable address. Since the pickup location belongs to the store, it does not make sense to ask the customer to edit or complete its address. This prevents the checkout flow from requesting address completion and allows the customer to proceed directly to the payment step. [1]https://github.com/odoo/odoo/blob/815de3f1a43bccdb5714436da2060f7a45aa385e/addons/website_sale/controllers/main.py#L1141-L1142 [2]https://github.com/odoo/odoo/blob/815de3f1a43bccdb5714436da2060f7a45aa385e/addons/website_sale/controllers/main.py#L1894-L1895 [3]https://github.com/odoo/odoo/blob/815de3f1a43bccdb5714436da2060f7a45aa385e/addons/website_sale/controllers/main.py#L1945 opw-6394166 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Issue: --- Adding a pickup-in-store delivery method to a sales order from the backend `Add shipping` wizard and clicking on the pickup point selector raises: Invalid props for component `LocationSelectorDialog`: `countryId` is not a number. Steps to reproduce: 1- Create a SO with a partner without country set. 2- Enable debug mode. 3- Use `Add shipping` wizard and choose pick-up delivery method. 4- Open the location selector. Cause: --- `PickupLocationMany2OneField.countryId` re
Original PR description
Issue: --- Adding a pickup-in-store delivery method to a sales order from the backend `Add shipping` wizard and clicking on the pickup point selector raises: Invalid props for component `LocationSelectorDialog`: `countryId` is not a number. Steps to reproduce: 1- Create a SO with a partner without country set. 2- Enable debug mode. 3- Use `Add shipping` wizard and choose pick-up delivery method. 4- Open the location selector. Cause: --- `PickupLocationMany2OneField.countryId` returns the `id` of `this.partnerRecord.country_id` which is `false` when the company is not set. This can be fixed by a safe optional chain access. opw-6321167
Steps to reproduce: - give a user the Point of Sale / User group only, without any accounting access right - open a session, sell a product to a customer and ask for an invoice Issue: The invoice is created and posted, but it is never reconciled with its payment: it stays fully due even though the journals and the accounts are correctly configured. Cause: _reconcile_invoice_payments gathers the lines to reconcile with the rights of the caller and elevates only the final reconcile() cal
Original PR description
Steps to reproduce: - give a user the Point of Sale / User group only, without any accounting access right - open a session, sell a product to a customer and ask for an invoice Issue: The invoice is…
Steps to reproduce:
- give a user the Point of Sale / User group only, without any accounting access right
- open a session, sell a product to a customer and ask for an invoice
Issue:
The invoice is created and posted, but it is never reconciled with its payment: it stays fully due even though the journals and the accounts are correctly configured.
Cause:
_reconcile_invoice_payments gathers the lines to reconcile with the rights of the caller and elevates only the final reconcile() call. The payment moves it reads are linked to the order through account.move.pos_payment_ids, while rule_invoice_pos_user restricts a POS user to the moves matching [('pos_order_ids', '!=', False)], so those moves are not readable by a salesperson. Since saas-19.3, base_user_account_move_line_rule adds [('move_id', 'access', 'read')] on account.move.line, which propagates that restriction to the lines: payment_moves.pos_payment_ids.account_move_id.line_ids silently returns an empty recordset. reconcile() then gets the invoice receivable line alone and has nothing to match it with.
_create_payment_moves does return a sudo recordset, but _generate_pos_order_invoice accumulates it into self.env['account.move'] and the union of two recordsets keeps the env of its left operand, so the payment moves reach the helper back in the salesperson's env.
opw-6439389
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr14 changes
Resolved issues and error corrections
This fix adjusts an internal Belgian payroll test so it uses a normal working day instead of a Sunday. It prevents false test failures during leave validation, helping keep payroll maintenance and releases reliable without changing user-facing behavior.
Original PR description
The test `test_float_holiday_attest` fails with a ValidationError: "The following employees are not supposed to work during that period". The previous patch (cf. PR odoo/enterprise#107490) froze time to "2026-02-01 08:00:00", which was a Sunday. When validating the leave created for `today`, check of the employee's calendar fails because zero working hours are scheduled on weekends. This commit updates `@freeze_time` to "2026-02-02 08:00:00" (Monday) so the leave validation runs against a valid working day. runbot-240132 runbot-241193 Forward-Port-Of: odoo/enterprise#126391
French VAT reimbursement declarations now include the bank account holder's name in the account details section. This helps ensure declaration 3519 contains all required account information and reduces the risk of rejected or incomplete refund submissions.
Original PR description
For reimbursement declarations, the name of the holder of the account is required This commits adds holder's name to the account data zone no-task-id Forward-Port-Of: odoo/enterprise#127631 Forward-Port-Of: odoo/enterprise#127554
Barcode receipts now keep the putaway destination when users scan multiple lots for the same product. This prevents items from being split between the intended shelf and the default stock location, reducing warehouse confusion and manual corrections.
Original PR description
Steps to reproduce --- 1. Enable Storage Locations and Lots & Serial Numbers. 2. Add a putaway rule sending a lot-tracked product from WH/Stock to WH/Stock/Shelf 1. 3. Confirm a receipt reserving 2…
Steps to reproduce --- 1. Enable Storage Locations and Lots & Serial Numbers. 2. Add a putaway rule sending a lot-tracked product from WH/Stock to WH/Stock/Shelf 1. 3. Confirm a receipt reserving 2 units of that product; putaway sets the reserved move line destination to WH/Stock/Shelf 1. 4. In the Barcode app, scan a first lot, then a second lot. The second lot lands on a separate line at WH/Stock instead of WH/Stock/Shelf 1. Issue --- The first lot reuses the reserved line and keeps its Shelf 1 destination. The second lot cannot reuse it because its tracking number differs, so `_findLine` returns nothing and `_getNewLineDefaultValues` builds a new line with `location_dest_id` set to `_defaultDestLocation()`, the picking's default destination (WH/Stock). https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/stock_barcode/static/src/models/barcode_picking_model.js#L1591-L1601 Putaway relocates the destination on the move line at reservation, never on the picking, so only the reserved line carries Shelf 1. Since `groupKey` includes `location_dest_id`, the new line does not group with the first lot and shows separately at WH/Stock. This is not a regression: new lines have always defaulted to the operation destination. https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/stock_barcode/static/src/models/barcode_picking_model.js#L239-L241 The new line now inherits the selected line's `location_dest_id`, already relocated by putaway, instead of the default. opw-6317077 Forward-Port-Of: odoo/enterprise#125309
The Helpdesk Stock ticket screen now shows the Replace button even when no customer is selected. This keeps the action available in the same way as related buttons, reducing confusion for support teams handling stock-related helpdesk cases.
Original PR description
Adjust the `invisible` condition to make the button visible even if no customer is selected, for consistency with other buttons --- task-6103996 Forward-Port-Of: odoo/enterprise#124467
This fixes an issue where financial reports could show incorrect date ranges after switching between companies with different fiscal year setups. The report now selects the correct fiscal year based on the chosen end date, helping keep period-based reporting accurate.
Original PR description
Fix year-mode date filter when switching between companies with different fiscal years With two companies configured: one using a standard fiscal year and one using an offset fiscal year, switching between them could produce incorrect date ranges. This happened because the previous company’s `date_to` value was reused to compute the current period for the newly selected company, and vice versa. The fix is to use the `date_to` year instead and select the latest fiscal year ending in that same year.
Invoices in Peru that include lines without taxes now fail with a clear, handled message during batch sending instead of causing a generic system error. This prevents the background sending process from getting blocked and allows other invoices to continue being processed.
Original PR description
In l10n_pe_edi, invoices containing lines without tax can't be submitted to SUNAT.
When sending a single invoice, an error message is displayed. However, sending multiple invoices processes them in the background by a cron job. In this case, EDI document creation fails without error handling, raising a generic parsing error and blocking the cron from processing other invoices.
Steps to reproduce:
1. Create and post two invoices with no tax on some lines.
2. From the list view, select both invoices and click "Send" and mark "SUNAT".
3. An exception is raised: `ValueError: XMLSyntaxError("Start tag expected, '<' not found, line 1, column 1")`.
opw-6390480An automated accounting test was adjusted to match a related platform change in how grouped data is read. This keeps the accounting test suite aligned with the updated behavior and helps prevent false test failures during releases.
Original PR description
The fix at https://github.com/odoo/odoo/pull/281911 adds bin_size: tru in the web_read_group. This commit adpats an accounting test as a consequence Forward-Port-Of: odoo/enterprise#127638
The timesheet assistant layout now keeps duration values on one line, adds spacing, and allows long titles to wrap cleanly. This prevents overlapping text in chronological views, making timesheet entries easier to read and review.
Original PR description
- enforce duration in one line - add a gap between the title and duration - wrap title if so long - adapt flex direction of chronological view to avoid overlapping of title and start time --- task-6432434
This fix corrects how certain Swiss payroll tax mutation values are listed in declarations. It helps ensure submitted payroll information uses the expected official format, reducing the risk of reporting errors or follow-up corrections.
Original PR description
task-6116327 Forward-Port-Of: odoo/enterprise#127745
The timesheet assistant now preserves a project chosen by the user when switching between suggestions. This prevents accidental replacement of an unsaved project selection, reducing data entry mistakes and rework.
Original PR description
Steps to reproduce: - Select an unmatched suggestion. - Select Project A on the timesheet form (do not save it yet). - Select another suggestion matched to Project B. Observed behavior: Project A is overridden by Project B. Expected behavior: Project A remains selected on the timesheet. By initializing `project_id` with the current record's data, we prevent the suggestion loop from overwriting the user's manual selection. task-6410844 Forward-Port-Of: odoo/enterprise#126450
Fixed an issue that caused Deferred Revenue Report exports to fail when the report included annotations. Business users can now export annotated accounting reports to Excel without encountering a server error.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Unhide the **Start Date** and **End Date** fields on invoice lines. * Create and post a customer invoice with deferred dates. * Go to…
**Steps to reproduce:** * Install the **Accounting** module. * Unhide the **Start Date** and **End Date** fields on invoice lines. * Create and post a customer invoice with deferred dates. * Go to **Accounting → Reports → Deferred Revenue Report**. * Add an annotation to a deferred revenue line by clicking the **annotate** from three dots next to the account. * Export the report in **XLSX** format. **Observed behavior:** * The export fails with a server error: `UnboundLocalError: cannot access local variable 'annotations_x_offset' where it is not associated with a value` **Cause:** * The variable `annotations_x_offset` is assigned inside the `for header_level_index, header_level in enumerate(options['column_headers'])` loop, which writes the "Annotations" column header for each header level. * The Deferred Revenue Report produces an empty `column_headers` list, so the loop body never executes and `annotations_x_offset` is never assigned. * When the code later tries to write annotation data for each report line, it references the unassigned variable, causing Python to raise `UnboundLocalError`. **Fix:** * Introduce a boolean flag `annotations_header_written = False` before the header loop to explicitly track whether the "Annotations" column header has already been written. * Inside the header loop, set `annotations_header_written = True` after writing the header. * After writing all individual column headers (where `x_offset` already points to the first free column after all data columns), add a fallback: if `report_annotations` is set but `annotations_header_written` is still `False`, assign `annotations_x_offset` from the current `x_offset` and write the "Annotations" header. opw-6354473 Forward-Port-Of: odoo/enterprise#127726 Forward-Port-Of: odoo/enterprise#122768
Accounting users can now export Spanish VAT record books even when the report includes Point of Sale transactions. The report safely reads the needed POS data internally, preventing access errors while keeping normal user permissions unchanged.
Original PR description
Steps to reproduce:
- With an ES Company
- Open a POS session, add product with tax and pay
- As a user with only accounting access
- Go to Accouting > Reporting > Tax report
- Select Generic Tax report
- Print "VAT record Books"
Issue:
An AccessError will raise
```
Access Error
You are not allowed to access 'Point of Sale Session' (pos.session) records.
This operation is allowed for the following groups:
- Point of Sale/User
Contact your administrator to request access if necessary.
```
Analysis:
Vat Record Books handler for POS needs to read pos.session and pos.order records. Currently, the action is performed with the rights of the user running the report, so accounting-only user face an error.
As POS records are only read internally to build the report, we add sudo call to get the data.
opw-5862529
Forward-Port-Of: odoo/enterprise#126590
Forward-Port-Of: odoo/enterprise#125980Rejection notification emails now show the name of the person who declined to sign, rather than the email recipient's name. This prevents confusion for other parties involved in the signing process and makes document status updates more accurate.
Original PR description
**Description of the issue/feature this PR addresses:** When a document is rejected by a signer, the notification email sent to other involved parties incorrectly displays the recipient's name in the…
**Description of the issue/feature this PR addresses:** When a document is rejected by a signer, the notification email sent to other involved parties incorrectly displays the recipient's name in the subject line instead of the person who actually refused to sign. This occurs because the subject string was using `partner.name` (the current email recipient) instead of `refuser.name`. This commit updates the string to reference the refuser, ensuring the subject accurately identifies the individual who rejected the document. **Steps to reproduce:** - Sign > upload any PDF > add signature request for 2 different signers > Send > choose signers, e.g. Abigail Carter and Marc Demo > Send - Settings > Technical > Emails > Emails - Select one of the sent emails > Sign document > sign > Validate & Send Completed Document - Select the other email > Sign document > top-right dropdown arrow > Decline to sign > Decline - Settings > Technical > Emails > Emails - Observe that all emails sent state that the recipient of the email rejected the signing **Current behavior before PR:** - Rejection email subject states that the recipient refused to sign **Desired behavior after PR is merged:** - Rejection email subject states that the refuser refused to sign opw-6421188 Forward-Port-Of: odoo/enterprise#126412
Australian payroll submissions now check that required payslip or employee information exists before sending data to the ATO. Instead of an unexpected system error, users receive a clear validation message, helping payroll teams correct incomplete STP records more easily.
Original PR description
When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module -…
When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module - Switch to ``My australian Company`` - Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth - Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO Traceback: ```py IndexError: tuple index out of range ``` https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233 The traceback occurs because ``_get_fiscal_year_start()`` assumes that the STP record always contains at least one payslip or one employee. When these recordsets are empty, indexing the first element raises an IndexError. Solution: This commit validates that the required payslips or employees are present before the submission and raises a validation error instead of a traceback. Forward-Port-Of: odoo/enterprise#127733 Forward-Port-Of: odoo/enterprise#124096
6 changes
Resolved issues and error corrections
Annotated Deferred Revenue Reports can now be exported to Excel without triggering a server error. This helps accounting users reliably download reports even when the report has annotations and no standard column headers.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Unhide the **Start Date** and **End Date** fields on invoice lines. * Create and post a customer invoice with deferred dates. * Go to…
**Steps to reproduce:** * Install the **Accounting** module. * Unhide the **Start Date** and **End Date** fields on invoice lines. * Create and post a customer invoice with deferred dates. * Go to **Accounting → Reports → Deferred Revenue Report**. * Add an annotation to a deferred revenue line by clicking the **annotate** from three dots next to the account. * Export the report in **XLSX** format. **Observed behavior:** * The export fails with a server error: `UnboundLocalError: cannot access local variable 'annotations_x_offset' where it is not associated with a value` **Cause:** * The variable `annotations_x_offset` is assigned inside the `for header_level_index, header_level in enumerate(options['column_headers'])` loop, which writes the "Annotations" column header for each header level. * The Deferred Revenue Report produces an empty `column_headers` list, so the loop body never executes and `annotations_x_offset` is never assigned. * When the code later tries to write annotation data for each report line, it references the unassigned variable, causing Python to raise `UnboundLocalError`. **Fix:** * Introduce a boolean flag `annotations_header_written = False` before the header loop to explicitly track whether the "Annotations" column header has already been written. * Inside the header loop, set `annotations_header_written = True` after writing the header. * After writing all individual column headers (where `x_offset` already points to the first free column after all data columns), add a fallback: if `report_annotations` is set but `annotations_header_written` is still `False`, assign `annotations_x_offset` from the current `x_offset` and write the "Annotations" header. opw-6354473 Forward-Port-Of: odoo/enterprise#127726 Forward-Port-Of: odoo/enterprise#122768
Australian payroll submissions to the ATO now check that required payslip or employee data is present before submission. Instead of an unexpected system error, users receive a clear validation message, helping payroll teams correct the issue and continue safely.
Original PR description
When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module -…
When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module - Switch to ``My australian Company`` - Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth - Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO Traceback: ```py IndexError: tuple index out of range ``` https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233 The traceback occurs because ``_get_fiscal_year_start()`` assumes that the STP record always contains at least one payslip or one employee. When these recordsets are empty, indexing the first element raises an IndexError. Solution: This commit validates that the required payslips or employees are present before the submission and raises a validation error instead of a traceback. Forward-Port-Of: odoo/enterprise#127733 Forward-Port-Of: odoo/enterprise#124096
A payroll-related automated test was failing because it used a Sunday, when employees were not scheduled to work. The date has been changed to a Monday so the test reflects a valid working day and avoids false failures.
Original PR description
The test `test_float_holiday_attest` fails with a ValidationError: "The following employees are not supposed to work during that period". The previous patch (cf. PR odoo/enterprise#107490) froze time to "2026-02-01 08:00:00", which was a Sunday. When validating the leave created for `today`, check of the employee's calendar fails because zero working hours are scheduled on weekends. This commit updates `@freeze_time` to "2026-02-02 08:00:00" (Monday) so the leave validation runs against a valid working day. runbot-240132 runbot-241193 Forward-Port-Of: odoo/enterprise#126391
Historical Luxembourg payslips now use the wage index that was valid at the end of the payslip period, rather than today's index. This helps ensure past payroll calculations remain accurate and consistent with the period being processed.
Original PR description
Historical payslips incorrectly used today's wage index instead of the index active during the payslip period. Now, salary rules evaluate the indexed wage using `payslip.date_to` via the new `_get_l10n_lu_indexed_wage(date)` contract method. Task: 6395557 Forward-Port-Of: odoo/enterprise#125861
Large accounting reports now render fewer hidden rows, reducing page weight and improving responsiveness when users fold sections or search. This helps reports with thousands of lines feel faster and easier to navigate until the newer virtual grid solution is available.
Original PR description
When a report has 1 000+ lines, the DOM gets quite heavy which make DOM operation very slow. To help reduce this, we now will minimize the number of components rendered by removing components that previous were just hidden using "d-none" on the line. This will require more creation and suppression of components but it should make the DOM size smaller so it should help on larger reports where a lot of lines are hidden (by folding back a line, or by using the search bar). opw-6427411 opw-6442756 PR Note: this is only required until saas-19.5/20.0 since the virtual grids are added then which will resolve this issue since the virtual grids only render what's in the view of the user with long paddings on top and bottom so only ~70-80 lines are actually rendered. Forward-Port-Of: odoo/enterprise#127516
Payroll configuration now shows Mexico-specific CFDI settings only when the active company is based in Mexico. This avoids confusing or irrelevant options for companies operating in other countries.
Original PR description
Steps to reproduce: 1. Switch to a non-Mexican company. 2. Go to Payroll > Configuration > Settings. 3. The CFDI settings block is visible. Reason: The CFDI block was missing a country check. Solution: Restrict the CFDI block visibility to Mexican companies. Task-6448440 Forward-Port-Of: odoo/enterprise#127022
2 changes
Resolved issues and error corrections
Historical Luxembourg payslips now use the wage index that was active at the end of the payslip period, instead of using the current index. This helps ensure older payroll calculations remain accurate when wage index values change over time.
Original PR description
Historical payslips incorrectly used today's wage index instead of the index active during the payslip period. Now, salary rules evaluate the indexed wage using `payslip.date_to` via the new `_get_l10n_lu_indexed_wage(date)` contract method. Task: 6395557 Forward-Port-Of: odoo/enterprise#125861
Odoo now recognizes valid Brazilian electronic invoice XML files even when the invoice tag has no extra attributes. This prevents some vendor bills from being skipped during import, helping accounting teams process compliant invoices consistently.
Original PR description
### Issue before this commit: Certain valid Brazilian NF-e (electronic invoice) XML files fail to import because the system silently ignores them during the initial EDI recognition phase. ### Steps to reproduce the issue: 1. Download Accounting and l10n_br_edi 2. Go to Vendor > Bills 3. Try to import both xmls in the ticket 4. One of the two will not be imported correctly ### Cause of the issue: https://github.com/odoo/enterprise/blob/3ed1721b702555e96c9774969927f6517e855704/l10n_br_edi/models/account_move.py#L819-L827 This function relies on a strict byte string search for b"<NFe " while it's also correct if the tag is only `<NFe>`. ### Reason to introduce the fix: To make the initial NF-e file recognition more robust and compliant with standard XML namespace rules, ensuring Odoo successfully processes all valid Brazilian invoices regardless of attribute formatting. opw-6402843 Forward-Port-Of: odoo/enterprise#126881
7 changes
Resolved issues and error corrections
Odoo now correctly recognizes Brazilian electronic invoice XML files even when the main invoice tag has no extra attributes. This prevents valid vendor bills from being skipped during import, reducing manual handling and import failures for Brazilian accounting teams.
Original PR description
### Issue before this commit: Certain valid Brazilian NF-e (electronic invoice) XML files fail to import because the system silently ignores them during the initial EDI recognition phase. ### Steps to reproduce the issue: 1. Download Accounting and l10n_br_edi 2. Go to Vendor > Bills 3. Try to import both xmls in the ticket 4. One of the two will not be imported correctly ### Cause of the issue: https://github.com/odoo/enterprise/blob/3ed1721b702555e96c9774969927f6517e855704/l10n_br_edi/models/account_move.py#L819-L827 This function relies on a strict byte string search for b"<NFe " while it's also correct if the tag is only `<NFe>`. ### Reason to introduce the fix: To make the initial NF-e file recognition more robust and compliant with standard XML namespace rules, ensuring Odoo successfully processes all valid Brazilian invoices regardless of attribute formatting. opw-6402843 Forward-Port-Of: odoo/enterprise#126881
Fixes report printing through IoT devices so a completed print job is properly closed out. This prevents later connection errors after a successful print, reducing disruption for users who rely on IoT-connected printers.
Original PR description
The report printing logic was missing a call to `removeListener` on print success, resulting in an IoT connection error later, even on print success. opw-6469551 Forward-Port-Of: odoo/enterprise#127835
Luxembourg payroll now calculates indexed wages using the wage index that was active at the payslip period end date, rather than today's index. This helps ensure historical payslips and payroll records remain accurate when wage indexes change over time.
Original PR description
Historical payslips incorrectly used today's wage index instead of the index active during the payslip period. Now, salary rules evaluate the indexed wage using `payslip.date_to` via the new `_get_l10n_lu_indexed_wage(date)` contract method. Task: 6395557 Forward-Port-Of: odoo/enterprise#125861
The product catalog in Field Service now gives more space to the unit of measure column. This makes product information easier to read when adding items from a task, aligning the experience with the main Odoo catalog update.
Original PR description
Steps to produce: --- - Install `Field service` module. - Create a task and open it. - From the task open the catalog from smart button. Update the Product Catalog UI to match the Community PR changes. community PR: https://github.com/odoo/odoo/pull/267118 opw-6253382 ---
The Project Forecast settings no longer show the Time Management section unless the Timesheets app controls its visibility. This prevents users from seeing irrelevant configuration options when Timesheets is not installed.
Original PR description
**Steps to reproduce:** - Install the project_forecast module. - Go to Projects -> Open the settings of any project (create one if none exist) -> Settings. - You will see the Time Management section. **Issue:** The project_forecast module was forcefully setting the invisible attribute of group_time_managment to 0. This caused the group to remain visible at all times, even when the Timesheets app was not installed. **Fix:** Remove the forced attribute setting from the project_view. The visibility is already properly managed by the hr_timesheet module, and project_forecast does not depend on timesheet_grid or hr_timesheet. **Merge Till - SaaS-19.1 only, then from SaaS-19.2 : https://github.com/odoo/enterprise/pull/121454** task-6195716 Forward-Port-Of: odoo/enterprise#121565
The General Ledger CSV export now keeps accounts and transaction lines in the same order, even when multiple companies share account codes. This prevents export failures and helps users reliably download complete ledger reports.
Original PR description
Description of the issue this commit addresses: Account and move lines can be returned in different orders when account codes are shared across companies. The CSV generator can then exhaust its account iterator and raise StopIteration. --- Desired behavior after this commit is merged: This commit orders move lines using the account sequence returned by the report, keeping both CSV iterators aligned. --- runbot-[242131](https://runbot.odoo.com/odoo/error/242131) Forward-Port-Of: odoo/enterprise#126619
When loading the registry, borrow the request to avoid having using the cursor linked to it. Failing use case before the fix: install base odoo, in the web interface, activate and switch to a new language then install website. The installation will hang if the stable cache is invalidated because the installation may call `_` which will fallback to the request's language - reading the table from the request's cursor - while the installation tries to update the same of that same table in anothe
Original PR description
When loading the registry, borrow the request to avoid having using the cursor linked to it. Failing use case before the fix: install base odoo, in the web interface, activate and switch to a new language then install website. The installation will hang if the stable cache is invalidated because the installation may call `_` which will fallback to the request's language - reading the table from the request's cursor - while the installation tries to update the same of that same table in another cursor. Backport of odoo/odoo#281797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281798
19 changes
Resolved issues and error corrections
The Swiss payroll time off form layout has been corrected so HR users can view and complete the form more easily. This reduces confusion when managing employee absences in the Swiss payroll module.
Original PR description
This commit fixes the layout of the time off form view for the Swiss payroll module. task-6275864
This fixes a small compatibility issue in the UK tax reporting screen after a recent reporting framework update. Businesses using UK reports should see the HMRC submission button read report settings correctly, reducing the risk of errors when preparing submissions.
Original PR description
https://github.com/odoo/enterprise/commit/5da8982a0edf9655ef622f1937ebe2cb72abff07 ([IMP] account_reports: Report Virtual Grids and Reactivalypse) made `AccountReportController.options` a signal but forget a caller that (probably) landed in master after the author started its PR (but before he closed it) https://github.com/odoo/enterprise/commit/f648605aac92fa6414bb7ab5f9a4347c3bf7aa05
The AI tools now avoid loading full file contents when reading records, preventing oversized requests and improving reliability. For website-related AI use, file fields can still be referenced through a URL when needed instead of raw data.
Original PR description
Instead of using the binary field raw content and overflowing the context, we are searching with `bin_size=True`. This way, result will contain only binary field's size, instead of the raw content. However, in ai_website it might be useful to have an address of the field, instead of its size, as ai might need to use it.
This fixes an accounting transfer issue where journal entries could be off by one cent when transferring a percentage to a destination account. The destination line now uses the exact amount removed from source accounts, helping ensure generated entries stay balanced.
Original PR description
Before this commit, _get_transfer_move_lines_values computed the amount for the last destination line from the global transferred balance, instead of reusing the amount already removed from the source accounts. The two values are rounded independently and can differ by a cent whenever the removed amount comes from more than one rounded source, producing an unbalanced journal entry. Removing that condition the last destination line always absorbs the remainder fixes it. Steps to reproduce: 1. Transfer model with 2 source accounts and 1 destination line at 15%. 2. Post moves for the period: account A balance 395.88, account B balance 252.16 (total 648.04). 3. Run `action_perform_auto_transfer()`. Before: source lines -59.38 (395.88 * 15%) and -37.82 (252.16 * 15%), destination line +97.21 (648.04*15% rounded) -> entry off by 0.01. After: destination line takes the exact remainder, 97.20 -> balanced. OPW-6443928 Forward-Port-Of: odoo/enterprise#126877
Subscription product tiles in the online shop now calculate discounted recurring prices from the correct subscription plan price, not the one-time sale price. This prevents customers from seeing misleading monthly prices when a pricelist discount applies to a recurring plan.
Original PR description
Steps to reproduce: =================== 1. Create a subscription product, allow one-time sale, sale price 5 2. Add a recurring price 10/month 3. On the pricelist, add an advanced rule: -10% for the…
Steps to reproduce: =================== 1. Create a subscription product, allow one-time sale, sale price 5 2. Add a recurring price 10/month 3. On the pricelist, add an advanced rule: -10% for the monthly plan 4. Open the shop page and look at the product tile Cause: ======= On the /shop page, the subscription price displayed on a product tile is computed by `_get_sales_prices`. The cart has no plan selected yet at that point, so `request.cart.plan_id.id` is empty and was passed as `plan_id` to `_compute_price`. In `product.pricelist.item._compute_base_price`, the recurring base price is only looked up when a `plan_id` is given: if rule_base == 'list_price' and product.recurring_invoice and plan_id: ... # find the recurring rule -> base = recurring price With `plan_id` empty, that branch is skipped and the percentage rule falls back on the product's one-time `list_price` instead of the recurring price. Example: one-time price 5, recurring price 10/month, pricelist rule -10% on the monthly plan. => Tile showed 4.5/month (5 * 0.9) instead of 9/month (10 * 0.9). Solution: ========= The chosen pricing already targets a plan, so pass `pricing.plan_id.id` to `_compute_price`, matching what the product page does in `_get_additionnal_combination_info`. opw-6307398 Forward-Port-Of: odoo/enterprise#126259 Forward-Port-Of: odoo/enterprise#120872
The self-order test flow was adjusted because the takeaway option is now selected automatically when it is the only available choice. This keeps the validation aligned with the current customer experience and avoids false test failures.
Original PR description
In this commit: - The takeaway preset is now automatically selected when it is the only available option. Remove the explicit "Takeaway" selection step from the tour to match the updated behavior. Task:6217791 Community PR : https://github.com/odoo/odoo/pull/274301 Forward-Port-Of: odoo/enterprise#127350 Forward-Port-Of: odoo/enterprise#122979
Fixed an issue where Australian payroll could skip unused leave balances when processing multiple employees at once. Each payslip now checks leave allocations for the correct employee, helping ensure termination or final pay calculations include the right leave amounts.
Original PR description
`_l10n_au_get_unused_leave_by_type` compared leave allocations to `self.employee_id` while looping payslips. On a multi-recordset that is the whole employee set, so the match never holds and unused leave is skipped. Use `payslip.employee_id` so each payslip keeps its own allocations. task-6458480 Forward-Port-Of: odoo/enterprise#127330
Corrects an incorrect classification used in Swiss withholding tax mutation reporting. This helps payroll declarations use the expected official values, reducing the risk of rejected or inaccurate submissions.
Original PR description
task-6116327 Forward-Port-Of: odoo/enterprise#127745
The Planning menu now appears in the intended order when Field Service is installed. This avoids confusion for users who navigate Planning while preserving the normal menu structure for installations without Field Service.
Original PR description
Ensure the Planning menus are displayed in the correct order when Field Service is installed, without affecting the standard Planning menu structure. task-6443397 Forward-Port-Of: odoo/enterprise#127377
This fixes an internal automated test for payroll pay runs so it waits for the correct page to finish loading before continuing. The change reduces false test failures and helps keep payroll development and releases reliable without changing end-user payroll behavior.
Original PR description
Currently in payroll_payrun_tour in hr_payroll module, if we put step_delay as paramater in tour test. the tour test will get fail, after the validation in payslip step. When return to Payrun View Page, the next step to click New Button and Select the Payrun in the Dropdown option. But New Button with dropdown only available in the Payslip steps. The reason it works in runboot before due to race conditions where the test still click new button in Payslip step, expected there is dropdown in this view. The reason it's not work in with step_delay, because step_delay make we have time to change the payrun view, when we trigger the new button, the button is no longer reflected to Payslip step but in PayRun View. In this PR, expected to wait the tour test to fully reload the Payrun View before click the New button, so it will work with or without step_delay. task-6455499 Forward-Port-Of: odoo/enterprise#127204
VoIP contact searches now recognize phone numbers even when users type or receive an automatically added country code. This makes keypad suggestions and contact lookup more reliable and shows matched numbers in a clearer, user-friendly format.
Original PR description
Before this fix, the keypad's callee suggestions only matched the search term against the raw `phone` field of contacts. When the user input was automatically prefixed with a country code (e.g. +86), the match could fail if the stored phone number lacked the international prefix. Now `phone_sanitized` is also sent to the frontend via the Store, and the callee suggestion matching falls back to the E164 sanitized number when the raw phone field does not match. Task-6290760 compr https://github.com/odoo/odoo/pull/278018 Forward-Port-Of: odoo/enterprise#127553 Forward-Port-Of: odoo/enterprise#124797
When payroll users include additional unpaid payslips in a SEPA payment file, those payslips are now correctly marked as paid after using the payment confirmation action. This prevents payroll records from incorrectly remaining in a validated but unpaid state after payments are generated.
Original PR description
Steps to reproduce: - Open the payment report wizard on a payslip or a pay run - Tick "Include Unpaid" and keep the extra payslips selected - Generate the SEPA file, then click "Mark as Paid" Issue: the extra payslips listed in the file stay in state "validated". Cause: mark_as_paid() paid payslip_ids, while the file is built from unpaid_payslips. Fix: pay the payslips that are actually listed in the file. Task 6428919
The Generate Sample Data button now works even when ActivityWatch is connected. Users can view generated sample events together with their real activity data, making demos and testing easier without disconnecting ActivityWatch.
Original PR description
Before this commit, the Generate Sample Data button only worked when the ActivityWatch server was unavailable. When ActivityWatch was running, users could only load real activity data. After this commit, clicking Generate Sample Data while ActivityWatch is connected injects the generated sample events alongside the real ActivityWatch events, allowing both to be displayed together. task-6373606 Forward-Port-Of: odoo/enterprise#126498 Forward-Port-Of: odoo/enterprise#124981
Customers can now use Order Again for rental products even when their cart already has a changed rental period. The system reuses the cart's existing rental dates, preventing a false conflict that previously stopped the item from being added.
Original PR description
Steps to reproduce: --- - Install the `website_sale_renting` module. - Create a rental product, place an order for it with customer as `Administrator`, and confirm the order. - Open the order preview…
Steps to reproduce: --- - Install the `website_sale_renting` module. - Create a rental product, place an order for it with customer as `Administrator`, and confirm the order. - Open the order preview and click `Order Again`. - In the cart, modify the rental period. - Go to My Account > Your Orders, open the sales order, and click `Order Again` again. Issue: --- - Clicking Order Again a second time does nothing and - The following error is logged in the terminal: `You cannot mix different rental periods in the same order.` Root cause: --- - When the user clicks `Order Again`, the `/my/orders/reorder` route calls `add_to_cart`[1], which in turn invokes `_cart_add`[2]. If no rental dates are provided, `_cart_add` computes default rental dates based on the product's rental periodicity [3]. - However, when the current cart already has a rental period set, these computed dates differ from the cart's existing rental period. As a result, the rental consistency check detects the mismatch and prevents the product from being added to the cart. Solution: --- - When the current sale order already has a rental period set, reuse those dates instead of computing default ones. This ensures the product is added using the existing cart rental period and avoids the false conflict. [1]: https://github.com/odoo/odoo/blob/bb9fcbb062887ab6b1c4c17870201d789afa9dbc/addons/website_sale/controllers/reorder.py#L63-L76 [2]: https://github.com/odoo/odoo/blob/bb9fcbb062887ab6b1c4c17870201d789afa9dbc/addons/website_sale/controllers/cart.py#L134-L141 [3]: https://github.com/odoo/enterprise/blob/a39da12a4a85d749235d59a05ebd67b91f9867b0/website_sale_renting/models/sale_order.py#L60-L64 opw-6357001 --- Forward-Port-Of: odoo/enterprise#125481
Meal voucher reports now use the original voucher value when correcting postponed vouchers from a prior period. This prevents employees or employers from being charged using a newer meal voucher amount for vouchers that were actually issued at an older value.
Original PR description
**Purpose:** -In case of postponed Meal vouchers, it may happen that the value of (patronal part + employee part) change. -Example: - June → MV amount 8 € - July → MV amount 10€ -Employee received too many MV in June because some absences where encoded after the order of the MV. -In that case, it will be postponed on July but the employee will be charged for a MV of a value of 10€ while he received meal voucher of 8€. **Proposed Solution:** -The total has been adjusted by considering the original value for _meal_voucher_amount_ in case of postponed MV.
The Belgian payroll report now uses the previous quarter's contract when a mobility budget balance is paid after the current contract no longer includes that budget. This prevents the declared amount from incorrectly showing as zero, improving payroll compliance and reporting accuracy.
Original PR description
When the mobility budget balance is paid on a contract that no longer carries a mobility budget, fall back to the previous quarter's contract to declare the correct amount instead of 0. Task-6384786 Forward-Port-Of: odoo/enterprise#127786 Forward-Port-Of: odoo/enterprise#127318
Fixed an issue where users without certain accounting permissions could be blocked from confirming sales orders when a Studio approval rule referenced a restricted related field. The approval check now runs with the right elevated access so valid approval workflows continue without unexpected access errors.
Original PR description
continuation of [PR](https://github.com/odoo/enterprise/pull/121856) Issue: Inside _get_approval_spec filtered_domain is called a few times and due to a related field that calls an access rights group that the user who used the action isnt apart of is blocked by the filtered_domain. To Replicate: 1) Install studio, sale, Accounting and make sure "account_followup" is installed 2) create a related field on the sales.order form related to "customer -> follow up status" 3) Save 4) Create a "Studio Approval Rule" (studio.approval.rule) with a domain using the new related studio field -> method : "action_confirm" -> approver:admin 5)create a test user with no accounting access rights 6) in an incognito browser try and create a sales order, and then confirm it. it will throw the access rights error Solution: Go one up the stack where _get_approval_spec is called and add a syudo for those calls opw-6316069 Forward-Port-Of: odoo/enterprise#127412
Australian Single Touch Payroll submissions now check that required payslips or employees are present before sending data to the ATO. Instead of an unexpected system error, users receive a clear validation message, helping them correct incomplete payroll records before submission.
Original PR description
When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module -…
When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised. Steps to reproduce the error: - Install ``l10n_au_hr_payroll_account`` module - Switch to ``My australian Company`` - Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth - Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO Traceback: ```py IndexError: tuple index out of range ``` https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233 The traceback occurs because ``_get_fiscal_year_start()`` assumes that the STP record always contains at least one payslip or one employee. When these recordsets are empty, indexing the first element raises an IndexError. Solution: This commit validates that the required payslips or employees are present before the submission and raises a validation error instead of a traceback. Forward-Port-Of: odoo/enterprise#127733 Forward-Port-Of: odoo/enterprise#124096
This fix prevents the Sign app from crashing when a document field has an empty value and no automatic fallback value. Users can continue processing signature requests reliably even when optional fields are left blank.
Original PR description
Forward-Port-Of: odoo/enterprise#127426
1 change
Resolved issues and error corrections
A leftover "Request Appraisals" action that no longer worked has been removed from the Employees area. Users should use the existing "Launch Campaign" button to request appraisals for multiple employees, avoiding an error and keeping the workflow clear.
Original PR description
#### Description of the issue/feature this PR addresses: The "Request Appraisals" server action on hr.employee calls model._create_multi_appraisals(), a method that no longer exists. Running it…
#### Description of the issue/feature this PR addresses: The "Request Appraisals" server action on hr.employee calls model._create_multi_appraisals(), a method that no longer exists. Running it raises AttributeError: 'hr.employee' object has no attribute '_create_multi_appraisals'. #### Current behavior before PR: Commit 8845eb2ac29 replaced the multi-appraisal flow with hr.appraisal.campaign.wizard: it deleted _create_multi_appraisals and repointed the employee list header button to action_open_appraisal_campaign_wizard, but left the action_create_multi_appraisals record in hr_appraisal/views/hr_employee_views.xml. Its code is now the only reference to the deleted method, so the action crashes whenever it is run. #### Desired behavior after PR is merged: The dangling action is gone. Requesting appraisals for several employees at once is done with the "Launch Campaign" button already present in the Employees list view; action_open_appraisal_campaign_wizard reads active_ids when active_model is hr.employee and pre-fills the selected employees. Nothing references the removed xml id, and the record is not noupdate, so _process_end removes it from existing databases on update; no migration script is required. Verified on a 19.0 database: with the orphan record loaded, updating hr_appraisal with this change deletes it. opw-6408609
3 changes
Resolved issues and error corrections
This fix ensures successful report prints properly clean up their connection callback. It prevents later false IoT connection errors after a print has already completed successfully.
Original PR description
The report printing logic was missing a call to `removeListener` on print success, resulting in an IoT connection error later, even on print success. opw-6469551
This fixes an issue where a person listed more than once on a signature request could be prompted to sign again before earlier signers had completed their step. Signing requests now respect the configured order, reducing mistakes and ensuring documents follow the intended approval flow.
Original PR description
### Steps to Reproduce: 1. Create a sign request and have 3 total signers (User, Customer, Employee) 2. Enable Signing Order and make the order as follows: (1) User, (2) Customer, (3) Employee But…
### Steps to Reproduce: 1. Create a sign request and have 3 total signers (User, Customer, Employee) 2. Enable Signing Order and make the order as follows: (1) User, (2) Customer, (3) Employee But make the User and Employee the same contact 3. Send and sign the request > Notice that (1) is able to sign for (3) immediately after, (2) has not signed yet. ### Description of the issue/feature this PR addresses: **Issue:** The signing order is ignored when the same user has to sign multiple times on a document, even if it is configured for a different person to sign in between. This happens because all signature request items are initialized in the 'sent' state upon creation, rather than strictly advancing based on the order. As a result, the system prematurely allows users to sign out of order and prompts them with their next turn too early. **Solution:** To resolve this, the controller was updated to include an `is_mail_sent = True` domain filter. This ensures that the UI's post-sign popup only displays documents where it is explicitly the user's active turn, rather than prompting a premature sign. ### Current behavior before PR: Users are able to sign prematurely, and the system will disregard the configured signing order. ### Desired behavior after PR: Users will only be prompted and able to sign a document when it is explicitly their turn, per the `mail_sent_order`. This way, documents are signed in order. opw-6417327
Peruvian accounting reports now use the exchange rate already saved on each accounting entry instead of recalculating it later. This reduces rounding differences and helps produce more reliable reported amounts.
Original PR description
Previously, the `_get_ple_report_data` method computed the currency rate when called. Since the calculation was based on the entry totals, it was prone to rounding errors. This PR makes it use the rate stored in the entry itself. This should lead to more accurate results. opw-6411322
2 changes
Resolved issues and error corrections
When bank synchronization finds no new transactions, the reconciliation screen now shows an empty view instead of displaying transactions from all bank journals. This prevents confusion for companies using multiple bank journals and keeps the experience consistent with newer Odoo versions.
Original PR description
Currently, when we fetch zero transaction for an online account through bank synchronization, we open the bank reconciliation view with an empty domain, thus showing every transactions from every journals. This is confusing for the user if they have several bank journals. This commit now shows an empty bank reconciliation widget if no transactions are fetched. Additionally, this aligns with how it works in Odoo 19. [opw-6384718](https://www.odoo.com/mail/message/1138570272)
Invoice scanning now compares bank account numbers in the same cleaned format used by OCR. This helps match supplier IBANs more reliably when saved account numbers contain spaces, dots, or dashes.
Original PR description
When looking for a matching IBAN, we were searching on the `acc_number` field, which can contain spaces or special characters (dots, dashes, etc). But the OCR always returns the IBAN in a sanitized format, without any space or special characters, so it should be compared against the sanitized IBAN of the partners. task-none (issue found by chance)