Central group and membership tables

[PVince81]

Juts like the central accounts table #23558 we should add the same for groups and group memberships.

This would avoid having to ping group backends like LDAP over and over again for group membership info. It could also obsolete LDAP's own memcache caching, see owncloud/user_ldap#30

@DeepDiver1975 @butonic @pmaier1

[PVince81]

cc @jvillafanez @IljaN

[PVince81]

@felix as I understand we want to have this as soon as possible in the upcoming 10.0.x releases, moving to 10.0.3 but due to the current schedule I'm afraid there might not be enough time.

[jvillafanez]

Personal estimation:

• 2-3 weeks to implement it (including tests)
• 1-2 weeks to adjust other backends
• 1 week to test for outstanding issues (quick testing)
• 1 week for in-depth testing (specially for LDAP)

That's around 5-6 weeks to have this ready. Taking into account there will people having some vacations during this time, I think the timing will be pretty tight if we want to have this for 10.0.3. Note that almost everything should be ready before the code freeze, which should happen 2-3 weeks before the release depending on the testing workload.

[PVince81]

from what I heard this isn't going to make it to 10.0.3, moving to "planned" for the next version

[felixboehm]

yes, we need input from the ldap concept, will be topic for 10.0.4

[felixboehm]

Asked for concept and detail description of schema. Need to challenge LDAP sync functionality and meet requirements ...

[mrow4a]

I been doing performance fix for LDAP... and stopped.. because most of the problems seem to be because of the lack of this functionality. I might try with @patrickjahns

[DeepDiver1975]

work plan

1. design new groups table (please add specs below in an individual comment)
2. implement group entity and entity mapper
3. design indexes based on used queries
4. integrate group entity mapper into the group manager
5. see jenkins explode
6. iterate over all failing unit tests
7. keep a close eye on the unit test execution time
8. implement sync command
9. implement migration for database groups

[mrow4a]

1. Designed the table related to the concept of groups, group memberships, backends and roles in owncloud ( @pmaier1 )

https://cloud.owncloud.com/index.php/s/fPpsY3J26nhT44e -> password: owncloud

I have also shared the file to @butonic @felixboehm @DeepDiver1975 so we can use collabora to design it further. Looking for comments in the collabora doc or here.

[mrow4a]

Ok, I reiterated once again and I have some conclusions to the design:

Roles:
In fact, roles sound nice, but there is an issue - roles != roles. Group roles are actually only 2, and there wont be more. System roles are not really related to groups, it makes the table multifunctional and maybe it is not the best thing. I think, two separate tables, for group_users and group_admins will work better in this case if there are only 2 options - it would make sense if I will find out there are separate queries in the same operation to oc_group_users and oc_group_admin or design another role in group - otherwise separate tables make no sense.

I still have no idea how to integrate roles like Admin, User and GroupAdmin into oc, but I am afraid it cannot be a scope of this feature and I have to stop thinking about it.

Backends:
I started having doubt about having normalized table there - I mean here, that there is another table describing backend types. Problem is, backends are e.g. LDAP/User as for now. This means, if we have oc_backends table serving for both oc_accounts and oc_groups, record LDAP/User is not a valid value in the table oc_groups. There would need to be a reformat probably saying backend LDAP in general, which increases code complexity on cost of database storage. what do you think @DeepDiver1975, we go back to string in backend entry? It is not best optimized with long scring, but having "lookup table for all" is also not a best idea.

UPDATE:
Talked with Thomas, and will start with just oc_groups and oc_memberships not having foreign keys.

[mrow4a]

@tomneedham is displayname required for LDAP groups or something we want to have? In current group table this is not possible.

[tomneedham]

@tomneedham is displayname required for LDAP groups or something we want to have? In current group table this is not possible.

we allow group backends at the moment to specify a group dispayname - which is how customgroups works. We should add this, so we can have numeric group ids and displaynames for the UI. I would love this for the support portal as well - and so we should sync these too like with the accounts table.

Not sure if we already use this with the ldap group stuff but it would make sense

[DeepDiver1975]

@mrow4a displayname is an integral part of the group - see the interface

interface IGroup {
	/**
	 * @return string
	 * @since 8.0.0
	 */
	public function getGID();

	/**
	 * Returns the group display name
	 *
	 * @return string
	 * @since 10.0
	 */
	public function getDisplayName();

[mrow4a]

Ok, makes sense. Should we store group_id as lowercase by default? What do you think guys?

[DeepDiver1975]

Should we store group_id as lowercase by default? What do you think guys?

since this is coming from external: no - but we need a unique index over it's lowercase representation. just like accounts

[mrow4a]

Do we, in case of groups? I did not find yet place in the code, maybe it will pop up later.

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

[PVince81]

still WIP: #29107

[stale]

This issue has been automatically closed.