Circles, contact groups and user groups

[MorrisJobke]

Problem

We have so many grouping mechanisms and they are confusing for people that don't know the technical background of them. We should unify the way those are handled into a single way of grouping users.

• circles
• contact groups
• (system) user groups
• federated groups
• ...

Idea

Idea is to have some grouping entity that is the only way of organizing a group of users and contacts.

Additionally a layer is added to the server to share to some grouping entity only and not to groups, users or federated users anymore, because those are 3 concepts that basically do the same: share something to 1...n users.

• each user is at least in one of those groupings (the grouping with only the user itself) <- that is used to replace user shares

Attributes

• this grouping entity has a name (random one by default)
• this grouping entity has a type (single user, group of users)? - can be build with permissions (no adding/removing permission for anybody for the single user type)
• this grouping entity has a permission who can manage it (joining, adding, removing users, change name)
• this grouping entity has a visibility

Steps

• discuss the idea (right here in the ticket)
• define the scope and specs
• implement this grouping mechanism (which exists in parallel to the existing ones and undisclosed to any UI)
• implement sharing part
• migrate user shares, groups, circles, contact groups
• remove existing shares, rooms, circles, ...

Note: the last two steps need to be done in one release. The other ones can be done in separate major releases to be able to move this forward and not have one huge changeset that nobody can review properly.

Problems

• the UI needs to make it easy what this grouping entity is about (admins, permissions, visibility)
• the UI needs to make it obvious where this grouping entity comes from to avoid phishing attacks by creating a similar looking entity via federated groups for example
• for migration: what about existing collisions? if there is a circle, a group and 3 contact groups named the same? - during migration, we can add something at the end of the name
• how are the groups managed? User mgmt and Contacts? And additionally inherent grouping using "Linking Collaboration Things"? (Ideally the name "Circles" does not show up – it’s just "users" and "groups")

Other approaches

Linking collaboration things™ - #11015

• links a random entity (room, file, board, ...) to another one and each user that has access to any of them then they also have access to the linked ones
• it's still different, because the goal is not to group users but to group data objects

Design forward: How we handle Users / Groups / Circles - #4493

• this one is another approach to not evolve but rethink the whole concept to not be limited by the existing structures

cc @skjnldsv @juliushaertl @rullzer @jancborchardt @ChristophWurst @danielkesselberg @blizzz @schiessle @nickvergessen @daita for feedback on this topic.

[jancborchardt]

Does it make most sense to talk about it more at the Contributor Week in person? Or is that too late, and we should rather have another (or two) calls about this?

I ask mainly because of:

Linking collaboration things™ - #11015
it's still different, because the goal is not to group users but to group data objects

Technically that’s what it does, but UX-wise it’s really similar. That’s why I think we need to coordinate this here and that one, so we don’t end up in 2 different concepts again. :)

Design forward: How we handle Users / Groups / Circles - #4493

This includes a whole lot of other things (federation of contacts, own profile etc), so this here is one part of it. Probably that issue should be renamed. :)

[juliusknorr]

Technically that’s what it does, but UX-wise it’s really similar. That’s why I think we need to coordinate this here and that one, so we don’t end up in 2 different concepts again. :)

Well, the approach this PR describes is more a generalization of our model of sharing entities (file/calendar) to a user/group/userdefined-group, while #11015 is about combining related entities. Yes, the linking will have the effect of allowing users to access those entities as well, but the main concept is about grouping related elements.

Does it make most sense to talk about it more at the Contributor Week in person? Or is that too late, and we should rather have another (or two) calls about this?

This issue is something we won't be able to tackle for 16 I think, regarding #11015 we already discussed that at the last hackweek and the concept is different from sharing, so I see no collision there.

[ArtificialOwl]

Finally, I found a way to do something nice: IEntitiesManager !

While this is a group management solution, we will take the file sharing as an example for a better overview.
When you share a file, you share to an entity, could it be:

• a single local user,
• a single mail address,
• a group of multiple local users and/or mail address.

(we can imagine a list of other types like federated cloud, federated users, ...)

Now, let's talk about the databases
Please note that this is the general structure, some fields might pop up before and during the development.

table 'entities'

This table will be the core of any request regarding a user or a group of users.

- id             string    - a unique uuid to ident the entity
- owner_id       string    - id from 'entitied_accounts' for the owner
- type           string    - type of the entity: no_member, unique, group, admin_group
- visibility     small int - visible to all, visible to owner only, visible to members
- access         small int - free, invite only, request needed
- name           string    - name of the entity
- creation       datetime

• 'no_member' means that the entity contains no members at all: the owner is the entity. As an example, when you share your file to a local user, you're sharing to the 'no_member' entity that have the local user as owner_id
• 'unique' means that the entity will have a unique member: this unique member is the entity and the owner is the one that can use this entity. As an example, when you share to a mail address, you're sharing to the 'unique' entity that have your userId as owner_id and the mail address the unique member of the entity (see the table 'entities_members') and 'name' should be the mail address of that unique member.
• 'group' means that the entity is a group of multiple accounts. works like 'unique' but is not limited to a single account and the 'name' will be editable.
• 'admin_group' is a 'group' with admin rights on the Nextcloud.

Uniqueness is not managed by the database.

table 'entities_accounts'

This table contains all 'accounts' that can be added to an entity: Local Users and Mail Addresses

- id             string    - a unique uuid to ident the account
- type           string    - local_user, mail_address, guest_user
- account        string    - account/user_id
- creation       datetime

'id' is linked to 'entities.owner_id' or to 'entities_members.account_id'.

• 'local_user' means it is a local account identified by the userId
• 'mail_address' is a mail address.
• 'federated_user' and 'federated_cloud' can be one of the possible entries as 'type'.

Uniqueness is managed by the database using 'type' and 'account', meaning that the same mail address can be used by different owner in the 'entities' table. Of course, when sharing to a mail address, we provide completion based on the 'entities.owner_id', meaning that we only returns the known mail address if it was previously used by the user.

table 'entities_members'

This table will help to link 'entities_accounts' to 'entities'

- id             string    - a unique uuid
- entity_id      string    - id from 'entities'
- account_id     string    - id from 'entities_accounts'
- status         string    - invited, requesting, member
- level          small int - 1=member, 4=moderator, 8=admin  
- creation       datetime

'entity_id' is linked to 'entities.id'
'account_id' is linked to 'entities_accounts.id'

• Status and Level will help manage the current rights in the group for each members: like in Circles, moderator can add/remove users, admin can add/remove moderators.

table 'entities_types'

This table should returns interface and class used by some of the types in the previously defined table. This looks like a descent way to have some extension to the whole system.

- id             int       - incremented and primary key, nothing more
- type           string    - string that define the type
- interface      string    - type of the type (sic)
- class          string    - class to be called to manage the service

This table needs some improvement during the developement of the project, my guess is that the 'entities_accounts.type' will be the first field to use this table with type='local_user', interface='IEntitiesAccounts', class='OC\Entities\Accounts\LocalUser::class'

Please provide feedback and comments.

[MorrisJobke]

Looks good so far. I haven't re-assembled all details in my head fully, but roughly it seem to be what we discussed in the past.

Maybe @nickvergessen @kesselb @blizzz @rullzer @ChristophWurst @skjnldsv @juliushaertl also want to check this out, because that is what we want to replace groups, circles and stuff like that with.

[nickvergessen]

My biggest question for talk is how we should use this.
This needs to be circular proof:

• A talk conversation should be an entity, because you can share files into a conversation
• We want to be able to add entities to a conversation, so you can invite e.g. a group, email, circle, ... into a conversation.
• But at the same time we need to be able to detect if a user is removed from a conversation (while staying in the original entity that was invited) etc.

Hope you can put those thoughts into the thingy as well :)

[MorrisJobke]

• But at the same time we need to be able to detect if a user is removed from a conversation (while staying in the original entity that was invited) etc.

That's quite interesting ... because it would mean that it changes either the original entity or creates a copy without this one user. 🤔

[ArtificialOwl]

@nickvergessen : About adding entites, this could be done in 2 ways:

• In a sharing approach, I was thinking to add a 2-level (and non-recursive) way to group groups. The idea is that you could add an slave entity as part of a master entity, without being too heavy on resources.

• In a grouping approach, a better approach would be to create 1-way link between entities.

Not sure there is a real difference from a user point of view, I need to think about the back-end perspective.

@MorrisJobke : We could use the status field in the entities_members database, even better if a sql request on bit flag value is doable. If not, we can have a text field to store that kind of data in a json that will be stored by the EntityManager, but used by the Talk app. A third solution would be that the Talk app manage the in/out conversation flag using the uuid of the entities_member (which is unique per user per group)

Both are just quick answers!

[blizzz]

GroupAdmins

If I understand it correctly and want to apply it to group admins:

• the target entity is of type group
• regular admins have ownership built-in, so they don't need to be in owner_id
• a "virtual" entity of type admin_group is created and all group admins (each entity no_member) are members of it
• this virtual groupadmin entity is the owner of the target entity

That's a bit cumbersome. To have n owners another relational table could be used.

External users and groups

If I understand correctly, backends that might bring users and groups from somewhere else like LDAP and SAML do register theirs as a type in "entities_types"?

Since, right now there is one service for all users and another for all groups, so duplicating them with "local_users", "ldap_users", "saml_users", …, is perhaps not necessary, unless there is a reason for having it like that?

[ArtificialOwl]

@blizzz

GroupAdmins are just a group member with Admin rights on the current group, right ? This should be managed by the IEntityManager itself when the admin level is assigned to a member.
The 'admin_group' type of an entity are groups that provide Nextcloud Admin rights to its members. Like the 'admin' group in today's Nextcloud.
Users within an admin_group also have Admin Level in all 'group' entities.

External users and groups wont need any specific stuff.

Edit: I now understand the misunderstood: 'local_user' is 'local' as from the Nextcloud. the way it authed is not important.