Unexpected Admin Access for Limited-Access User

[whichone]

On an InvenTree demo site, I created a user and assigned them to a user group with access only to sales. However, after logging in, I found that the user could still access the Admin Center and System Settings, where they were able to perform actions in other modules. Is this expected behavior?

Another issue is that the user can still see the Purchase Order widget on the dashboard, even though they don't have permission to access that module.

[SchrodingersGat]

Does the account have "staff" access?

Please provide some screenshots or evidence here for us to work with.

[whichone]

Yes, the account has "staff" access. After removing the "staff" access, the Admin Center and System Settings were no longer visible.

However, the user can still add widgets from other modules to their dashboard.

[SchrodingersGat]

Ok good to know the "staff" change fixed the admin access.

For the dashboard items - do the items themselves show any data if they are added for the wrong user?

[SchrodingersGat]

It appears that a user can "add" dashboard widgets without the related permissions, but the widgets don't display any data in such a case:

[SchrodingersGat]

PR incoming here - #10047

[p-fruck]

I have the inverse of this issue - I did not assign the staff flag to a user, but added him to the admin group. The user cannot access the django admin ui, which I expected. However, I expected an admin user to have access to ALL components within the InvenTree UI.

However, despite being in the admin group (which has literally all existing rulesets assigned), the user has only access to the user settings, not to e.g. global settings:

Is this expected? Are there any plans to manage global settings permissions using groups/rulesets?

[p-fruck]

@SchrodingersGat that is what I expected, maybe my formulation wasn't the best: The thing that actually confuses me is that my admin user (not a staff member) still does not have access to all settings within the InvenTree UI.

@matmair do I understand correctly, that for the global InvenTree settings all users must be stuff member? So there are currently no rulesets that allow a user to see/modify global settings using group assignments, only staff members?

[matmair]

Yes, to change global settings you need to have superuser rights.
To access the old Django admin site you need staff rights. Those are per user rights.

this all stems from Django’s own permission system, from which we probably will move away with the permissions refactor

[p-fruck]

Thanks for the explanation! So I guess, it does not make sense to consider developing a new feature to sync staff member status using OIDC, but rather wait for the refactoring and use the existing SSO Group Sync to assign the permissions for the global settings?

[matmair]

The refactor is probably 2.0 material, many months out - do not wait for it (#7466).
You could add 2 scopes to your provider and read those on sync, should be fairly simple and is the usual way to sync things like this

[p-fruck]

Every time I come back to contribute some miniscule changes I am impressed how advanced and well-structured this project has become - keep up the good work ;)

Any reason you recommend using additional scopes? Intuitively, I would have extended the SSO group sync feature to define an OIDC group that maps to staff members and one that maps to superadmins. Using dedicated sopes seems like overhead for the IdP admin compared to simply adding another group?

Regarding the IdP configuration, I would like to add 2 further questions:

• How exactly is the OIDC scopes configured? Do you set a specific scope in the codebase or simply use the default from django-allauth that could be overridden by the inventree admin? How would I configure the scope to allow for such additional claims? By overriding the django-allauth provider settings in the environment? Seems like this is not possible via django admin ui for the social app.
• Does the environment config of the provider actually update the database? It seems like the django-allauth config has changed multiple times over the past years, but my (now) invalid environment config never resulted in the oidc config getting bricked. I assume that the config was written to the database once and has never been update since. Is this intended or should changes in the environment update the database configuration? Also I am a little bit confused which part of the config belongs in the environment and which parts belong to the social app configured via django admin ui since a lot of my config (e.g. client id/secret) is duplicated between those two settings. Is there any possibility to define the SSO config solely through the environment?