[19.0][MIG] project_task_default_user: Migration to 19.0#1725
[19.0][MIG] project_task_default_user: Migration to 19.0#1725NICO-SOLUTIONS wants to merge 2 commits into
Conversation
NICO-SOLUTIONS
commented
May 11, 2026
NICO-SOLUTIONS
commented
- Migrate relational field commands to Command API
- Adapt test data for Odoo 19 API changes (groups, M2M handling)
- Fix failing tests after migration from 18.0
- Keep existing default user assignment logic unchanged
This module automatically assigns default users to tasks: - Stage-based (priority rule): When creating a task or changing its stage to one with default users, stage users are applied with a configurable assignment mode (replace or merge). Stage defaults always take priority over project defaults. - Project-based fallback: If the stage does not define any default users, project default users are applied with the same assignment mode logic. - Assignment behavior: - replace: replaces existing task users with default users - merge: adds default users to existing task users without removing them - Multiple default users can be configured on both projects and stages. [UPD] Update project_task_default_user.pot [BOT] post-merge updates
- Migrate relational field commands to Command API - Adapt test data for Odoo 19 API changes (groups, M2M handling) - Fix failing tests after migration from 18.0 - Keep existing default user assignment logic unchanged
OCA-git-bot
added
series:19.0
mod:project_task_default_user
NICO-SOLUTIONS
changed the title
|
Would you mind taking a look? |
CRogos
left a comment
CRogos
left a comment
There was a problem hiding this comment.
Migration LGTM code + tested.
Not sure if default could get into confusion with the build-in user defined defaults.
I am also not sure if there is a more generic solution with base.automation. I agree that the UI here is easier to use, but maybe use technically base.automation in the background? (just loud thinking)
|
@CRogos In this case I don't think it's the best fit. The assignment logic is quite tightly coupled to project/stage behavior and the replace/merge strategy. With automations we would likely still end up writing custom Python logic, which in my view would make things harder to maintain, debug and reason about. Keeping this in the model layer feels more explicit and deterministic for this use case. Regarding the default_* naming: I checked the related core usage, and the pattern is indeed used for context defaults (e.g. default_user_ids in context). That said, I don't see a realistic risk of breaking behavior here. The core snippet only affects the initial default evaluation of user_ids during task creation via context-based defaults. This implementation doesn't interfere with that mechanism, since we neither inject default_user_ids into the context nor override default_get. Also, the fields in this module live on project.project and project.task.type, while the referenced core logic is scoped to project.task. Overall, while the concern is valid from a theoretical standpoint, I don't see a practical path where this would lead to conflicts with the core behavior. |
4 participants
