Tuesday, March 10, 2026
15 changes · saas-19.2
New functionality added to Odoo
This update adds two new Book of Accounts reports – Cash Receipts and Cash Disbursement Journals – specifically designed for Philippine accounting needs. These reports now accurately capture cash flow data by directly analyzing the General Ledger, addressing previous limitations with manual journal entries and in-transit funds, leading to more reliable financial reporting.
Original PR description
## [IMP] l10n_ph_reports: add cash receipt/disbursement report Adds two new Book of Accounts reports: - Cash Receipts Journal - Cash Disbursement Journal Instead of strictly filtering by `account.payment` links, these reports now derive cash flows directly from the General Ledger's liquidity lines (Bank, Cash, Credit Cards, and Outstanding clearing accounts) because it: 1. Catches manual journal entries that affect cash but lack payment records. 2. Captures in-transit funds sitting in Outstanding Receipts/Payments before bank reconciliation. 3. Categorizes transactions accurately by their actual GL impact (Debit = Receipt, Credit = Disbursement), inherently fixing edge cases like negative receipts (refunds). task-[5116323](https://www.odoo.com/odoo/project.task/5116323)
Enhancements to existing features
This update enhances the generation of WPS files required for AE companies, focusing on compliance and ease of use for users. Key changes include stricter data validation, improved bank account linking, and the ability to export WPS reports in Excel format. This ensures accurate and reliable WPS file creation for payroll reporting.
Original PR description
This commit aims to make the generation of wps files for AE companies more compliant and intuitive for the user, by: - Updating string for l10n_ae_employer_reference field - Domaining the company's salary bank account to accounts that belong to the company - Enabling the export of xlsx wps report - Preventing negative values in EVP section of the wps file - Adding constrains to the employer code as per expected format - Changing the names of allowance inputs - Adding a new category for evp rules - Making sure clearing number is only 9 digits as per expected format task-5884696 Forward-Port-Of: odoo/enterprise#109404 Forward-Port-Of: odoo/enterprise#107218
Resolved issues and error corrections
This update fixes a problem where the Gantt view for service projects would crash when grouping by project. The issue stemmed from an outdated date format being used for domain filtering. The fix ensures dates are correctly parsed, allowing the Gantt view to function properly.
Original PR description
### Issue: When in the Gantt view of service projects, grouping by project results in a traceback. ### Steps to reproduce: - Create another field service project - Create a task in the new project…
### Issue: When in the Gantt view of service projects, grouping by project results in a traceback. ### Steps to reproduce: - Create another field service project - Create a task in the new project and add start and end dates - Go to Field service > my tasks > gantt view > group by project - Error with traceback `time data 'today' does not match format '%Y-%m-%d %H:%M:%S'` ### Cause: This [commit](https://github.com/odoo/odoo/commit/d1ea43f6721116914762ea323d8a5987f043e87f) added the possibility to use dynamic dates in domains. Then all domains were changed in 42b1fca8e127926a06f503d79c8baeddf7d5ae82 But `_expand_domain_dates()` is trying to parse the dates as if they were written in ISO format: https://github.com/odoo/enterprise/blob/be853cc1ee544dda580960d94417cfdff2c8a7db/project_enterprise/models/project_task.py#L626 ### Solution: We use the method `parse_date()`, which was added with dynamic dates, to parse them. opw-5955317 Forward-Port-Of: odoo/enterprise#109236
This update fixes an issue where new timesheets weren't correctly selecting the appropriate Service Order Line (SOL) when creating them in a multi-company setup. It ensures the timesheet now uses the correct SOL linked to the user's billing rates, regardless of the company being used, improving accuracy in billing.
Original PR description
****Behavior:**** **Current:** In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific…
****Behavior:**** **Current:** In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific task, creating a new timesheet for the project does not set the correct SOL. This only happens if the sale is happening from a company that does not have an employee linked to the user. **Expected:** The new timesheet should be able to connect the current user to the related employee in the billing rates to find the right SOL. In the situation in which multiple companies have created an employee for the same user, and more than one of these has been linked to a SOL in the billing rates (unlikely workflow): We choose the SOL linked to the employee record created for the currently activated company, otherwise, we default to the first employee in the list. **Steps to reproduce:** - Be in a multicompany environment: company A and B - Create User with access to both but only one employee record for company A - Switch to company B - Create 2 services product, both creating a task in the same project. - Activate Billable Rate Indicators in the settings - Create a quote with both services and confirm - Go to the related project, and in the Invoicing tab, link employee from company A to SOL2 - As the user, check both companies but set company B as current active - Go to timesheet and create a new timesheet, when setting the project from the quote, you should see SOL1 by default, however we would want SOL2 as it was configured. opw-5159195 Forward-Port-Of: odoo/odoo#234200
This update enhances the Time Off Gantt view by displaying total worked hours in the progress bar and streamlining actions. The 'Save' button has been removed, replaced with 'Approve' and 'Refuse' buttons for direct approval/rejection, and a 'Reset' button has been removed. These changes improve the user experience and efficiency of managing time off requests.
Original PR description
Changes Show total worked hours in the progress bar before the employee name. Remove the Save button from the popover and add Approve and Refuse buttons for direct action. Remove the Reset button from the Gantt view. UX improvements: Show the deferred icon on the pill. Fix popover margins and remove unnecessary message. task-5941368
This update fixes an issue where the working time assigned to tasks wasn't accurately calculated when a company's holiday was active. The fix ensures that the correct working time is applied, considering company-specific holidays, and allows users to view and enable hidden fields for accurate time tracking.
Original PR description
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2…
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation Nothing happens When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546 The company isn't taken into account in the domain, applying the holiday for every company. __ opw-5222883 Forward-Port-Of: odoo/odoo#248725 Forward-Port-Of: odoo/odoo#246994
This update fixes an issue where instructions added to work orders weren't correctly linked when creating purchase orders (MOs) via the mobile app. The problem stemmed from a previous change that prevented the necessary data from being passed to the server. This ensures that instructions from the BOM are now properly associated with the MO, improving the mobile workflow for shop floor operations.
Original PR description
# How to reproduce - Create a BOM for a product with a Work Order - Add instructions to the WO - Using mobile, create a new MO for the product # The problem The instructions are not linked to the MO. This can easily be seen via the shop floor application # Why This issue is identical to https://github.com/odoo/odoo/pull/197889. This commit https://github.com/odoo/odoo/commit/b1ceec4c616d8ad2fee5b0fa1ce76c85cacbb344 removed the operation_id field from the workorder kanban mobile view, which is used in the MO form on mobile. operation_id is then not passed to the server in vals_list when creating the MO but it is required to link the instructions from the BOM to the MO. opw-5950983 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250090
This update fixes an issue where flexible calendar employees were incorrectly displaying grayed-out days in planning and related modules. The change ensures that only public holidays and leaves are reflected as unavailable, providing a more accurate representation of employee availability. This improves the usability of the planning app for employees with flexible work schedules.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
opw-4879481
Forward-Port-Of: odoo/odoo#252285
Forward-Port-Of: odoo/odoo#245741This update fixes an issue where flexible calendar employees were incorrectly displaying grayed-out days in planning and related modules. The change ensures that only public holidays and leaves are reflected as unavailable, providing a more accurate representation of employee availability. This improves the planning experience for teams utilizing flexible work schedules.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
Forward-Port-Of: odoo/enterprise#109706
Forward-Port-Of: odoo/enterprise#105521This update resolves several issues related to shift scheduling and resource allocation within the planning module. Specifically, it corrects errors in how allocated time is calculated, ensures accurate comparisons of shifts, and improves the mobile user experience for viewing maps and managing interventions. These fixes enhance the reliability and usability of the planning system.
Original PR description
## [FIX] planning: make sure allocated_percentage is defined in the view Before this commit, since we remove the allocated percentage field from the form view, the framework js does not know that…
## [FIX] planning: make sure allocated_percentage is defined in the view
Before this commit, since we remove the allocated percentage field from
the form view, the framework js does not know that field has a default
value and so it will set 0 by default for the float field and give it as
parameter when it will request an onchange when the user wants to create
a new shift.
This commit makes sure the field is inside the form view to be sure the
default value is taken into account to correctly compute the
allocated_hours.
## [FIX] planning: make sure we compare apples with apples
Before this commit, the copy previous week action in planning.slot could
crash because values for new shifts could contain Commands in
`resource_ids` field.
This commit makes sure we convert those commands into resource ids to be
able to compare those ids with the ones on the shift processed.
## [FIX] planning_field_service: display map view in mobile in My Map
Before this commit, the `My Map` action displays the calendar view in
mobile instead of the map view.
This commit makes sure we first display the map view in any device when
`My Map` action is loaded.
## [FIX] planning_field_service: hide field service buttons when slot not published
Before this commit, some buttons in planning.slot were visible even if
the intervention is not published or in progress.
This commit makes sure the buttons are visible when the state of the
intervention is published or in progress depending on what is the
purpose of the button.
## [FIX] planning_field_service: open full form view in calendar
This commit makes sure the form view is fully opened in the calendar
view of planning.slot instead of opening it inside a modal.
## [FIX] web_gantt: undo the rechescule of shifts and keep resources set
Before this commit, when the user reschedules a shift by drag and
dropping a pill in the gantt view and the group by is by Resources, if
the shift was assigned to more than one resource and the user undo his
action, the shift will be assigned to only the resource where the pill
was before the drag and drop instead of keeping its initial resources
set.
This commit makes sure the resources which were assigned to shift are
correctly set once the user undo the reschedule made.
## [FIX] planning_holidays: correctly compute the search domain for is_absent
Before this commit, the `employees on time off` filter does not return
the shifts with at least one human resource off due to wrong calculation
made in the search method of `is_absent` field defined in
`planning.slot` model.
This commit fixes the issue to correctly show the shifts with at least
one human resource off in the period of the shift.
## [FIX] planning_field_service_{sale_timesheet,worksheet}: display photos before materials
This commit makes sure the Photos button is before the one to add
materials in the intervention.
## [FIX] planning: display icon instead of label in calendar view
This commit reviews the popover in the calendar view of planning.slot to
replace the label by the icon to let more space for the value of each
fields displayed in that popover.
It also display in week by default the calendar view of planning slot in
My planning menu
## [FIX] planning: don't send re-assign email when one more resource is assigned
Before this commit, when the user edits a shift to add an additional
resource to the shift, the resource initially assigned to the shift will
receive a re-assign email even if he is still assigned to the shift.
This commit makes sure the email is sent only when the resource is no
longer assigned to the shift.
## [FIX] planning_field_service: add navigation map button to popovers and some fixes
This commit mainly adds a button to easily redirect the user to google
map with the customer address.
## [FIX] planning: don't show seconds in allocated_hours field
Before this commit, due to a rework of duration format, the allocated
hours now displays the seconds which is not really needed and take more
space than expected.
This commit makes sure we don't display the seconds in the allocated
hours field of planning.slot since that information is not really
useful.
## [FIX] planning{_field_service}: simplify display_name and conflicts warning
This commit simplifies the conflict warning in the form to have a
minimal warning message. The display name has been reviewed to only
display partner_id and role_id if partner_id otherwise project_id and
role_id will be displayed.
## [FIX] planning: don't include material resources when a human resource is set
This commit removes the material resources in the compute allocated
hours when there is at least one human resource set with it since we
could assume the material resources will just be used by the human
resource(s) assigned to the shift.
## [FIX] planning_field_service: fix geolocation when sign_in/complete intervention
Before this commit, the geolocation feature does not work because it was
only done in sign in button in calendar popover of planning.slot but the
feature is also needed when the user clicks on sign in and complete
buttons in the other views of planning.slot.
This commit makes sure the geolocation feature works in any view where
the sign in and complete buttons are currently displayed.
## [FIX] planning_field_service: add subtypes
## [FIX] planning: don't generate shifts in multi create when no resource available
Before this commit, when the user wants to create multiple shifts for a
certain resource in the gantt to cover a whole week (weekend included),
the shifts in the weekend will be generated as open shift since the
resource does not work during the weekend. Actually, the shifts should
not be generated in non working day for the resource.
This commit makes sure the shifts are not generated in non working day
of a resource selected.
## [FIX] planning_field_service: facilitate the work of planning manager
Before this commit, the planning manager cannot sign in for one of his
workers in the case, one worker forgot to do it and the intervention is
in the past. Hide price feature does not work correctly because the
check to know if the feature is enabled or not does not take the right
setting (wrong module because the feature has been moved before the
merging the main task).
This commit make sure the sign in button is available even if the
intervention is in the past. Some wordings have been reviewed and fix
typo to correctly check if hide price is enabled or not in the setting
of planning.
This commit also hides some fields for planning user when field service
is enabled in planning to only show the most important information for
the workers.
## [FIX] planning_field_service: add Today filter by default in My Map
## [FIX] planning_field_service: sign-in should recompute end date when needed
Before this commit, since the user can sign in when the shift is in the
past, we need to recompute the end_datetime to make sure the
end_datetime set is not before the start_datetime.
This commit recomputes the end_datetime when the shift is in the past
and the user clicks on sign in since the button will update the start
datetime to current time.
## [FIX] planning{_field_service_worksheet}: fix mobile form view in gantt
Before this commit, the Photos button displayed in the form view in
gantt does not have the same width than the other buttons in the form in
mobile. Moreover, a margin left is added on the first button in the form
view in gantt but in mobile that button is no longer aligned with the
other ones displayed.
This commit fixes those issues to make sure the buttons in the form view
displayed in the gantt view have the same width and the same alignment.
## [FIX] planning_field_service: fix break_time compute
Before this commit, the allocated hours field contained the sum of the
working hours of the human resources when there is at least one human
resource and so the working hours of the material resource assigned on
the intervention is not taken into account. Also, the compute of break
time field does not correctly compute it when there is more than one
resource.
This commit adapts the compute of break time according to the changes
made in the compute of allocated hours.
## [FIX] planning_field_service: hide Sign in button when no customer set
## [FIX] planning_field_service: fix SOL flow when confirming shift and portal
Before this commit, the portal views were not correctly supported the
portal user (missing sudo to find interventions completed and related to
the user which is the customer). A route is not adapted to the new route
in field service feature of helpdesk.
This commit fixes the access error in the portal to make sure the portal
user can access to intervention made for him.
## [FIX] planning_field_service_sale_timesheet: avoid copying SO and SOL
Before this commit, when field service and Billing features are
installed in planning and the user duplicates an existing intervention,
the SO and SOL fields are also copied and so the new materials added to
the new intervention will be added inside the same Sale Orders then the
one copied which is not really expected.
This commit avoid copying SO and SOL when duplicating an intervention
when field service is enabled in planning.
## [FIX] planning_field_service_sale_timesheet: rename label of back button in product
## [FIX] project_timesheet_forecast: fix compute effective hours
Before this commit, when field service and Billing features are enabled
in planning and the user completes an intervention, the allocated hours
and the break time are recomputed when the timesheets are generated for
the intervention, because of the hours recorded could be wrong in the
case the intervention finished after the working schedule of the workers
assigned. The issue is because when a timesheet is created, the
timesheet_ids field is recomputed and recompute effective hours and
allocated hours with other fields. Moreover, timesheet_ids is not stored
and is inside the compute of effective hours and that field is stored
which is not a good practise since the compute of effective hours will
do many write on db since timesheet_ids field will be recomputed each
time we need to read that field.
This commit reviews the compute of effective_hours to no longer depends
on timesheet_ids and makes sure the effective_hours field in
planning.slot are recomputed for the right slots when the employee_id,
date, task_id, project_id and unit_amount field are updated (or when the
timesheet is created). By doing that, that compute will only be computed
when needed.
## [FIX] planning_field_service: add some fields in calendar portal, and some more fixes
This commit adds the new fields added by field service in the planning
portal made for employees without any users to access in the backend.
task-5921961
task-5994180This update fixes an issue where credential errors were displayed in a confusing format. It also corrects how XML invoices are generated when an OIB (tax ID) isn't provided, ensuring accurate invoice creation. New tests have been added to validate these improvements.
Original PR description
- Credentials errors have a separate format in MER, they should now be displayed in a more user-fiendly manner - Correcting XML generation for partners with no explicit OIB provided - Adding tests for both changes task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252284 Forward-Port-Of: odoo/odoo#249448
This update allows administrators to view and revoke user sessions, enhancing security and control over access to the Odoo system. The change was implemented to centralize session management and provide administrators with the tools they need to manage user access effectively.
Original PR description
An administrator must be able to revoke other users' sessions. The revocation action has been moved to the `res.session` model. Add the view that allows admins to view user sessions and revoke them. Task-5941823 Forward-Port-Of: odoo/odoo#248813
This update resolves several issues impacting the AI chatbot functionality, specifically related to prompt management and voice transcription. The fixes ensure users can correctly define prompts for AI interactions and address errors preventing public users from accessing the AI chat, improving overall AI performance and reliability.
Original PR description
This PR fixes the following bugs: - After 2acc117, users have the ability to define prompts for ai.prompt.button records instead of using the name field as the prompt. However, the VoiceTranscription component wasn't updated to use the new prompt field. - The _render_prompt method should return the `name` of the `ai.prompt.button` if no `prompt` is defined or no `rendering_record` is passed to the method. However, this check didn't take into account that `prompt` may contain empty HTML, for example `Markup(<p></p>)`. - Accessing render_model field on `ai.prompt.button` records raises AccessError. - An error would occur if a public user (or portal) tried to chat with the AI using the live chat. - The composer retrieved by the `TranscriptionComponent` doesn't take the model of the current record into consideration.
This update resolves an issue where chatbot session names weren't displayed correctly in live chat and triggered errors when used with the website editor. The fix ensures the chatbot's name is accurately displayed and prevents a crash caused by conflicting channel operations, improving the overall chatbot experience.
Original PR description
*=test_discuss_full Before this PR: - When starting a session with a chatbot, the name of conversation is not visible on livechat channel. Because the name is computed from agent/customer history and not from bot history. - Using a chatbot while the website editor is active could trigger a TypeError traceback. This PR: - computes the name properly from bot history. - adds a guard that closes the transient channel Steps to reproduce traceback: - go to localhost:8069/@/contactus - start chatbot and select some answer - receive traceback task-[5881970](https://www.odoo.com/odoo/project/1519/tasks/5881970)
This update fixes an issue where accrual calculations for stock-based orders were inaccurate, particularly when orders were partially delivered. Now, accrual lines are created separately for each sale order line, providing a more precise accounting of invoiced and delivered quantities and their associated unit prices. This ensures accurate financial reporting for sales and purchase orders involving stock.
Original PR description
### [FIX] (stock_)account: cost method
> Before this commit, we tried to access to `product.product` `cost_method` field in `account` module.
> The issue is: this field is defined in `stock_account` which means we can try to read an unexisting field if we try to generate accruals from a sale order or a purchase order without `stock` installed.
>
> This commit creates an helper method, overrided in `stock_account`, to avoid this issue.
### [FIX] account: split stock variation accrual lines
> Before this commit, accrual lines created for stock variations in case of already incoived not delivered quantities were summed together.
> This commit keeps them separate: one line by sale order line.
>
> Also, those lines' label is rewritten to be more specific, giving the amount of invoiced and delivered qties, and with what unit price.
task-5934232
Forward-Port-Of: odoo/odoo#250408