Friday, August 1, 2025
12 changes · master
Resolved issues and error corrections
When a logged-in user is included as a signer, the signing workflow now takes them straight to their signing page instead of showing a confusing send dialog or notification. This reduces duplicate steps and makes it easier for employees or customers to complete documents promptly.
Original PR description
**Version:** - saas-18.3 **Steps to reproduce:** - Open a sign template. - Click "Send". - Add signers (include yourself). - Click "Send" to confirm. - The template is shown in preview mode. - Click "Sign Now". - A new "Send" dialog appears. - You have to add signers again. - Click "Send" again. **Issue:** - When the logged-in user is one of the signers, clicking the "Send" button shows a notification and not allows the user to sign. But clicking "Sign Now" again after that is confusing. **Solution:** - If the current user is a signer, clicking the "Send" button should directly open the sign view for that user to sign. task-4933608 Forward-Port-Of: odoo/enterprise#89943
Point of Sale kitchen printers connected through IoT now receive the full device information needed to print through the backup websocket connection. This prevents kitchen tickets from failing while regular receipts continue working, and helps avoid checkout screen errors when IoT devices were not recently updated.
Original PR description
Due to a missing `iot_id` field when the `DeviceController` for kitchen printers is instantiated, the websocket fallback does not work. This results in kitchen tickets failing to print even when regular receipts are working correctly. The fix is to provide the full IoT device model to the `DeviceController` constructor, as is done elsewhere. To do so we now pass the `device_id` field for the preparation printer model from the backend. We also ensure IoT devices/boxes are loaded even with a 'limited' load. This is because of an issue where an IoT device is added to the PoS config, but because the device itself has not be written to recently, the PoS doesn't load it and you get a traceback in the frontend. Forward-Port-Of: odoo/enterprise#91369 Forward-Port-Of: odoo/enterprise#91260
Sign template editing is now easier because edit buttons take users directly to the matching field. Template preview screens are cleaner by hiding unnecessary edit icons, and the document menu button now displays correctly.
Original PR description
Improved the sign_template_sidebar view by enabling pencil buttons to focus corresponding input fields for editing, and hidden the edit icons in template visualization mode for a cleaner experience. Additionally, fixed the document menu button to ensure proper display. task-4908825 Forward-Port-Of: odoo/enterprise#89884
Fixes the calculation of accident-related days in Swiss payroll reporting so employee payroll data is reported more accurately. This helps reduce payroll reporting errors and supports more reliable compliance processing for Swiss companies.
Original PR description
Forward-Port-Of: odoo/enterprise#91391 Forward-Port-Of: odoo/enterprise#91358
Vendor batch payments now use the correct payable account when matched with bank statements. This prevents accounting entries from being posted to the wrong partner account during reconciliation, improving financial accuracy.
Original PR description
**Steps to reproduce:** - Install accountant - Go to "Accounting / Vendors / Payments" - Create a payment: * Payment Type: Send * Vendor: [any] * Amount: 1000 - Confirm the payment - From payments list, select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -1000 * Memo: [anything] - Reconcile the statement with the batch payment **Issue:** The receivable account of the partner is used for the batch line instead of his payable account. **Solution:** Select the type of the account to use depending on the type of the payment. opw-4952786 Forward-Port-Of: odoo/enterprise#91354 Forward-Port-Of: odoo/enterprise#91206
Studio exports now retain several important customization fields that were previously left out automatically. This helps ensure exported Studio customizations, views, approvals, automations, and attachments can be restored or moved more reliably.
Original PR description
If you create a **StudioExportModel** with a model that we always export (for studio customizations, i.e. ir.ui.view) then the excluded_fields field gets computed. Before this commit, the _compute_excluded_fields method of the StudioExportModel model could have excluded some fields we would like to export. This commit fixes that. **List of fields we should export but by default were excluded:** - "base.automation": "action_server_ids" - "ir.model.fields": "selection" - "studio.approval.rule": ["approver_ids", "can_validate"] - "ir.ui.view": "arch" - "ir.attachment": "datas" task-4866474 Forward-Port-Of: odoo/enterprise#91409 Forward-Port-Of: odoo/enterprise#88125
Self-order kiosks can now print receipts through connected IoT devices as intended. The update adds the missing dependency and adjusts communication so receipt printing works even when kiosk users do not have a standard logged-in session.
Original PR description
The kiosk was updated to use iot http service to print receipt, but the dependancy was missing. This commit fixes the issue. We now override the iot http service to avoid using the orm as there is no session using self order, and use rpc calls instead. Forward-Port-Of: odoo/enterprise#90532
Subscription commission calculations now account for plan transfers during renewals, so salespeople are credited or debited according to the correct recurring plan rates. The update also prevents duplicate achievement lines when currency is missing and improves commission report performance for larger datasets.
Original PR description
PURPOSE In order to take into account the achievement rate based on recurring plan for MRR log on a renewal, we need to take into account transfer logs SPECIFICATIONS Take into account transfer logs…
PURPOSE
In order to take into account the achievement rate based on recurring plan for MRR log on a renewal, we need to take into account transfer logs
SPECIFICATIONS
Take into account transfer logs in achievements computation. Source should be clear that it's a transfer log of a renewal
Example:
If you have a Monthly sub to 100$/month but the yearly of 1000/year (MRR = 83.33) With a commission plan rewarding: 80% MRR of Monthly and 100% MRR of yearly
If you renew a montlhy into a yearly --> MRR that was 100 become 83,33 so you have a negative MRR so a negative commission and a negative on yearly so with more weight (100% instead of 80)
Current:
Renew in into yearly: 100% of MRR change -16.67 = -$16.67
New monthly 80% of MRR change $100 = $80
Total = 63.33 (modifié)
New
New monthly 80% of MRR change $100 = $80
Transfer 1 : 80% of MRR change -100 = -$80
Transfer 2 : 100% of MRR change +100 = +$100
Contraction of MRR: 100% of MRR change -16.67 = -$16.67
Total = 83.33
Moreover this PR:
- fix a bug when achievements were duplicated when no currency was set.
- improve performances by creating a temporary table for invoice rules.
taskid-4783929
Forward-Port-Of: odoo/enterprise#91045
Forward-Port-Of: odoo/enterprise#88646Users who manage timesheets but do not have Project access can now open Timesheet list and kanban views without being blocked by an access error. This keeps timesheet administration usable for teams with restricted project permissions while preserving existing access rules.
Original PR description
Steps to Reproduce: - Ensure the `timesheet_grid_holidays` module is installed. - Log in as a user with Timesheets Administrator access but no access to the Project module. - Navigate to the Timesheets > List or Kanban view. - An `AccessError` occurs due to missing read rights on the `project.task` model. Cause: - In the `timesheet_grid_holidays` module, the `_should_not_display_timer` method accesses `self.task_id.is_timeoff_task` without checking access rights, causing an `AccessError` when users who can view timesheets but lack read access to `project.task` try to access tasks linked to projects with private privacy visibility. Solution: - Use `sudo()` when accessing `self.task_id` in `_should_not_display_timer()` to avoid access errors. task-4798066 Forward-Port-Of: odoo/enterprise#91361 Forward-Port-Of: odoo/enterprise#86302
Payroll payment reports now use the company linked to the payslip batch instead of whichever company is currently selected. This helps multi-company payroll users avoid incorrect company details on payment reports.
Original PR description
Steps to reproduce: - install payroll and create a batch - generate payslips - select multiple companies. - Click on "Create Payment Report." - create any payment method issue: - The report displays the currently selected company instead of the one associated with the payslip batch. reason - the default company is given on the field which is self.env.company fix - now the company field is computed to the payslip company task-4643306 Forward-Port-Of: odoo/enterprise#91233 Forward-Port-Of: odoo/enterprise#81812
Appointments in the evening before an all-day event are no longer incorrectly marked as unavailable because of timezone differences. This helps businesses avoid losing valid booking slots, especially for users in timezones where local evenings cross into the next UTC day.
Original PR description
All-day calendar events were incorrectly causing unavailability for appointment slots scheduled on the previous evening, due to mismatches between local time and UTC. Previously, all-day events…
All-day calendar events were incorrectly causing unavailability for appointment slots scheduled on the previous evening, due to mismatches between local time and UTC. Previously, all-day events scheduled for Tuesday were stored with a start time of 00:00 UTC. In timezones like America/Chicago, this corresponds to 7:00 PM Monday. As a result, a valid appointment booked from 6:30 PM to 8:00 PM local time on Monday would partially fall into Tuesday in UTC (ending at 01:00 UTC), causing a false conflict with Tuesday’s all-day event. The `calendar_verify_availability` method now calls the newly added `_get_date_boundaries` which than computes naive datetime boundaries based on the user's local timezone by taking the end of the previous local day and the start of the next local day. This change resolves those edge cases where evening slots crossing the UTC boundary were falsely marked as unavailable due to timezone misalignment. opw-4614544 Forward-Port-Of: odoo/enterprise#91398 Forward-Port-Of: odoo/enterprise#85654
The Barcode app now refreshes correctly after a quality check wizard is closed, so required quality check buttons reappear when needed. This helps warehouse users avoid missing required checks and makes the quality control flow more reliable.
Original PR description
Description of the issue/feature this PR addresses: The two buttons to open quality check and demand a quality check in the Barcode app are set in an override of MainComponent It would be better to set them in the BarcodeModel class like we do for the validate() button for instance (see enterprise/stock_barcode_quality_control/static/src/components/main.js) Current behavior before PR: - When closing quality check wizard without doing quality checks the quality check button would not appear (see screen recording below) Desired behavior after PR is merged: - When closing the qualityy check wizard force a page refresh to show the Quality check button if they are required task: 4825608 screen recording of QC button refresh issue: https://drive.google.com/file/d/1cVPwgp70Ivrnjufb6x9XdawXI9JYaH0n/view?usp=drive_link I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)