Show group display name when the group object is not loaded yet

[kesselb]

• Resolves: [Bug]: Display name of group not shown until group object is lazy loaded in user management #56532

Summary

We are fetching the first 25 groups when opening the users list. If a user in that list has a group assigned that was not part of the first 25 groups, then we don't have the displayname.

Until:

• The user opens the edit mode (then all groups are lazy loaded)
• The user scrolls in the group view to load the next batch of groups

STR

Preparation:

• Have more than 25 groups.
• Assign group number 26, 27, etc to a user.

Helper script

for i in {1..30}; do
  occ group:add --display-name "Test Group $i" group$i
done

for i in {31..35}; do
  occ group:add --display-name "Test Group $i" group$i
  occ group:adduser group$i alice
  occ group:adduser group$i bob
  occ group:adduser group$i fry
  occ group:adduser group$i hermes
  occ group:adduser group$i bender
  occ group:adduser group$i professor
done

Case 1:

• Open the user management
• Reload to ensure the local state is clear
• See that some of the groups are not using the display name, but the group id.
• Scroll the list of groups on the left => the group id is replaced by the display name
• This PR: List of groups is using the displayname

Case 2:

• Open the user management
• Reload to ensure the local state is clear
• Open the edit view for a user where the disply name is missing
• See that the list of groups is incomplete
• This PR: List of groups is complete

Case 3:

• Open the user management
• Create a new group occ group:add --display-name "Test Group Subadmin" group_subadmin
• Assign "group_subadmin" to a user
• Reload to ensure the local state is clear
• See the in the userlist the subadmin column is empty
• Also in the edit view it looks like the user has no subadmin group
• This PR: Subadmin groups are shown in list and edit

Case 4:

• Open the user management
• Open the user list for a group
• Reload to ensure the local state is clear
• See that some of the groups are not using the display name, but the group id.
• Scroll the list of groups on the left => the group id is replaced by the display name
• This PR: List of groups is using the displayname

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

[kesselb]

cc @artonge @come-nc @susnux @benjaminfrueh for early feedback as you were involved in the other pr's.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[artonge]

I see that we could instead provide the group mapping in another property in the response:

server/apps/provisioning_api/lib/Controller/UsersController.php

Lines 202 to 204 in a2a1f52

	return new DataResponse([
	'users' => $usersDetails
	]);

So the endpoints could contain:

{
	"users": [
		{
			"id": "user1",
			"group": ["group1"]
		},
		{
			"id": "user2",
			"group": ["group1", "group2"]
		}
	],
	"groups": [
		{
			"id": "group1",
			"display_name": "Group 1"
		},
		{
			"id": "group2",
			"display_name": "Group 2"
		}
	]
}

Compare to the current proposal, in which the mapping is contained multiple time in each user object.

What do you think?

[artonge]

Looks good, only one question

[kesselb]

/backport to stable34

[Copilot]

Pull request overview

Copilot reviewed 5 out of 7 changed files in this pull request and generated 3 comments.

[kesselb]

Thanks for your input!

I've marked the conversation about addGroup as resolved. Copilot flagged that this change could add an incomplete group object to the store. The previous implementation of addGroup would not update a group with the correct usercount once it was later fetched with full details. That's addressed now by updating an existing group instead, as suggested.

On master, groups assigned to a user (part of the user response) that aren't yet known to the frontend store aren't shown in the user list and edit dialog. This is fixed by sending the id => displayname mapping along with the user list response and adding those groups to the store. However, that group object is incomplete so the count is only shown once the user scrolls down the group list (which loads the full group details).

I'd hope this is an acceptable trade-off: not seeing the group at all vs. seeing the group with the right name but a missing count. This was originally reported against an older version where the group id was shown but only the display name was missing; a recent change made that worse.

Looking forward to your feedback.