Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a better permission system #95

Open
CrsiX opened this issue Sep 29, 2021 · 1 comment
Open

Add a better permission system #95

CrsiX opened this issue Sep 29, 2021 · 1 comment
Labels
improvement There's improvment needed with something

Comments

@CrsiX
Copy link
Member

CrsiX commented Sep 29, 2021

Currently, the user permission system is based on some flags and other data. First, the flag permission which should determine whether a user is allowed to vote for or against refund requests. Second, the external flag which should indicate whether the user is an internal member or not. Third, the active flag which should make disabling of user accounts temporarily possible. And lastly, the voucher_id reference that determines which internal user vouches for the given external user -- which kind of renders the external flag useless, at least in the current setup.

The goal should be to set up a better and more flexible permission system for different users. It should be easy to use in the server code as well as easy to understand, use and maintain by the clients.

This permission system does not necessarily need to be combined with the authentication question.

@CrsiX CrsiX added the improvement There's improvment needed with something label Sep 29, 2021
@CrsiX
Copy link
Member Author

CrsiX commented Dec 17, 2022

Since most clients currently use a privilege level system anyways, it would be a valid option to specify explicit privilege levels, for example as an enum with the following values:

  • DISABLED (aka the user was softly deleted and can't be used anyhow)
  • EXTERNAL
  • VOUCHED
  • INTERNAL
  • PERMITTED for users with permission=true, which currently implies active=true and external=false
  • optional SUPERUSER, if an action is performed by the server operator, e.g. via the CLI; then, this level could be used to allow some operation which would not be allowed otherwise

Those enums should be exposed to clients via static keywords in strings as well as integers, where DISABLED equals zero. This way, comparisons of the form privilege_level >= 3 are possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement There's improvment needed with something
Projects
None yet
Development

No branches or pull requests

1 participant