0002: Add permission revamp architecture

[matmair]

inventree/InvenTree#7466

[netlify]

✅ Deploy Preview for project-adr ready!

Name	Link
🔨 Latest commit	f28e8a1
🔍 Latest deploy log	https://app.netlify.com/projects/project-adr/deploys/69980f8a7c702400084d5117
😎 Deploy Preview	https://deploy-preview-8--project-adr.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[matmair]

follow up to #6 due to CI automation

[matmair]

@SchrodingersGat I would start work on this once inventree/InvenTree#11372 is done; probably in a few days
Can you review the proposed architecture change here?

[SchrodingersGat]

@matmair apologies this is the first time I have actually done a full read through of your proposal, it was lost in the churn with everything else going on.

On first pass it seems very ambitions and.. complicated? Also I am not sure I understand where you are going with the "Profiles" concept.

Workspaces

Let's see if I understand workspaces correctly:

• A workspace can be optionally used to section off data within the interface
• By default, everything is in the "global" workspace
• Other workspaces can be defined, which limit the scope of which agents / users can access them

For example:

There might be a super secret project which only certain users have access to. Any parts / stock items / purchase orders which are associated with this project are assigned to the custom workspace.

Any API calls from a particular user would check if they have access to that workspace, and if not, exclude those items from the response?

It would also impact which actions can be performed by the user

Example: Departments

I assume that different "departments" in an org could be represented as different workspaces?

Profiles

I'm a bit lost on this one. They are, kind of like groups?

Can you provide a more concrete example here of how a profile might be used, in conjunction with a workspace?

Plugin Vision

I think that your proposal may be too complex for the core code and the general user base. Additionally, such a prescriptive approach may prevent other types of desired permissions workflows from being achieved.

What I would like to submit for consideration is:

• We add a "PermissionsMixin" plugin class which allows plugins to hook into permission checks
• We expose hooks into this framework at various points in the API and business logic
• Any plugins which implement this mixin can have a say on how permissions are handled
• A default (mandatory) plugin provides a core permission function, based on the existing users / groups / roles
• We add in more fine-grained model-level and instance-level permissions checks

Example: Stock Ownership

Stock ownership is currently poorly conceived and the way that we have implemented it is not for everyone.

We could offload this to a plugin, and the per-instance permission checks can be used to determine viewing / ownership / actions on stock items. This plugin could then be used as a basis for users who want more complex, or different, stock ownership functionality

Example: Workspaces

Workspaces could be implemented as a plugin which maintains separate models for controlling the context of various other models (parts / locations / sales orders) in the system. This decouples the complex workspace logic from the core codebase, and allows users to opt-in to whether they want this more comprehensive approach which comes with more overhead.

Example; More complex role-based permissions

The existing role-based permission functionality could easily be extended by custom plugins for finer-grained access control.

Edge Cases

I can see the interaction between workspaces / profiles / groups / roles becoming extremely complex, and I would like to keep the core permission code as simple and tightly scoped as possible.

---

Let's discuss!

[matmair]

Workspaces

Any API calls from a particular user would check if they have access to that workspace, and if not, exclude those items from the response?

No, the workspace would be added to the URL similar to what other PLM / PDMs already do (fusion, onshape) and serve as one of the inputs of permission requests.

I assume that different "departments" in an org could be represented as different workspaces?

If they do not share data: yes

Profiles

I'm a bit lost on this one. They are, kind of like groups?

Not really, you would still use users or groups assigned to profiles just as with the current permission system.

These are a way to add performant, nestable settings. We are lacking some fundamental things around nesting right now that are re-created by any serious plugin. You can not set a setting on a part category and apply it to all leave / children of that category. Profiles solves that. Every item has the profiles that apply to it already saved. It is a single, efficient lookup.

So if you want to know which permissions apply to this category (maybe form 3 levels up) and which fields should be highlighted in this category (maybe from the global settings) you get that reference with one aggregate request and not some cursed, expensive Python code that we execute every API call.

Can you provide a more concrete example here of how a profile might be used, in conjunction with a workspace?

The concepts are pieces needed for the puzzle, but not dependent on each other.

Workspaces solve the issue of sectioning data (be it permissions, categories, project_codes and various plugin attempts) in a first party, reusable way.
Profiles add an efficient way to store and look up settings in a first party way.

Example: Stock Ownership

Stock ownership is currently poorly conceived and the way that we have implemented it is not for everyone.

We could offload this to a plugin, and the per-instance permission checks can be used to determine viewing / ownership / actions on stock items. This plugin could then be used as a basis for users who want more complex, or different, stock ownership functionality

I do not see how my proposal changes anything reagrding this idea with changing how stock ownership works.

Edge Cases

I can see the interaction between workspaces / profiles / groups / roles becoming extremely complex, and I would like to keep the core permission code as simple and tightly scoped as possible.

That is the exact issue I am trying to address. Getting proper permissions and data separation is very hard to achieve in the current system with plugins; moving security features into plugins is a great way to ensure there is always a hard-to-patch hole and cements InvenTree in the awkward hobby-ist place it currently recides in

[SchrodingersGat]

@matmair thanks for the clarifications, I think that the picture is becoming clearer now. Apologies for my lacking of understanding here - I think that we are approaching the problem from very different business requirements / company backgrounds.

Workspaces

No, the workspace would be added to the URL similar to what other PLM / PDMs already do (fusion, onshape) and serve as one of the inputs of permission requests.

So, would this look something like?

https://inventree.my.org/engineering/api/part/
https://inventree.my.org/finance/web/

Or, something different in mind?

Profiles

you get that reference with one aggregate request and not some cursed, expensive Python code that we execute every API call.

Is the linked profile data stored in a separate "profile" table, with generic FK references back to each target object?

Workspaces solve the issue of sectioning data (be it permissions, categories, project_codes and various plugin attempts) in a first party, reusable way.

Profiles add an efficient way to store and look up settings in a first party way.

So, then you have a "profile" which defines which users / groups / workspaces have access (and what type of access) to any resource

---

I think it would be useful (when you have some time) to demonstrate a rough table structure / workflow to show how all these things all link together. I am beginning to understand better but I want to make sure we are on the same page before we push further forward.

[SchrodingersGat]

@matmair if you have some time to produce an architectural diagram (or similar) here to push this forward - I would love to see this progress and also make sure we are on the same page.