Allow setting role when inviting new user

[jjcarstens]

Adds role to the invite stored for new users so they are created with the expected role.

[fhunleth]

What's the difference between the write, delete and admin roles?

[jjcarstens]

It just depends. They are defined in each controller. I think the next bigger task is to really define that and have it more central so it's easy to overview what each can/cannot do.

In the meantime, the typical means are:

• read - mostly show and index pages. Allows creation of users items
• delete - Like read, but allows deleting user items
• write - CRUD actions for more shared items (device, CA certificate, etc)
• admin - All the things, especially altering org details (invite users, create new products, etc)

[fhunleth]

Since these are "roles" and we have a "role" called "admin", would different words make sense? I find read, write, and delete a little confusing - especially since "read" allows creation?

Since our immediate requirement is to support a user that has access to device status and nothing else, can the roles be "admin" and "status"? Or another word besides "status"? And then delete the "read", "delete", and "write" roles?

[jjcarstens]

I misspoke. I went through some controllers and read does not seem able to create.

Yes, I do think that makes sense, but I also think it's a much bigger change than this PR.role in the DB is an Enum type and that is just difficult enough to change that it requires thought and I'd rather it be separate.

[jjcarstens]

Thought right after submitting - the quick hack could be displaying the role as status, but not changing the Enum value in the DB. I don't love how that disconnects the view and code handling so much, but I could be convinced

[fhunleth]

Wouldn't it be better if there was a layer of indirection here? I.e., the role would point to a set of fine grained permissions that would determine what could be done. Perhaps the set is trivially small now and having "if" statements all over won't be terrible.

I'm ok with whatever you all think best on this. My desire would be to expose fewer roles while we still can so that we don't accidentally lock in confusing names as people start using them.

[jjcarstens]

Chatted offline. Going to only display the Admin and Read roles for now until all the permissions are adjusted (see e0594f4)

[joshk]

Upon reflection, I think we should use admin, manage, and view as the roles.

manage is a good middle ground for cases where you want to restrict actions like 'delete a product'

I also think these names are more descriptive.

[joshk]

@fhunleth @jjcarstens

What are your thoughts on three user roles:

admin : can create and delete products, and can invite users and set roles
manage : do everything except the above
view : can view all information

[jjcarstens]

I like those role names and these basic starting restrictions

[fhunleth]

Same. Those roles sound good to me.

[joshk]

@fhunleth @jjcarstens this is ready for another review.

[joshk]

from a PR review by @jjcarstens

Josh and I brainstormed this a bit ultimately deciding that our future selves and those migrating would prob prefer a much simpler setup changing the roles to simple string field in the DB.

The main benefits we get from Enum types in the DB is database validation and maybe more efficient lookups. However, we don't look up the role field individually as it comes with the whole user field so it seems worth the trade off to handle validation in the application instead to make it much simpler to maintain going forward