New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(NEEDS DISCUSSION) Contract for isMemberOf and isSubGroupOf searches off /api/eperson/groups
#237
Conversation
@abollini and/or @benbosman , I'd appreciate your thoughts on this. This adds two new Without these changes (or some sort of similar REST API endpoints), it's not possible to fully fix major performance issues described in DSpace/DSpace#9052 (see description above for more details). The implementation here is rather simple as the necessary methods mostly exist in our Java API. So, the question is really whether we can allow this sort of change in a bug-fix release (7.6.1) or if there are major concerns with that direction. (Feedback on the suggested endpoints is also welcome) |
My first reaction is that the unpatched design requires the front end to know too much about the back-end implementation, so these new abstractions are going in the right direction. I would suggest a little further thought on "what does the front-end want to know and what does it have to know only to figure that out?" |
/api/eperson/groups
/api/eperson/groups
Closing as "won't fix". This PR includes an old design which isn't correct. I'm going to replace this with the design described in my prior comment: #237 (comment) (which others agreed with in today's DevMtg) |
Related to DSpace/DSpace#9052
While investigating performance problems described in DSpace/DSpace#9052, I've realized that our Angular UI includes code which requests every EPerson in a Group or every Subgroup in a Group in order to determine whether a given EPerson or Group is already included in a given parent Group.
For example:
isMemberOfGroup
inmembers-list.component.ts
: https://github.com/DSpace/dspace-angular/blob/main/src/app/access-control/group-registry/group-form/members-list/members-list.component.ts#L216C1-L233C3isSubgroupOfGroup
insubgroups-list.component.ts
: https://github.com/DSpace/dspace-angular/blob/main/src/app/access-control/group-registry/group-form/subgroup-list/subgroups-list.component.ts#L138-L159This UI behavior will cause performance issues when a Group has a large number of members (either EPerson or Subgroup).
These queries will have much better performance if moved to the backend via
isMemberOf
andisSubGroupOf
endpoints.Therefore, this PR suggestions two new REST API endpoints (to replace the above UI methods):
GET /api/eperson/groups/search/isMemberOf?group=<:name>
GroupService.isMember()
method: https://github.com/DSpace/DSpace/blob/main/dspace-api/src/main/java/org/dspace/eperson/GroupServiceImpl.java#L311-L313/search/isMemberOf
endpoint. https://github.com/DSpace/dspace-angular/blob/main/src/app/core/eperson/group-data.service.ts#L114-L124GET /api/eperson/groups/search/isSubGroupOf?group=<:name>&subgroup=<:name>
GroupService.isMemberGroup()
method, modeled similar toisMember()
above.Because this is a performance fix & is backwards compatible, I'd recommend we consider this change for 7.6.1. The code to implement these endpoints would be rather simple (see implementation notes above)