Saturday, May 10, 2025
6 changes
3 changes
Resolved issues and error corrections
Project users can now open task forms that include timesheet entries without running into errors caused by timer information they are not allowed to access. The change limits timer-related data checks to users who have Timesheets access, improving reliability for teams using projects and field service workflows.
Original PR description
Before this commit, the project user cannot access to the form view of a task with timesheets recorded, because the fields related to the timer are always computed and crash if the user does not have any access to timesheet app. This commit makes sure the timer fields are only read if the user has access to timesheets app. task-4782330
This fix places the task-hours display widgets in the correct location for Field Service tasks. It resolves a performance issue, helping task views load and run more smoothly for users.
Original PR description
Commit-https://github.com/odoo/enterprise/commit/9e8ae6df6920e4c10659a87f3f802957a423f44c In above commit, 'fsmTaskWithHours' and 'taskWithHours' were not set in the correct place, which caused a performance issue. task-4760561
When users choose to review all checks on an account return, the checks page now stays open instead of immediately sending them back to the return and moving it to the next state. This prevents unintended workflow progress and ensures state changes only happen through the main Review Checks action.
Original PR description
Before the commit: On a return which passed all checks in 'new' state, when we clicked the dots then click review all checks. It would open the checks view with all the checks green then instantly redirect to the return view. It would also automatically forward to the next state. This is because there is a call to refresh the checks on the page load of the checks view. During this page load, a call to try_forward_state was triggered even if we didn't want to change state. Now, when we open the view from the button 'review all checks', we would not allow changing automatically to the next state. The only way is via the 'Review Checks' main button.
1 change
Enhancements to existing features
Appointment forms can now be embedded on existing external websites for visitors who are not logged in. This makes it easier for businesses to use Odoo appointment scheduling without immediately adopting the full Odoo website integration, while keeping logged-in sessions protected.
Original PR description
Remove CSRF check on appointment forms if there is no session or no associated user for the session. We consider this safe as we already accept logged-out creation of appointment and do not modify any existing data so long as no user is logged in. In that way it is similar to regular form snippets which already work this way since odoo/odoo@b192d8d23f83b35c21b13f6e4516c18897b80201 This greatly eases embedding this form on existing websites for users who do not wish to use our website integration immediately but still want the benefits of the app and the ease of use of the form page. task-4593880
2 changes
Resolved issues and error corrections
Scheduled automations using date-based filters such as “is within the last month” could fail because the server did not recognize some date helpers created by the interface. This fix lets those automations evaluate the filters properly, reducing missed or silently failed automated actions.
Original PR description
# Bug: Currently, base automations that use filters constructed by the front-end using `context_today` and `relativedelta` will fail. These are for example constructed when using the "is within"…
# Bug:
Currently, base automations that use filters constructed by the front-end using `context_today` and `relativedelta` will fail.
These are for example constructed when using the "is within" operator for filter domains, producing search domains like: "Created on is within -1 months"
```
["&", ("create_date", ">=", datetime.datetime.combine(context_today() +
relativedelta(months = -1), datetime.time(0, 0, 0)).to_utc().strftime("%Y-%m-%d %H:%M:%S")),
("create_date", "<=", datetime.datetime.combine(context_today(),
datetime.time(0, 0, 0)).to_utc().strftime("%Y-%m-%d %H:%M:%S"))]
```
When running the CRON for the automation rules, it will silently fail throwing a `NameError: name 'context_today' is not defined` error.
# Proposed solution:
Extend the `eval_context` dictionary in `_get_eval_context` to whitelist the needed methods to resolve such filter domains. Additionally replace `.to_utc()` calls that only make sense when evaluating the filter domain in thre front-end JS
opw-4763409
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Salary Register now only retrieves payslips for the company currently being viewed. This prevents access errors in multi-company India payroll setups and lets users review payroll reports without being blocked by records from another company.
Original PR description
Problem: In a multi-company environment with multiple companies from India, users are getting access right errors about being unable to read employees from Company B when viewing the Salary Register from Company A and vice versa. Steps to Reproduce on Runbot: 1. Install accounting,employee, payroll, India payroll 2. Create 2 Indian companies with India fiscal package 3. Create an employee per company and create payslips per employee and pay them 4. View the salary register in Payroll > Reporting --> access right error thrown opw-4677551