-
-
Notifications
You must be signed in to change notification settings - Fork 56
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
A user's teammates should be a union of users associated through licenses and invited users #809
Comments
Or, we could make a user's teammates be the union of users associated through their licenses and users associated through their group. I think this would be a much better solution rather than implementing an invite system (which is needed eventually but let's push that back as far as we can). Technically, a user can already read their group's users, so this wouldn't be too hard to implement i.r.t. authz. |
I think moving forward with the group concept makes the most sense. That way, an account holder can group users together where they want to give those users access to attach each other to their owned licenses. We'd need to give the user Should this be a blocker for the new self-hosted version? Right now, multi-user licenses are kind of half-baked for client-side user-facing portals, but fully-baked for server-side integrations. Good enough? |
Instead of overloading groups, why not introduce a new |
Follow up to #802 (multi-user licenses). Attaching new users to a license as its owner currently makes sense, e.g. create the user and then use the ID to attach to a given license. But in order to attach existing users to a license, we need to allow the license's owner to list users that they invited, since users can't read users they aren't already associated with.
This would require an invite system to track invited users (e.g. a polymorphic
invited_by
association).The text was updated successfully, but these errors were encountered: