Enhancement request: Introduce ability to ignore (bypass) Product Object Permissions

[rogu-beta]

Is your enhancement request related to a problem? Please describe.
Currently, when a product gets created only its creator has access to it, apart from superusers. The user that created the product cannot control who has access to it. If creation is done via a technical user form a CI pipeline, nobody except the superusers gets to see it. Superusers then have to manually assign all users or roles for the individual product version. This has to happen every time a new version is created.

It would be beneficial to have some form of team concept in the permission model.

What are the benefits of the requested enhancement?
The benefit of the proposed feature is that teams working with frequent releases do not have to ask the administrators to change the visibility of yet another version everytime they create a new one. The current situation would cause delays in the work of the development team, as they cannot see their products, and also keeps the administrators away from other tasks. Administrators would currently either have to perform the assignment manually or build custom script that uses webscraping techniques to automate the assignment, as there is no API for it and IDs for users, products, and roles need to be found.

Describe the solution you would like
The concept of teams could be introduced. For instance, teams could create a mapping between users and product names. Users are given "view_product", "change_product", and/or "delete_product" permissions within the team and associated products. Permissions do not have to be assigned for individual version of products, instead all versions for a given name are included. Management of team membership could be done by superusers, but ideally there would also be a new role that allows for self-management of team membership for users that are already part of a team (e.g. the team lead).

Additional notes
n.a.

[DennisClark]

@rogu-beta thanks for describing your issue. Please take a look at this to see if it addresses your problem adequately:

https://dejacode.readthedocs.io/en/latest/howto-5-product-object-permissions.html

[rogu-beta]

@DennisClark Unfortunately not. The page is a great addition to the documentation as it explain how superusers can manage permissions for an single product version, but this would have to be done for every single version of a product and each time a new product version is added. Given that the users creating the products and superusers are fairly distinct user groups, the aformentioned issues arise.

[DennisClark]

@rogu-beta thanks, got it. will look into a solution.

[rogu-beta]

@DennisClark Even just an API that would allow superusers to assign users and groups to products would already be a great help for a start. That way we could at least model that mapping outside of DejaCode and would not require manual assignment for every version.

[DennisClark]

Perhaps there is a simpler way to approach a solution to this problem; first, a little background. The concept of view/edit security on individual Products was originally introduced to handle the data privacy of different departments of very large organizations; however, it is clear that many organizations do not require such security at all.

Proposed new option in the Dataspace "Application Process Settings": Ignore Product Object Permissions
Proposed help text:
When true (checked), enables user access to any Product in the Dataspace for users with basic Product security, regardless of Product Object Permissions.

@tdruez Please investigate the feasibility of making this enhancement and let me know if you have any concerns. The problem described in this issue by @rogu-beta is a serious application usability issue and if this approach can resolve that, we should make it a high priority.

[mjherzog]

Sounds like promising and much simpler for implementation for orgs that do not need Product-level access controls.

[rogu-beta]

Proposed new option in the Dataspace "Application Process Settings": Ignore Product Object Permissions Proposed help text: When true (checked), enables user access to any Product in the Dataspace for users with basic Product security, regardless of Product Object Permissions.

@DennisClark It would only simplify this if no access control is needed at all. However, separation between products (and the real world teams working on them) would still be of interest. The key part here is that the current permission system does not allow to set permissions for products across all current and future versions. Otherwise you could do what you suggested already, by creating a role/group where every user is placed in and assign that role/group permissions on several or all products. However, this is currently a situation you would have to perform configurations for every time a new version or new product is added. With frequent release cycles, e.g. one release per sprint, that's a lot of organizational overhead and delays between teams, especially if only the superusers can assign the permissions.

So the suggestion would work for some, but it would not solve the situation originally described in my ticket.