User management interface

lboeman commented 5 years ago

Related issues : #81 #97 We will need to add a system for creating new users as well as inviting new users to organizations.

My proposed solution for user creation is as follows:

Allow users to sign up via auth0.
If a user logs in and has validated email: add them to the system under the Public organization. The Public organization should have a default role for reading all of the reference data.

User invites/removal:

An organization Admin can invite a user to their organization. This creates a new entry in an invites table, which tracks the invite creator, the invitee and the organization to add them to.
Users may list invites and accept/decline invites. Accepting an invite updates the users organization, declining just deletes the invite. Should we bar inviting users who already belong to an organization?
Organization admin will also need a way to remove users from the organization. This should revert the user to the 'Public' organization and remove all roles related to the organization. If there is a need for banning the user, perhaps framework operator intervention is needed.

wholmgren commented 5 years ago

Sounds good.

Should we bar inviting users who already belong to an organization?

Why? To limit users to a single organization? I don't think that's necessary, but could be wrong.

lboeman commented 5 years ago

Why? To limit users to a single organization? I don't think that's necessary, but could be wrong.

Currently a user only belongs to one organization, which we will use to determine data ownership and which admin can administer the account. To avoid confusion maybe we should disallow inviting a user who already belongs to an organization that isn't 'Public'? Sharing data between organizations will be handled via some similar invite-accept workflow.

alorenzo175 commented 5 years ago

Maybe it will be easier to remove any organization from the user object and only rely on the roles to determine if the user is part of an organization. For deletion of an org (like removing a trial) we'll have to make sure to remove trial users.

lboeman commented 5 years ago

I think that sounds cleaner, but it also introduces some complexity in terms of data ownership. Would the user explicitly define the organization when submitting data or creating a new metadata object? It seems like the user-organization relationship is there to strictly tie that users actions to the organization, and the acceptance of the Terms of Use?

alorenzo175 commented 5 years ago

Hmm, good point. Yes, I think the relationship is there to tie a user to the acceptance of Terms of Use and seamlessly delete users along with organizations.

For now at least, I think we should keep users restricted to a single organization. The workflow you've describe sounds ok but I'm really not sure what's best.

3 should be handled just by deleting the user in the database (which should also remove role associations) and the user will default back to Public.

wholmgren commented 5 years ago

Makes sense. Maybe unaffiliated instead of public. No data upload permissions for unaffiliated.

On Wed, Aug 7, 2019 at 12:06 PM Tony Lorenzo notifications@github.com wrote:

Hmm, good point. Yes, I think the relationship is there to tie a user to the acceptance of Terms of Use and seamlessly delete users along with organizations.

For now at least, I think we should keep users restricted to a single organization. The workflow you've describe sounds ok but I'm really not sure what's best.

3 should be handled just by deleting the user in the database (which should also remove role associations) and the user will default back to Public.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SolarArbiter/solarforecastarbiter-api/issues/140?email_source=notifications&email_token=ABBOER4RRVQGL4RDN6TJND3QDMMNBA5CNFSM4IJX5EXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3ZNBPI#issuecomment-519229629, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBOER2FS3EE5KK77BKLYETQDMMNBANCNFSM4IJX5EXA .

alorenzo175 commented 5 years ago

Since user signhup should be relatively infrequent, what if we have framework administrators add users to organizations? So a user would signup with Auth0 and a user row will be created in the DB without an organization. Then it is up to a framework admin to communicate with the user and org admin to update the organization column for that user.

lboeman commented 5 years ago

Makes sense. Maybe unaffiliated instead of public. No data upload permissions for unaffiliated.

I was thinking that Public would be without upload permissions since we want to ensure that anyone contributing data has accepted the TOU.

lboeman commented 5 years ago

Since user signhup should be relatively infrequent, what if we have framework administrators add users to organizations? So a user would signup with Auth0 and a user row will be created in the DB without an organization. Then it is up to a framework admin to communicate with the user and org admin to update the organization column for that user.

I think this solution works too. Are you thinking of manually running a sql query, or possibly a cli tool for this?

wholmgren commented 5 years ago

I am fine with a manual process so long as we can't screw up.

My objection to "public" is that it implies more than is actually happening. "unaffiliated" seems more accurate.

alorenzo175 commented 5 years ago

Yeah, a simple CLI tool to do this and minimize screw ups would be good

lboeman commented 5 years ago

closing this as the basic cli has been implemented and we can open issues for any persisting bugs. closed by #156

SolarArbiter / solarforecastarbiter-api

User management interface #140