[8.0] project_baseuser - discussion for different permission structure

[rafaelbn]

Hi @dreispt , thinking and testing this module I would like to ask you opinion in my reflexions.

Installing this module is very specific and maybe we could make it better. I think that we can maintain this functionality better by adding 2 more security groups in project (setting -> Users):

• User
• Member (new group)
• Project Manager (new group - for res.user who are assigned in user_id in project.project)
• Manager

This way we don't touch Odoo's permission groups so if you don't user "member" or "project manager" you will have same functionality of Core.

1

Employees are now basic Project users, able to create new documents (Issues or Tasks). These are kept editable while in New and Cancelled states, to allow for corrections or for the user himself to cancel an incorrectly created request. Previously, Employee users did not have any write nor create access to project documents.

• Adding to employees make all employees access to project (this is not very common), this is not good as many employees must see the minimum part of their job, just sales, just purchases, just accounting...
• Force to customer to use "New" and "Cancel" states, in fact, for to use states when Odoo v8 and v9 do not use it anymore.

I think we must maintain option in Setting -> User to select if a user or employee access to project o not.

Note: Odoo core has a functional bug in my opinion. By default a Project User cannot create issues... this has no sense. So we can add this to the default user's group. Project Users can create issues. Here is how you must add this manualy: https://youtu.be/ZLzZ-o6q8N0

2

Project Users, on the other hand, are supposed to act on these documents, such as reported issues, and update them accordingly, so they have write access for all states. Employee users don't have write access on later states, but can still write comments and communicate through the message board (open chatter).

In general, users will only be able to see documents where:

