Permissions Refactor - in Refinement

[matmair]

The permission system currently uses a mixture of stock Django permissions, a self-written role-mapping engine and a ownership model for stock. This is not well documented and the behaviour is not consistent - making it harder to understand/predict.

There are a few issues regarding permissions, some quite old

Related issues

• Stock Item Ownership on items with no owner #7446
• Django permission group naming can be misleading #7003
• [PUI] Check user permission when viewing pages #5755
• [FR] Permissions system for pricing #4022

Requirements

Requirements for the overhaul:

1. Interoperable (additional to) with Djangos default system
2. Using existing fine-grained control patterns (Tree per Location -> Part -> Stock items)
3. API-enforced and auto-documented
4. Generic / pluggable so plugins can use the same systems (maybe with a permission register?)
5. Extendable with per-model actions (ie. allocate stock, count stock, create revision, ship order but not change it)
6. Integrate well with (LDAP/SSO synced) groups and be transparent to users

User stories

TBD

Feel free to submit your user stories / requirements / issues here - I will update / remove points as consensus is reached on them.

[wolflu05]

I think it would be pretty helpful, if we could assign some users only permissions to:

• CRUD parts, categories (including SP, MP, ...) from a specific category (and their nested children categories)
• CRUD locations (including stock items) only from a specific location (and their nested children locations)
• CRUD only specific companies, BOMs ... maybe here it would be helpful to create different "profiles" which can be assigned to a user, and to some models like BOMs, Companies, ...

This would be helpful to my personal inventree instance which I use for my electronics hobby, to add a separate profile for my family so we can manage our cellar, garage, ... too, without them having appearing my electronics inventory when they search for something they have in their garage. I could just run two inventree instances, but 1. this costs double RAM, CPU, ... and 2. I have to use two different logins.

As well, this could also be useful for business who have different departments: manufacturing, selling, .. different categories of products. Where the employees should not be able to mess with the parts, locations in other departments.

[SergeoLacruz]

I think it would also be nice be bind this somehow to projects.

• Assign users to projects
• Assign parts/stock whatever to projects

Everyone in the project gets access to every item in the project. User groups already exist and can be used.

[SchrodingersGat]

Additional consideration: with the upcoming "lock part" feature, it would be a good idea to control who can lock / unlock a part. Maybe part "ownership" (either of individual parts or part categories) could come into play here.

[wieselukas]

Coming from #7718, here are my user stories from working in a university with different research groups/projects who would like to share a common Inventree instance:

• As an admin:
  • I want to assign one or multiple groups/projects to users so that different kind of stocks can be represented (e.g. common stock, group stock, per-project stock).
  • I want to select whether group/project items will be visible to other groups/projects to reflect different levels of sharing/not sharing Stock.
• As a user:
  • I want to be able to assign a group/project (that I belong to) to every item of every level (Parts, StockItems, BuildOrders, PurchaseOrders, ..) so that different ways of working together can be represented
  • I want to set default groups/projects for newly created items per level so that accidentally forgetting group/project assignment and general amount of work is minimized.

[matmair]

@wieselukas would you use case-required organisations (similar to GitHub/Gitlab with restricted visibility teams/groups below) or would globally visible groups be enough?

I am unsure if project codes are the right device to control Inventree-wide permissions as they represent simple 1:many FK relations (you basically would have to assign every stockitem, part, BO, PO, SO on it's own to the projectcode)

[wieselukas]

I don't have much experience with github/lab groups but globally visible groups would be totally fine for me.

I like the idea of assigning it per stockitem, part, BO, PO, SO individually as it would allow for different use-cases. E.g. the current stock ownership feature could still be reflected when only assigning projects/groups to stock items.
To not make this a manual effort this could either be done through per-user/per-type defaults (type being: stockitem, part, BO, PO, SO) and the possibility to assign project groups to a selection of items. Another, and maybe the better, option would be to link it to a category for parts and stock location for stockitems, while automatically assigning the same project/group to subcategories/locations. To do it manually for BO, PO and SO would be fine for me.
Another case for "project codes" would be that for an admin moving stockitems, parts, BOs, POs, SOs between projects/group would just be a matter of changing the project codes for these items.

[matmair]

@SergeoLacruz @wieselukas
I would like to scope this in the next few months to get an actionable list of tasks assigned to epic. Would you / a college be willing to jump on a call to discuss ideas? This is not going to happen fast but I would like to write down a possible plan for after 1.0 so we know what parts might change in the mid-term.
If you are interested feel free to drop me an email.

[SergeoLacruz]

If if is not around midnight I would like discuss this and add me ideas.

[wieselukas]

Sorry for the late reply. I would also be available for a call. During the week 9-10am or 5-9pm UTC would mostly work I guess