MetacatUI currently loads an existing group by calling CNIdentity.getSubjectInfo with the group subject. That response expands every group member into a full Person record before the group list is rendered. Testing recorded in #2131 found that this request took more than 45 seconds for the example group, while listSubjects returned the member identifiers in less than 0.9 seconds.
PR #2871 prevents MetacatUI from sending a partial group to updateGroup. This prevents members from being lost from the group on update, but it does not improve the long wait before a large group can be viewed.
For an existing group in the editor, use an authenticated CNIdentity.listSubjects request for the exact group instead of getSubjectInfo. The returned Group contains the complete hasMember and rightsHolder identifier lists without expanding every member into a full Person record. We can render those identifiers as soon as the group response arrives, then use the existing authenticated UserModel.getInfo() request to load names only for members shown on the current page.
The initial response must populate both membership and ownership before the group becomes editable. This gives updateGroup the complete hasMember and rightsHolder data even when member names have not been loaded. Users can then edit a large group without waiting more than 45 seconds for every member name.
#2131 mentioned investigating pagination in the listSubjects API. While this endpoint does accept start and count, these parameters page the top level group results, not the hasMember list nested inside one group.
So to support loading and editing large groups, MetacatUI should:
- Load the complete identifier list once with
listSubjects.
- Parse both
hasMember and rightsHolder from the initial response. Mark every matching member model as an owner before the group becomes editable.
- Build the first UI page from those member models.
- Call the existing authenticated
UserModel.getInfo() for visible members whose names have not been loaded.
- When the user changes pages, repeat the request only for members on the new page whose names are still missing.
- Keep the names on the existing models so returning to a page does not send the requests again.
UserModel.getInfo() still returns more than a member name. It can include complete records for every group that the member belongs to. This approach limits that extra work to members on the visible page, but it is not a name only lookup.
Keep the current getSubjectInfo request when checking whether a new group name is available. A listSubjects miss returns an empty response with a successful status, so replacing that request would also require changing the name check.
PagerView currently changes which list items are visible but does not report page changes. It should notify GroupListView when the current page changes so the view can request details for that page. Do not load details for pages the user has not opened.
See
MetacatUI currently loads an existing group by calling
CNIdentity.getSubjectInfowith the group subject. That response expands every group member into a fullPersonrecord before the group list is rendered. Testing recorded in #2131 found that this request took more than 45 seconds for the example group, whilelistSubjectsreturned the member identifiers in less than 0.9 seconds.PR #2871 prevents MetacatUI from sending a partial group to
updateGroup. This prevents members from being lost from the group on update, but it does not improve the long wait before a large group can be viewed.For an existing group in the editor, use an authenticated
CNIdentity.listSubjectsrequest for the exact group instead ofgetSubjectInfo. The returnedGroupcontains the completehasMemberandrightsHolderidentifier lists without expanding every member into a fullPersonrecord. We can render those identifiers as soon as the group response arrives, then use the existing authenticatedUserModel.getInfo()request to load names only for members shown on the current page.The initial response must populate both membership and ownership before the group becomes editable. This gives
updateGroupthe completehasMemberandrightsHolderdata even when member names have not been loaded. Users can then edit a large group without waiting more than 45 seconds for every member name.#2131 mentioned investigating pagination in the
listSubjectsAPI. While this endpoint does acceptstartandcount, these parameters page the top level group results, not thehasMemberlist nested inside one group.So to support loading and editing large groups, MetacatUI should:
listSubjects.hasMemberandrightsHolderfrom the initial response. Mark every matching member model as an owner before the group becomes editable.UserModel.getInfo()for visible members whose names have not been loaded.UserModel.getInfo()still returns more than a member name. It can include complete records for every group that the member belongs to. This approach limits that extra work to members on the visible page, but it is not a name only lookup.Keep the current
getSubjectInforequest when checking whether a new group name is available. AlistSubjectsmiss returns an empty response with a successful status, so replacing that request would also require changing the name check.PagerViewcurrently changes which list items are visible but does not report page changes. It should notifyGroupListViewwhen the current page changes so the view can request details for that page. Do not load details for pages the user has not opened.See
CNIdentity.listSubjectsCNIdentity.getSubjectInfoCNIdentity.updateGroup