They are assigned/responsible for, or They are following, or They are a team member for the corresponding Project (but not if only in the project's follower list).

Project's Members in project.project have same permission as Project's followers. This have many sense, as you have permissions on the project but you don't need to follow it. this has two benefits:

1. Project manager when creating task doesn't have to delete followers pulled from project.
2. Project users don't have see all task in one project, they can unfollow or follow as needed.

   3

Project Managers have access rules similar to Project Users, but additionally can create new projects and can see all documents for the projects they are the Manager. As a consequence, Project Managers no longer have inconditional access to all Tasks and Issues, and will only be able to edit the definitions of Projects they manage.

This makes it possible for a Project Manager to have private projects that other users, Project Managers included, will not be able to see. They will need to be added as followers or team members to able to see it.

Public Projects and their documents are still visible to everyone. Portal users access rules are kept unchanged.

Adding "Project manager" groups (which is different of Manager) you will have same functionality as you describe. You can have many project managers who are independent of each other and you can still have a Full Manager like CTO, CIO or also CEO who see everything.

4

Access Rules summary:

We will have in Setting - Users - Access Right - Application - Project

Employee Users Can see only documents followed or responsible for (in "user_id"). Can create new documents and edit them while in "New"/"Cancelled" states.

• User

Project Users Can edit Project Issues and Tasks in any stage/state. Can see all documents for projects they are followers on team members. Can see only documents followed or assigned to for other projects.

• Member

Project Managers Can create new projects and edit their attributes. Can see all documents (Tasks or Issues) but only for their managed projects. For the other Projects, will see only followed documents, just like the other users.

• Project Manager
• Manager

Note: For sure if needed we can add also "Employee" as you described, having 5 groups of permission for projects.

Also I think is more clear to understand for anyone.

After writting this I have read https://github.com/OCA/project-service/issues/59 so welcome @jbeficent

We can do this of v8 like I described if you agree.

@dreispt could be this and [IMP] of project_baseuser of it must be a new one.

cc @antespi @pedrobaeza

[dreispt]

Sorry for the late answer. Indeed I'm aware there are issues with that module structure. I agree with most of your comments.

I propose this:

1. Project Administrator: with full powers, corresponding to the core "Project Manager" role.
   • Suitable for a PMO or Projects Director (as in Jordi's proposal)
   • Corresponds to the core "Project Manager" with a modified description.
   • No record rule limitation: sees all projects and all tasks/issues.
2. Project Manager: can create Projects and maintain things like Tags and Stages.
   • Suitable for the Project Managers responsible for specific projects.
   • Currently is a modification to the core Project Manager, but should be a new Group inheriting/extending core Project User.
   • Should have record rules limiting the Projects it has access to the ones he is manager.
3. Project User: these are the people assigned to work on projects. They should be able to freely edit Tasks and Issues, but not configurations.
   • Suitable for Project Team Members.
   • Corresponds to the core "Project Users". I agree they should be able to create Issues; that should also be reported upstream as a bug.
   • No changes to existing record rules, meaning that they would see only followed Tasks/Issues (I'll elaborate later).
4. Project End Users: can open new Tasks/Issues but can't "manage" them.
   • Suitable for collaborators outside the projects
   • Now implemented directly in the "Employee" role, but should be a new Group inheriting from "Project User", adding restrictions to the editable stages/states (requires dependency on project_stage_state).

Regarding the "Project User" record rules, I came to the need of limiting the users that can be assigned to a Task. The most intuitive answer is to limit it to the Project team Members (BTW that will be removed in v9). To allow for this feature to use the Project Member list, I don't necessarily want all those persons to see all of the Project's Tasks. If I need that, i prefer to manually create a group/record rule granting that access.

What do you think?

[rafaelbn]

About project issues

Corresponds to the core "Project Users". I agree they should be able to create Issues; **that should also be reported upstream as a bug***.

No changes to existing record rules, meaning that they would see only followed Tasks/Issues (I'll elaborate later).

Odoo answers me this:

Hello Rafael, Mentioned issue not consider as a bug. It's user access rights issue. As you mentioned in your last mail, user who has “users” access right in the project module, they cannot create issue. when they create issue system generating Odoo warning message “Access Denied. The requested operation cannot be completed due to security restrictions. Please contact your system administrator.(Document type: project issue, Operation: create)”. you have add “Project / user” group into “Project/Issue: project manager: see all” record rule to assign access right for create issue. The Example was explained in Video file,please take view of it at :- https://youtu.be/ZLzZ-o6q8N0 I hope this information will help you. Mitesh Prajapati (mpr)

I didn't propose a fix to Odoo, just a user issue in Odoo.com

[dreispt]

Issue in odoo.com? Do you have a link or issue number?

[rafaelbn]

It is in the partners portal: this is the link but I suppose is private:

https://www.odoo.com/web#id=647445&view_type=form&model=project.issue&menu_id=4906&action=1901

I don't know why I didn't opened it in Github. Already done! Here: https://github.com/odoo/odoo/issues/8286

[rafaelbn]

Hi @dreispt , about the main theme of this issue. I mainly agree with you.

Thanks for "Project team Members (BTW that will be removed in v9) remark! I didn't realize...

This was my table before knowing this:

Profile	Odoo configuration	Project configuration	Functionality
Project administrator	Manager		Standard
Project Manager	User	+	Manager in project
Project Member	User	+	Member in project
Project User	User	+	project.issue
Project End Users	End user (new group)		new

Remarks/doubts of https://github.com/OCA/vertical-service/issues/108#issuecomment-135807598:

• Project Administrator, I agree.
• Project Manager, I agree.
• Project Users, I jump this point to the end of comment.
• Project End Users. My request for you in this point is to think on this:
  • I don't like the idea of depend in project_stage_state because a lot of companies would like this permissions without using states in stages. This is complicated, thats why Odoo leave out states.
  • IMO this module must work without states as without team members in project. Thinking in new versions.
  • For sure this profile could be needed with out states so we need it.
  • For sure any company could need states so we need it too.
  • Maybe could we include this in the module by not activate it by default and add a check-box in Setting -> Configuration -> Projects to enable it? This way there is only one module but by default no one will have states.
  • Maybe we must split this in other module.

• Project User, doubt with User related with a project (as you said): How to indicate in the projects which users are related to a project? (my idea was using team members but they will disappear...). We for sure need this as in Odoo core all members related with a project must be Followers (if not they don't see project and in tasks as only can read on project cannot input time to it) and this mean that when creating new task all followers of the project will be follower of all tasks with 2 problem IMO:

  • [a] All followers of the project has to unfollow each time from tasks for not getting hundreds of messages about tasks in projects. / Project manager or project users when creating a Task has to unfollow other users when task not related with them
  • [b] If a user is not follower of the project and has a task of the project he/she doesn't has permissions to input time on it.
  • The solution [s1] I see is modify Odoo function which set follower of tasks from followers of project, making that this not happens. I don't like this option, I wouldn't like to touch this from core (thats why I thought in team members). Maybe other solution [s2] is to add in Project User permissions to write in project in spite of not being followers.

  Regarding the "Project User" record rules, I came to the need of limiting the users that can be assigned to a Task. The most intuitive answer is to limit it to the Project team Members (BTW that will be removed in v9). To allow for this feature to use the Project Member list, I don't necessarily want all those persons to see all of the Project's Tasks. If I need that, i prefer to manually create a group/record rule granting that access.

  The only solution I see is like in Project End Users with states. Recover in v9 team members and this will be the list you need (and the most of the companies will need). And create a project_member and a check-box in Setting -> Configuration -> Projects for enabling this funcionality in module.

I'll thinks later more in this theme.

[dreispt]

Nice summary table. Comments:

Project End Users. For sure this profile could be needed with out states so we need it.

OK, what's the difference for you between "Project Users" and "Project End Users", then?

Project User: How to indicate in the projects which users are related to a project?

Use Project Member list, add that ourselves in v9. It's important information for Project Management, and just being there doesn't hurt anyone.

[a] All followers of the project has to unfollow each time from tasks

Just edit their Notifications at Project level - they provide the notification defaults for each new Task. Or you can add a Record Rule giving Members access to all Project documents. This could be done in the documentations or by a Wizard.

Project Member

You added this Group. What is it for?

[rafaelbn]

OK, what's the difference for you between "Project Users" and "Project End Users", then?

"Project End Users" are as you defined here https://github.com/OCA/project/issues/108#issuecomment-135807598 but we use Stages (new and canceled) instead of states. (+ here we can add an option not activated by default that if activate install project_stage_state and add this rules to states also.

---

Use Project Member list, add that ourselves in v9. It's important information for Project Management, and just being there doesn't hurt anyone.

OK, we will use Project Member list and in v9 we will maintain them. This will very absolutely necessary for many things.

---

Just edit their Notifications at Project level - they provide the notification defaults for each new Task. Or you can add a Record Rule giving Members access to all Project documents. This could be done in the documentations or by a Wizard.

+

Project Member You added this Group. What is it for?

+

To accomplish this need:

Regarding the "Project User" record rules, I came to the need of limiting the users that can be assigned to a Task

Sorry I was wrong...

• Project Member profile is the same as your definition of Project User here https://github.com/OCA/project/issues/108#issuecomment-135807598, so if a user is Project User:
  • Project User + Member: you see all tasks and issues of the project which user is memeber
  • Project User: you see only tasks and issues that are asigned to you. Any task can be assigned to a project user.
  • Add option not activated by defatult that if activated will limit the the users that can be assigned to a Task to the team memmers

Do you agree @dreispt ? I think this will fit all needs.

My new questions for you:

Which will be the name of the new module? What do we have to do with project_baseuser and project_issue_baseuser modules? We will maintain three modules?

Thanks Regards

[rafaelbn]

Hi @dreispt , if validated we will work on this next week and we will be able to test it in runbot. Thanks

[dreispt]

"Project End Users" are as you defined here #108 (comment) but we use Stages (new and canceled) instead of states. (+ here we can add an option not activated by default that if activate install project_stage_state and add this rules to states also.

This won't work - you can't rely on specific Stages names, since they are supposed to be customized by Project, and you can have equivalents to "New" or "Cancelled " with totally different names.

To do it properly you need to classify Stages into canonical "states". I don't any disadvantage in adding states, why are you hesitating on it? Are you sure you understand how stage states work?

The best workaround I see is to let End Users edit only in the first Stage of the Project, but I think this is quite limited compared to be benefits it provides.

Project User + Member: you see all tasks and issues of the project which user is memeber

Facing two possible configurations, I would prefer for the module's default to be the closest to the core module default. So I prefer that If I need that, create a group/record rule granting that access - either manually (enough IMO) or by adding a small module for that.

Regarding the implementation, if should be a new version of the new module. The README should provide instructions on what is changed, so that people upgrading can review their user permissions accordingly.

I dislike the current module name, it should change to something like project_security_group and project_issue_security. But IMO that is best left to do when migrating to v9. If you want to do it now, migration scripts would have to be provided.

[rafaelbn]

why are you hesitating on it? Are you sure you understand how stage states work?

• Is my experience with our customers/end users and my own experience.
• Working from 6.1 with states for end users (customers) was complicated to understand stages and states as for them (and the most of user I think) a task is open or close, this are states that from v8 is a field boolean in project.task.type named closed (when sale_service installed). This is the main reason I don't like the idea to use states again: to make Odoo easier for everyone.

If you agree then I prefer by default to not create profile "Project End Users" and created only if check box created for this purpose. This activation will install as you explained project_stage_state.

Facing two possible configurations, I would prefer for the module's default to be the closest to the core module default. So I prefer that If I need that, create a group/record rule granting that access - either manually (enough IMO) or by adding a small module for that.

By default OK but we will add this as optional to be activated with a check-box, OK?

Regarding the implementation, if should be a new version of the new module. The README should provide instructions on what is changed, so that people upgrading can review their user permissions accordingly.

OK

I dislike the current module name, it should change to something like project_security_group and project_issue_security. But IMO that is best left to do when migrating to v9. If you want to do it now, migration scripts would have to be provided.

OK to left to do when migrating to v9

[dreispt]

If you agree then I prefer by default to not create profile "Project End Users" and created only if check box created for this purpose. This activation will install as you explained project_stage_state.

v6 Stages were a mess, but Odoo got them right to v7. IMO it's very simple now and an indispensable feature, you should have a better look at it. But I agree on not pushing dependencies, so the "Project End User" should be moved to separate module.

By default OK but we will add this as optional to be activated with a check-box, OK?

OK. That probably means it is implemented in a separate module and to add a res.config extension to enable/install it.

[dreispt]

Can you write a summary so that we are sure there is a common understanding of the design?

[rafaelbn]

@dreispt I'm reviewing for summary and get this doubts from you comment https://github.com/OCA/project/issues/108#issuecomment-135807598

No changes to existing record rules, meaning that they would see only followed Tasks/Issues (I'll elaborate later).

• By default project user can see all tasks of the projects they are following even though they are not follower of the tasks.
• By default if project user is not follower of a project they cannot input time to a task even though they are assigned to the task because they have read only permissions in the project.

This two point are solved with the option "_Limit project users_" of my summary.

• [new we must discuss] by default if project_timesheet is installed, in a task where two project users are "assigned" and "revisor", they cannot input time in the task (only the firstone who input)

Do you know how to solve this? We have localy solved with a trick...

Summary

1. Project Administrator: with full powers, corresponding to the core "Project Manager" role.
   • Suitable for a PMO or Projects Director (as in Jordi's proposal)
   • Corresponds to the core "Project Manager" with a modified description.
   • No record rule limitation: sees all projects and all tasks/issues.
2. Project Manager: can create Projects and maintain things like Tags and Stages.
   • Suitable for the Project Managers responsible for specific projects.
   • Currently is a modification to the core Project Manager, but should be a new Group inheriting/extending core Project User.
   • Should have record rules limiting the Projects it has access to the ones he is manager.
3. Project User: these are the people assigned to work on projects. They should be able to freely edit Tasks and Issues, but not configurations.
   • Suitable for Project Team Members.
   • Corresponds to the core "Project Users". Adding permissions to be able to create Issues
   • No changes to existing record rules,

Options to be enabled after installed module:

• Add Project End Users: can open new Tasks/Issues but can't "manage" them.
  • Suitable for collaborators outside the projects
  • Now implemented directly in the "Employee" role, but should be a new Group inheriting from "Project User", adding restrictions to the editable stages/states (requires dependency on project_stage_state).
• Limit project users - Limit project user to see only the task and issue he/she is assigned and not all the task of a project. If project user is a team member then has persmision to see all tasks and issues of a project.
• Limit task to team members - Add option not activated by defatult that if activated will limit the the users that can be assigned to a Task to the team memmers. By defatul all project users can be assigned to a task even the are not members of the project team.
• Members not followers by default - You can add team members to define the project users that work in your project but they are not added as follower by defatul, this mean that the follower of the task in the project will be only the project user assigned and the revisor.

[dreispt]

I'm OK with the "Project End Users" additional role. About "Members not followers by default", isn't this already so? Regarding reviewers, we should change record rules for "Project Users" so that user see all Tasks they are reviewers.

[rafaelbn]

Hi Daniel, we are already working in this modules.

About Members not followers by default you are right but this is because I write wrong. The change is for making this possible:

You can add team members to define the project users that work in your project but they are not added as follower by default, this mean that the follower of the task in the project will be only the project user assigned and the revisor

But I don't know how to say it in one phrase.

@sergio-incaser any doubt?

[rafaelbn]

Hi @dreispt , as you can check in https://github.com/OCA/project/pull/117 we have the doubt in how the people who is using project_baseuser is going to update to the new module without troubles. Please check PR. Thank

[rafaelbn]

Resume:

• project_baseuser
• project_enduser (depends in project_stage_state)
• project_issue_baseuser
• project_issue_enduser (depends in project_enduser)

[rafaelbn]

OMG! :cry: @sergio-teruel @carlosdauden Did we make PR to OCA about this? We worked here hard...

[rafaelbn]

Closing... to old