Wednesday, April 9, 2025
2 changes · saas-17.4
Resolved issues and error corrections
A duplicate internal form identifier caused the Data Cleaning setup form to be overwritten during installation. This fix gives the form a unique identifier so the correct configuration screen is reliably available.
Original PR description
…rwriting **Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the…
…rwriting **Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the data_cleaning module 2. Open psql in the terminal 3. Run the following query:” select id, name, model from ir_ui_view where model ilike 'data_%' and type = 'form';” 4. Observe that data_cleaning.model is missing from the results Expected Behavior: the form view for data_cleaning.model should be present in the database. Actual Behavior: the form view for data_cleaning.model is not found in the database. **Root Cause** The form view in data_cleaning_model_views has the same id as the one in data_merge_model_views. Because data_cleaning_model_views is loaded first (as defined in __manifest__.py), it gets overwritten by data_merge_model_views. **Fix** To prevent this issue, the form view id in data_cleaning_model_views has been renamed to a unique and more appropriate identifier. Opw-4517418
Field Service planning by user now excludes archived users unless they are explicitly selected in a manual filter. This keeps planning views focused on active staff and prevents outdated user records from appearing due to unscheduled tasks.
Original PR description
when access planning by user in field service we will see that inactive user are also get fetched even though they dont have planning set this will happend if user have open assigned tasks with no `planned_date_begin` and `date_deadline` here we have made some refactor [ref](https://github.com/odoo/enterprise/pull/53499) and implemented the hook to prepare the domain to fetch the records of `project.task`, instead of overriding `_group_expand_user_ids` steps to reproduce: - navigate to `Field Service > Planning > By User`. - open unassigned task - assigned it to user(create new or use existing user) - unschedule the task - archieve the user ref the video: https://drive.google.com/file/d/1hME_bPXXNJgO9wgWT_CPP3-gz1RaLhPe/view?usp=sharing Fix: - fetch the active user if not added filter manually - if manual filter then fetch based on filter **OPW: 4588785**