[MIG][19.0] crm_project_task: Migration to 19.0

[ljmnoonan]

This is a migration + a pretty heavy handed rewrite of the of the security behavior. Previously, a user with no access to the project.task model could still create a task via a transient model, but it was a bit of a shot in the dark, because if he wanted to correct something, he would immediately get an access error. To fix this, I gave sales_team.group_sale_salesman access to project.task, but restricted them to tasks with a lead_id pointing to a lead accessible by the user.

Notes:

• In order to successfully run the default_get method in project.task we need to use sudo, as our user may not have access to such models as project.project. However, sudo strips all default_ context here, which appears to be a decision related to mail (odoo/odoo@7700bd1). In order to solve this, I use _get_sudo_env_with_context which reinjects the default_ values. The other approach would be to simply give sales_team.group_sale_salesman read access to project.project and restrict to the crm_default_project_id project, but this seems brittle. What if another model adds fields with defaults that we don't have access to? It's a little far-fetched, but better be prepared.
• It is possible to set res.company.crm_default_project_id for Company1 to a project in Company2. This will cause users from Company1 without access to Comany2 to get access errors when attempting to create a related task from a lead.
  While I can Imagine a situation in which this kind of cross company compatibility might be useful, I also think it violates the design intent of odoo in general.
• The tests here are written by AI (I'm lazy). They seem a bit excessive, but also seem to work. If you would like me to test anything in particular or would like to tell me to grow a pair and write my own tests, please do so :)

[ljmnoonan]

@EmilioPascual and @rafaelbn it looks like the bot forgot to notify you. I would love your input when you get some time. Thanks!

[EmilioPascual]

@ljmnoonan thank you for the migration but I’m afraid you haven't done a migration; this is a new module that works differently from version 18.0.
This module was designed specifically so that a salesman who doesn’t have access to tasks can still create a task linked to a sales project.
Over time, we’ve found that giving salesman more access isn’t the best option.
Only users with the appropriate permissions will be able to view, edit, delete or create tasks.

@moduon MT-14675

[rafaelbn]

Hello @ljmnoonan thank you for the migration work!

I’m afraid this PR changes the intended security behavior of the module, so I don’t think we should include that change as part of the migration from 18.0.

The module was intentionally designed to allow a sales user without Project permissions to create a task from a lead/opportunity, but not to view, edit, or delete the task afterwards. Those tasks may contain internal information intended only for project users.

If a salesperson needs access to those tasks, the correct approach is to grant that user the appropriate Project permissions, not to extend project.task access to all sales users through this module.

Could you please adjust the PR to preserve the 18.0 behavior?

Thanks again for your work on this. 😄 🙏🏼

[rafaelbn]

/ocabot migration crm_project_task

[ljmnoonan]

@rafaelbn @EmilioPascual Thank you for the feedback!

I understand what you are saying about separation of roles, so I brought back the previous behavior specifically for the case of the salesman who should not be able to mess with tasks. However, I did change what happens when he hits "Create Task" in the wizard view: instead of being redirected to the task form view, where he can edit nothing and will get an annoying access error if he even clicks in the HTML editor, he now stays on the lead page; the wizard closes and the task is created in the background. He can click the oe_stat_button and see the task he has created, but he cannot open it.

On the subject of oe_stat_buttons, I added sudo to the counter, so that the salesman can see that there are already tasks created even if he he can't see them in the kanban. This also means that the "Create Task" button goes away as soon as anyone has created a linked task. A salesman cannot make a duplicate.

Also, for users looking at the task, there is now an oe_stat_button linking them to the parent lead instead of the brittle link in chatter. This is especially important considering that leads can be merged. I have added the task_ids field to the list of fields to be merged, so linked tasks will now "stick" to the new, merged lead.

Finally, users with project.group_project_user do not use the wizard anymore. Instead, the "Create Task" button sends them straight to form view. They are also not limited to using the "Create Task" button, as now they can add tasks via the kanban, list, and calendar views with identical results. Context remains the same no mater what method you use.

Please let me know what you think!

[EmilioPascual]

@ljmnoonan thank you for the changes.

A minor change in readme.

[ljmnoonan]

Fixed the docs and added some edge case type stuff. Now the decision to use the wizard or not is determined not only by the permissions group, but also by whether the user has read access to the default project the new task is being created in. This allows certain cases like:

• Your salesman is also a user of project.task, but for other projects. You do not want to give him access to the default project.
• Your default project is in another company the user does not have access to

Finally, when a user created a task via the wizard, even if he had no permissions in the default project, he would still be able to come back and view/edit the task he created. This was because he was automatically added as a follower by the create() method. I fixed this by immediately unsubscribing him from the task as soon as he has created it.

[EmilioPascual]

Nice

[fcvalgar]

Thanks for the contribution @ljmnoonan and the migration work done on this module.

The following tests have been performed in Odoo 19:

Test 1: OK - Created a project task from a CRM opportunity using Mitchel Admin. The task was correctly linked to the opportunity and accessible through the smart button.
Test 2: OK - Verified that the “Create Task” button is only available when no linked tasks exist on the lead/opportunity.
Test 3: OK - Checked the smart button behavior and confirmed that only related tasks are displayed from the CRM record.
Test 4: OK - Verified that created tasks inherit default values from the CRM opportunity, including customer, assigned user and configured default project.
Test 5: OK - Tested task creation flow with a user without full project permissions. The wizard flow correctly created the task in the configured CRM project.
Test 6: OK - Confirmed that an appropriate validation error is displayed when no default CRM project is configured.
Test 7: OK - Verified navigation from the created project task back to the originating CRM lead/opportunity.
Test 8: OK - Confirmed that linked tasks remain properly assigned after merging CRM opportunities.
Test 9: OK - Verified the new permission selection behavior in Sales and Project access rights views. The “no permission assigned” state is now explicitly displayed as “No” instead of an empty value.

Additionally, there has been a UI modification in the Project access rights view under Sales/Project permissions where the empty permission state is now shown as “No”. While technically correct, this behavior is not common in standard Odoo, where unassigned permission levels are usually displayed as empty values rather than explicit “No” labels.

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[ljmnoonan]

@fcvalgar , Thank you for the review!
The "No" selection does not have anything to do with this module though and is actually default behavior for Odoo 19. I believe this is the line responsible here

[fcvalgar]

@fcvalgar , Thank you for the review! The "No" selection does not have anything to do with this module though and is actually default behavior for Odoo 19. I believe this is the line responsible here

Thanks for the clarification! I honestly didn’t know this behavior was already standard in Odoo 19.

Thanks again for the migration work!