aboutcode-org
Enhancement request: Introduce ability to ignore (bypass) Product Object Permissions
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.
@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
@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 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.
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.
Sounds like promising and much simpler for implementation for orgs that do not need Product-level access controls.
Proposed new option in the Dataspace "Application Process Settings":
Ignore Product Object PermissionsProposed 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.
I agree though, your suggestion would be much simpler to implement. I just wanted to note that it solves a different problem than described. Thank you for working on this.
Here's another approach, requiring somewhat complicated coding and upgrades probably, but it would address the usability problem:
Modify the Product model to make all Product Object Permissions apply to the Product Name only, without including the Version in that relationship, so that all updates and all references to the Permissions would use only the Product Name.
The user interface for Product Object Permissions could still be presented from the Change Form of a specific Product Version, but an informational message could be displayed to remind the user that the settings will apply to all Versions of the Product.
@tdruez Please comment on this when you have time, thanks.
Going through the discussion, I see 2 main issues:
- Only superusers can manage the object permissions through the admin.
- The permissions are not shared across loosely "related" objects, name/version for Products.
For 1., we have to improve the permission management features:
Even just an API that would allow superusers to assign users and groups to products would already be a great help for a start.
I agree, I've started an implementation (WIP) at https://github.com/aboutcode-org/dejacode/pull/395 to allow the permissions management from the REST API. The main difference with the admin UI is that the user does not require the is_staff privilege to access this endpoint.
From the current implementation of the API endpoint:
"""
Allows managing object-level permissions if the user is:
- a superuser, or
- the object's owner
- has a special manage permission (global or object-level).
"""
We could also add a new permissions management view/tab in the main UI once completed on the API side.
About 2.,
My suggestion is to provide a Product "Clone" action, available in the UI, admin, and REST API. It would allow cloning a Product into a "new" version with a few on/off options: "Copy permissions", "Copy inventory". See the clone project feature in ScanCode.io for example.
Note that you can already do a clone using the "Save as new" feature but you do not have the options about copying permissions and inventory.
Ignore Product Object Permissions Please investigate the feasibility of making this enhancement and let me know if you have any concerns.
I've played with an implementation of this idea, it does not take much code changes, but I'm quite concerned about providing a security kill switch.
Modify the Product model to make all Product Object Permissions apply to the Product Name only, without including the Version in that relationship, so that all updates and all references to the Permissions would use only the Product Name.
This seems a bit sketchy and will require quite some code modification to get it right. I like the "Clone" with configuration approach better because the user has to be explicit about what will be copied, there's less risk of security leaks.
@rogu-beta Would "cloning" an existing Product (instead of "adding") using the REST API be a valid solution for your needs?
@tdruez thanks for your very thoughtful comments, and I am glad that you have initiated an API improvement, which sounds really good. I like the idea of Cloning a Product in such a way that it can copy object permissions as well (which ought to be the default behavior I think). Here's another thought: perhaps you could improve the "Save as New" feature on Product to copy the object permissions as well?
I agree, I've started an implementation (WIP) at #395 to allow the permissions management from the REST API. The main difference with the admin UI is that the user does not require the
is_staffprivilege to access this endpoint.
That is great! It would certainly improve the reliability and ease of use over my current workaround where I scrape the website and process it with beautifulsoup to automate the permission assignment.
@rogu-beta Would "cloning" an existing Product (instead of "adding") using the REST API be a valid solution for your needs?
Not completely, to be honest. The issue is that this is only a snapshot of permissions at the time of creation based on a reference project. Altering permissions afterwards would still require manual adjustments throughout all versions. So you could not for instance add a new user to all existing versions or revoke permissons easily. I'd have to think about this some more, but I think I'd personally would not get that much benefits from this over the REST API for permission assignment. It would be slightly more convenient because you don't have to managed the permission configuration externally, but then again you still kind of have to in order to keep track of change over time.
While I understand this would be much more complex to implement, I still think the right way to go about this is a permission management for teams and associated products with the option to assign permissions across all product versions rather than individual ones. Ultimately, that is a design decision though and entirely up to you.