A user's teammates should be a union of users associated through licenses and invited users

[ezekg]

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).

[ezekg]

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.

[ezekg]

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 group.users.read permission, I'd think, so it would be disabled by default. And it may make sense to also allow group.licenses.read and group.machines.read to be enabled as well?

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?

[ezekg]

Instead of overloading groups, why not introduce a new teams model solely for associating users together that aren't already associated through licenses? This would allow us to not overload groups and change current behavior.