Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not many groups on maintenance #396

Open
etobella opened this issue Apr 30, 2024 · 10 comments
Open

Not many groups on maintenance #396

etobella opened this issue Apr 30, 2024 · 10 comments

Comments

@etobella
Copy link
Member

When we use maintenance, we only find two groups:

  • Base user base.group_user
    • Can see/edit their own issues
    • Can see only the equipment they follow
  • Equipment manager maintenance.group_equipment_manager
    • Can see/edit all issues
    • Can see/edit all equipment

This is obviously not enough. What I would recommend:

  • Base user base.group_user
    • Can see/edit their own issues
    • Can see only the equipment they follow
  • Maintenance User
    • Can see/edit all issues of their teams
    • Can see only equipment of their teams
  • Equipment manager maintenance.group_equipment_manager
    • Can see/edit all issues
    • Can see/edit all equipment

There is a module for something similar on OCA, but it is breaking maintenance logic for several reasons:

  • Only filters teams, this has no sense IMO
  • Removes the access to base user, so users are not allowed to report issues of their equipment
  • Maintenance Users can only can report issues on their own team

This is not fitted for a big company with several teams on different areas. For example, I have two teams, one for Building Maintenance and another for IT. We don't want to mix issues between them, but users might be able to create issues on both teams.

I can see two options:

  1. Create a new module
  2. Reorganize completely the base_maintenance_group
  3. Do 1 but apply 2 on new versions

WDYT?

@astirpe @MiquelRForgeFlow [I add you because you were involved at some point with this module]

@pedrobaeza
Copy link
Member

We have https://github.com/OCA/maintenance/tree/15.0/maintenance_security for having more granular control.

@etobella
Copy link
Member Author

But it only filters menus, isn't it, Would be right to add all this permissions there?

@MiquelRForgeFlow
Copy link
Contributor

I think 1st option is safer one.

cc: @Borruso

@pedrobaeza
Copy link
Member

I think the module can be extended to add more groups.

@Borruso
Copy link
Contributor

Borruso commented Apr 30, 2024

I think 1st option is safer one.

cc: @Borruso

Yes, create new module is better one.

@pedrobaeza
Copy link
Member

cc @victoralmau didn't we do something similar?

@etobella
Copy link
Member Author

I can create a new module, but having several strategies for the same goal seems a bad decision IMO. I would prefer to find a point of agreement in order to simplify all the flows in a single one at some point

@pedrobaeza
Copy link
Member

I didn't know base_maintenance_group. What is the problem with such module? Maybe the team concept? Should this go by department?

@victoralmau
Copy link
Member

IMO there is confusion (especially with module names).

My conclusions:

  • I did not know base_maintenance_group
  • The maintenance_security module limits the menus and remove the assignation mail.
  • There is no other module (as far as I remember) to extend maintenance permissions according to equipment teams (although it was once considered).
  • A new module (maintenance_team_security) should be created for the use case indicated (it will depend on base_maintenance_group).

@etobella
Copy link
Member Author

It has no sense to depend on base_maintenance_group:

  1. They remove access to base.group_user. I can agree on the idea, but it is a different scope and not required for all companies....
  2. A lot of security has been added on the menus
  3. filters only on teams, but it has no sense IMO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants