Repository navigation
Circles, contact groups and user groups #13478
Description
Activity
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 objectsTechnically 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. :)
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.
Reacted by Morris Jobke and John Molakvoæ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 serviceThis 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.
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.
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 :)
- 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. 🤔
Reacted by John Molakvoæ@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!
-
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?
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.
Can we do a table with different examples so I can properly get a grasp on it? It's a tad complex! :)
Please edit the following one ?
@daitaShares entity_type account_type ... ... User share unique local_user Mail share unique mail_address Talk file share unique? ?? Talk conversation share unique? ?? Circle share group? ?? Public share unique? guest_user Group share group? ?? (Contact share)? ... Reacted by Jan C. BorchardtReacted by Jan C. BorchardtMind explaining
Talk thread share? Do you mean a file shared into aTalk conversation? Or aTalk conversationin itself?15 remaining items
Hi, this feature looks interesting!
It's been a year in the making though, what is its current status?
Also mentioned in the integration of Project and Teams into Dashboard.
Could be worth involving the new Collectives app, which is an extension of Circles.
Documentation for users, admins, and developers
Here is their Gitlab repo
Here is a request for developing a Collectives Dashboard widgetCollective and non-hierarchical workflow by heart: Collectives are tied to a Nextcloud Circle and owned by the collective. Collaborative page editing like known from Etherpad thanks to the Text app Well-known Markdown syntax for page formattingQuick post to explain why Circles might be a descent option to this issue.
Membership
Should be ready for NC22, the app will not define its Circles by 'type' but using options (set by bit flag). Instead of being Personal, Public, Private or Secret a Circle will always be fully lock by default, but configurable to unlock features:
- Single user (Circle contains only one user)
- Personal (Only the owner can see the Circle)
- Visible (Visible to everyone. f not visible, people have to know its name to be able to find it)
- Open (People can join)
- Invite (Adding a member generate an invitation that needs to be accepted by the recipient)
- Request (Request to join a Circle needs to be confirmed by a moderator)
- Friends (Members of the Circle can invite their friends)
- Protected (Password protected)
- No Owner (no owner, only basic members)
- Hidden (fully hidden, fully managed by the backend)
- Root (Circle cannot be a member of another Circle)
- Federated (Federated)
Important notes:
-
Single and Personal are really specific Circles, and when selected, no other options can be added. While Personal Circle are managed by a user, Single are only managed by the backend based on the creation/suppression of users (local, remote)
-
Open/Invite/Request/Friends can be mixed for multiple results:
* OPEN => everyone can enter. moderator can add members. * OPEN | REQUEST => anyone can initiate a request to join the circle, moderator can * add members * OPEN | INVITE => every one can enter, moderator must send invitation. * OPEN | INVITE | REQUEST => every one send a request, moderator must send invitation. * OPEN | FRIEND => useless * OPEN | FRIEND | * => useless * * INVITE => no one can enter, moderator must send invitation. * FRIEND => no one can enter, but all members can add new member. * REQUEST => useless (use OPEN | REQUEST) * FRIEND | REQUEST => no one can join the circle, but all members can request a * moderator to accept new member * FRIEND | INVITE => no one can join the circle, but all members can add new member. * An invitation will be generated * FRIEND | INVITE | REQUEST => no one can join the circle, but all members can request a * moderator to accept new member. An invitation will be generated- The last option No_owner, Hidden and Root can be used by 3rd party app that want to generate their own groups using a provided API.
Federated
I am currently re-writing from scratch the concept of Federated Circles. Based this time on the work already done to have the Circles app and group files sharing compatible with Global Scale.
If the Circles app is [fully] integrated to the Core, any app can share its data with any external instance of Nextcloud.
Sharing
Sharing will be improved a lot, using a dynamic table that list all Unique Id available for each user. Instead of checking all different membership. That will helps managing groups within groups.
Reacted by sunjam, Johannes Schirge, Hans Martin Galliker, Daniel Langbein and brtptrs
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.
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.
Attributes
Steps
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
Other approaches
Linking collaboration things™ - #11015
Design forward: How we handle Users / Groups / Circles - #4493
cc @skjnldsv @juliushaertl @rullzer @jancborchardt @ChristophWurst @danielkesselberg @blizzz @schiessle @nickvergessen @daita for feedback on this topic.