Daily updates from Odoo
Tuesday, July 1, 2025
16 changes · master
Enhancements to existing features
Salary offers can now include a contract end date. When an offer is accepted and the employee contract is created, that end date is automatically applied, reducing manual follow-up and improving contract accuracy.
Original PR description
this commit added contract end date in offer, If the offer contract end date is set, then the created contract will have the end date field populated task- 4853216
Payroll payment reports now use the clearer label “payment date,” and payslips are automatically updated with that date. US payslip layouts are simplified to show the payment date, hide less relevant employee details, and display only the last four digits of bank accounts for clearer employee communication.
Original PR description
When creating a payment report, the user must can choose the effective date. The term is ambiguous and is replaced by this commit by payment date. Additonnaly, the pay_date field on the payslip is automatically filled according to the payment date of the attached payment report. Also, this PR improves the US payslip template to better follow best practices: - The payment date is added - The job position, department and worked days are hidden - The phrasing of the bottom sentence has been changed and only the last four digits of the bank account are shown task-4814800
Australian payroll rule parameters have been updated for the 2025 period. This helps ensure payroll calculations use the latest applicable values, supporting accurate payslips and compliance for Australian employees.
Original PR description
Forward-Port-Of: odoo/enterprise#88323
Appointment sharing links are now generated in one consistent place, reducing duplicate behavior across calendar, form, Kanban, and Gantt flows. Users get cleaner name-based links when possible, fewer duplicate invites, and more reliable link editing and creation.
Original PR description
Purpose: The short_code generation mechanism is made central, such that Kanban, Form, and Gantt views' share invite's code duplication can be avoided. Specifications: 1. Generate a unique link. Case…
Purpose: The short_code generation mechanism is made central, such that Kanban, Form, and Gantt views' share invite's code duplication can be avoided. Specifications: 1. Generate a unique link. Case 1: Generate name based link when no link exists for the appointment eg. /schedule-a-demo. Case 2: If a link exists for the appointment: Retrieve the existing link for the current configuration, or else generate a random code. 2. Avoid invite duplication on appointment duplication. 3. Change the button string from Cancel to Discard and short_code_unique_warning in view appointment_invite_view_form. 4. Remove AppointmentInviteViewFormController and associated files, as the same code is done on the server side to avoid code duplication. 5. Generate an appointment name-based link(if the link does not exist)for the appointment listed in the dropdown on the calendar side. 6. We can now alter the short_code of existing link and generate a new link. 7. Set default appointment type when we click on New btn in list view of links of the appointment. 8. Update the appointment name which is created via 'Share Calendar' click. 9. Test case has been created so above functional flow doesn't break. Task-4610207 Co-authored-by: Aurélien awa@odoo.com
Belgian payroll now places the ONSS CO2 fee before the employer ONSS contribution and includes it in that employer contribution total. This helps ensure payslip calculations and reporting better reflect the required treatment of company car CO2 fees.
Original PR description
The ONSS CO2 Fee must appear before the ONSS employer rule and included in its sum. task-3506696
The Partner Ledger no longer shows debit and credit amounts on initial balance and total lines. This reduces confusion from large historical amounts that do not relate directly to the selected reporting period.
Original PR description
Users are sometimes confused because Debit and Credit can show quite high amounts not related to the present period because of the initial balance. We hide these columns for the initial balances, and to remain consistent, for the totals as well in the partner ledger. taskid: 4261294
Resolved issues and error corrections
Users who work across a parent company and its branch can now open the Profit and Loss report without hitting an access error. The fix ensures journal currency information is read safely when the user has limited settings permissions.
Original PR description
This commit is the counterpart of a commit in community to add a test. ### Steps to reproduce: - Create a branch to a company - Create a journal on the parent company with a different currency from the company - Create a user that can access both the parent company and the branch, but can't change the settings of Odoo - Log as this user, select only the branch as current company - Accounting > Reporting > Profit & Loss - Access Error ### Cause: `_compute_display_name` on the journal reads `journal.company_id.currency_id` without sudo. The current user cannot read on `company_id` because of the rule `res_company_rule_employee`. ### Solution: Use `sudo()` to read the currency of the company. opw-4847500 Linked PR: https://github.com/odoo/odoo/pull/215455 Forward-Port-Of: odoo/enterprise#88848 Forward-Port-Of: odoo/enterprise#88339
Fixed an issue where child companies with their own VAT number did not receive the expected VAT return records. This ensures businesses using company branches can access and manage the correct tax returns for each eligible child company.
Original PR description
Steps to reproduce: - Create a company (for example a Belgian one) and set the vat - Create a child company with same country, but different vat - set the account opening date for both companies - open the tax returns page with the child company -> the child company should have VAT returns associated, because it's the main company for the vat branch, but it doesn't contain anything Forward-Port-Of: odoo/enterprise#88868 Forward-Port-Of: odoo/enterprise#88061
This fixes an issue where discounts on regular sales order lines could be unintentionally reset when subscriptions were saved, invoiced, or closed. Businesses using subscriptions alongside one-time sale items can now keep manually entered discounts intact, reducing billing errors and manual corrections.
Original PR description
**Issue 1** - Have a pricelist with the "Discount policy" == "without_discount" - Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line - Set a discount on both lines…
**Issue 1** - Have a pricelist with the "Discount policy" == "without_discount" - Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line - Set a discount on both lines - Save the SO - Issue: the discount on the non-subscription line has been reset to 0.0 **Issue 2** - Using the previous SO, add back a discount value for the non-subscription line - Confirm the SO and invoice it - Close the subscription - Issue: the discount on the non-subscription line has been reset to 0.0 **Cause** Both issues come from the fact that `order_id.subscription_state` is a dependency of `_compute_discount` in `sale_subscription`. The super is called for non-subscription lines, recomputing the discount. **Solution** It is not possible to know which dependency triggered the compute, therefore the solutions are to: - avoid a recompute at creation after the `web_save` by not writing on the `subscription_state` field if not necessary - avoid calling super for lines if the subscription is closed opw-4645579 Forward-Port-Of: odoo/enterprise#88816 Forward-Port-Of: odoo/enterprise#84754
This fix ensures overtime is paid on top of an employee's regular fixed wage instead of reducing the calculated hourly rate. It also prevents casual loading from being incorrectly applied to overtime, improving payroll accuracy for Australian employees.
Original PR description
Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a…
Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week. 2. The created payslip is of correct amount with the standard 40-hours work week. 3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts. Current behavior: The total remains 2000 and the computed hourly rate becomes 2000/44=45.45 Expected behavior: The hourly rate should remain the same 50. The total should increase to be: fixed_wage + hourly_rate * overtime hours 2000 + 50 * 4 = 2200 Fix: 1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate. 2.The casual loading rate should not apply to Overtime work entry types. task-4617681 Forward-Port-Of: odoo/enterprise#88100 Forward-Port-Of: odoo/enterprise#83171
Fixes an issue where enabling form access in Website Studio was not applied when saving a form. The change also makes form access edits part of the change history and clarifies the option with a tooltip, reducing confusion for website editors.
Original PR description
When [1] converted the form access option to fit inside `html_builder`, the form access was supposed to be enabled upon saving a form, but the used selector was incorrect, which led to the form access not being enabled. Also, a `ModelCache` was created which kept track of the same model but according to various ways to write this key. This system was flawed and led to reaching distinct object depending on the used "synonym" key. This commit: - fixes the selector used during the save operation - removes `ModelCache` and uses a plain cache with the model name as key in all situations - makes changes to form access included in the history - adds a tooltip on that confusing option [1]: https://github.com/odoo/enterprise/commit/689a2186fbe3b932b90bef3b64716c8443bad551 task-4367641 Forward-Port-Of: odoo/enterprise#88271
This fixes an issue where Chilean POS invoice settlement always showed $1 instead of the actual outstanding amount. The correct unsettled invoice amount is now loaded, helping cashiers collect the right payment and avoid manual corrections.
Original PR description
**Problem:** When trying to settle an order in POS with a Chilean company, the amount to be settle will be 1$, regardless of how much needed to be settled. **Steps to reproduce:** - Set the company to a Chilean company. - Make an invoice for a Chilean customer and confirm it. - Go to pos, and click settle invoices for your client, chose the invoice you just made. - The amount will be 1$ **Why the fix:** The field *pos_amount_unsettled* was not loaded into the invoice if the company is from Chile. It resulted in it being undefined, thus it was set to 1 afterwards. We now load this variable into the invoice when loading the data. opw-4856764 Forward-Port-Of: odoo/enterprise#87881
Portal users using a shared project folder link can now upload documents without running into an access error. This keeps external collaboration working as intended when project folders are shared with upload permissions.
Original PR description
To reproduce: ============= - install documents_project - create project - go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload) - open the share link in a new browser window and connect as portal user - upload a document -> access error Problem: ======== while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project Solution: ======== read as `sudo` opw-4782062 Forward-Port-Of: odoo/enterprise#88427 Forward-Port-Of: odoo/enterprise#87301
Accounting PDF reports in right-to-left languages now fit properly on the page when many columns are included. This prevents printed reports such as Aged Payable from being cut off, improving readability for users working in RTL languages.
Original PR description
Steps to reproduce: - Set language to RTL Orientation - Go to Accounting > Reporting > Aged Payable - Add multiple columns to report - Print as PDF Issue: When enough columns have been added to the report, the report will overflow the right side of the page Cause: Wkhtmltopdf does not correctly shrink the table if the direction is specified on the body of the document opw-4746361 Forward-Port-Of: odoo/enterprise#88770 Forward-Port-Of: odoo/enterprise#87520
Kenyan eTIMS invoice submissions that time out are now checked before being retried. If the invoice was already accepted, Odoo retrieves the official details such as the QR code instead of sending it again, reducing the risk of duplicate government invoices.
Original PR description
When a timeout occurs during invoice submission to eTIMS, we had no way to know if the invoice was actually received. Retrying could lead to duplicate invoices being accepted by the government. With the release of the selectInvoiceDetails endpoint, we now check if the invoice was already submitted before retrying. If found, we treat it as successfully sent and retrieve its details (QR code, etc). If not, we proceed to resend. task-4863787 Forward-Port-Of: odoo/enterprise#88858 Forward-Port-Of: odoo/enterprise#88608
Spreadsheet dashboards now apply date filters using the correct time-aware field type, so results better match each user's timezone. This prevents records from being incorrectly included or excluded around date boundaries in newly updated dashboard data.
Original PR description
The generated domain is wrong when filtering on the date. It doesn't account for the user timezone because the field matching is given as a "date" field instead of being a "datetime".
The generated domain looks like `[("create_date", ">=", "2025-06-27")]` instead of `[("create_date", ">=", "2025-06-27 21:59:59")]`
I'm fixing this in 18.0 because this fix won't affect existing databases (without updating the modules). The fix would be useless and I don't want to go though the pain of forward-ports for nothing. New databases are created in 18.0 every day (latest LTS)
Task: 4903362
Forward-Port-Of: odoo/enterprise#88807
Forward-Port-Of: odoo/enterprise#88730