show LDAP groups

[alexanderdd]

Is your feature request related to a problem? Please describe.

LDAP users are shown in the contacts app, but not the LDAP groups. But LDAP groups are shown to admins in the Accounts view.

Describe the solution you'd like

Show ldap groups in contacts app in the left sidebar where the other (system-) groups are. Maybe under a separate heading.

Describe alternatives you've considered

--

Additional context

loosely related:
#2100
#4102

[SebastianKrupinski]

Hi Alexander,

Thanks for the report. Yes this is a know limitation at the moment.

This might have to wait until support for v4 cards is implemented, due to the way that groups are currently implemented, this might be a challenge to implement, With v4 cards there is a better groups mechanism.

[ChristophWurst]

I believe @alexanderdd is referring to nextcloud/server#38432

This might have to wait until support for v4 cards is implemented, due to the way that groups are currently implemented, this might be a challenge to implement, With v4 cards there is a better groups mechanism.

Could you elaborate why? :)

[SebastianKrupinski]

Could you elaborate why? :)

Due the current implementation of the grouping, currently we use the Category property inside the contact card, with just a string.

We would need to pull all vcards with the specific string then figure out which members are still part of the group, which are missing and which got removed. Then update each vcard that was removed or added, which would mean phrasing the card and updating the category then saving it. Yes, we could probably do some fancy SQL statement to limit the amount of cards we pull, but would still need to update the vcards one by one. Also we would run in to some logic problems if a user is assigned to multiple groups, and then is added or removed from multiple groups, as we would need to update the same vcards multiple times.

With V4 there is a specific card type for groups,

BEGIN:VCARD
VERSION:4.0
KIND:group
FN:Product Team
UID:team-123@example.com

MEMBER:urn:uuid:12345678-1234-5678-1234-567812345678
MEMBER:mailto:alice@example.com
MEMBER:mailto:bob@example.com

END:VCARD

This card works by referencing other vcards, instead of embedding the group in each vcard.

So if anything changes in a group you simple override the existing vcard with new data and update one record. This is much simpler, faster and cleaner.

And since this is partially a sales pitch, V4 would also allow us to axe circles/teams, and would allow for things like email only groups that can be used in mail. I would vote for putting this on the roadmap for the next NC release 33.

[SebastianKrupinski]

One other point I forgot to mention in the above comment, because at the moment we use the Category property with a string of the group name. Any group name change operation would need to update all the vcards with the same name, so a group with a 100 members would cause an update of 100 vcards. And I am not sure if there is a way to know that the group was renamed in the back end so you would have users attached to non existing group names.

[ChristophWurst]

Summarized this means it also works with v3 vcards, some operations are just not as efficient to do.

With the way SAB cards are created it's not that big of a deal if you look at nextcloud/server#40997. It's always one vcard that is written and we simply fetch the list of groups, then convert them to a list of categories.

[derStephan]

With the way SAB cards are created it's not that big of a deal if you look

I don't understand if this is going to be included or not. nextcloud/server#40997 gets pushed from version to versions for 2 years now. With 38 conflicts it is unlikely that this will be resolved soon.

Is there anything we can do to speed things up? Maintaining circles in addition to the user groups is not very efficient.

[hluaces]

We might be interested in this functionality. Our use case is enabling LDAP groups to be added as attendees in the Calendar app. After being exploring the rabbit hole for a bit, this particular issue seems like the one that might unblock our use case.

We'd be happy to sponsor the development, if that were the case. Is there a way to try and squeeze this (and I assume, nextcloud/server#40997) in the near future?