-
Notifications
You must be signed in to change notification settings - Fork 50
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
Group and eperson management #41
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks to provide the contract also for existing implementation this will help to reduce our documentation gap. Please review the contract for the mapping according to the practice of Spring Data Rest using the text-uri/list format and the association links (some need to be introduced as stated in the comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@benbosman : I gave this a review today. Sorry for the questions, but there are a few things I don't understand. If you and @abollini have previously discussed any of these points & come to a different decision, feel free to let me know. I'm not trying to slow down this PR, but I did come away from the code review with many questions.
Note that metadata-as-map has since been merged, so examples given in this PR should be updated to use that new structure, e.g. what I did here: #53 |
# Conflicts: # epersons.md
get groups of eperson Updating metadata layout
…ons until it's sorted out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@benbosman : Overall this looks good to me. I noted below that I think some of the subresources here could use better names... I'm not sure about "parentgroup" (but if others prefer this name, I can live with it).
Previously (a long time ago) I had also asked a question about whether all these endpoints should be under /api/core/epersons
and /api/core/groups
(as /api/eperson/epersons
is a bit odd looking for an endpoint). As EPersons and Groups are related more to Authorization, we could also consider putting these at /api/authz/epersons
and /api/authz/groups
alongside the current /api/authz/resourcepolicies
endpoint. All that said, I'm OK with leaving this as-is if others feel EPersons and Groups are better grouped under /api/eperson/epersons
and /api/eperson/groups
.
epersongroups.md
Outdated
**GET /api/eperson/groups/<:uuid>/parentgroups** | ||
|
||
Retrieves direct parent groups of the given group. | ||
Requesting indirect parent groups is not supported |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted above, I wonder if calling this endpoint memberships
would simplify the description here? This is a list of the other Groups that this Group is a direct member of.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted above, I suggest to remove this association endpoint and add a search method
/api/eperson/groups/search/hasMember?:uuid
that will retrun the list of groups that contains the specified group by uuid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See inline comments. The ones that are imho blocking are the ones related to parent groups and children groups in the Groups endpoint.
epersongroups.md
Outdated
**GET /api/eperson/groups/<:uuid>/parentgroups** | ||
|
||
Retrieves direct parent groups of the given group. | ||
Requesting indirect parent groups is not supported |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted above, I suggest to remove this association endpoint and add a search method
/api/eperson/groups/search/hasMember?:uuid
that will retrun the list of groups that contains the specified group by uuid
I've updated this PR to prepare it for the beta 2 sprint implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@benbosman : Thanks for the updates here! Honestly, I think the overall contract looks good to me. I do have a number of (very minor) comments below...these are all more like tiny cleanup / renaming rather than any significant changes. Overall though, I think this contract is close to being done.
* 201 Created - if the operation succeed | ||
* 401 Unauthorized - if you are not authenticated | ||
* 403 Forbidden - if you are not logged in with sufficient permissions | ||
* 422 Unprocessable Entity - if the name was omitted or already exists, if permanent was set to true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor thing, I don't think a POST can fail if permanent is set to true
. A POST is creating a new Group, and a new Group cannot be a "permanent" one. So we can likely just remove the last statement on this line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tdonohue how I see this is:
permanent
is a property on the group which is part of the JSON response. It's possible this is set to true during the POST (Angular should not be implemented to set it to true, but it can still be sent as such to REST from other applications). Since we should not allow creating permanent groups via REST, it should fail
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@benbosman : Oh, I understand what you mean now. You are correct, but I previously misunderstood the statement without the additional context you just added. I'd suggest we simply reword this slightly and say:
422 Unprocessable Entity - if the name was omitted or already exists, *or* if permanent was set to true (permanent groups can only be created by the system).
epersongroups.md
Outdated
|
||
_Unsupported._ If you want detailed information about a single group, use the `/api/eperson/groups/<:uuid>` endpoint. | ||
|
||
**PUT /api/eperson/groups/<:parent_group_uuid>/subgroups** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PUT section seems like it should be moved up alongside the POST
that is similar. It's a bit oddly placed under a header called "Remove a Group from a parent group".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've moved this to make it more clear which methods are supported and which not for changing the subgroups
epersongroups.md
Outdated
|
||
### Remove an EPerson from a parent Group | ||
|
||
**PUT /api/eperson/groups/<:groupuuid>/epersons** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, I think this PUT should be in the section above next to the POST
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've moved this to make it more clear which methods are supported and which not for changing the epeople
epersongroups.md
Outdated
|
||
**GET /api/eperson/groups/<:parent_group_uuid>/subgroups/<:sub_group_uuid>** | ||
|
||
_Unsupported._ If you want detailed information about a single group, use the `/api/eperson/groups/<:uuid>` endpoint. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can probably remove this entire GET section as it's unsupported. I don't think it's necessary here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed this GET section
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 @benbosman Thanks for the quick updates to this contract. Also your explanations to a few previous request make sense & I've resolved those conversations leaving the contract as-is. One final minor request is to enhance the wording of this 422 error description: https://github.com/DSpace/Rest7Contract/pull/41/files#r375304904
Beyond that, this looks good to me. I'm already casting my +1 vote as the final change I've requested is really minor in nature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @benbosman It looks good to me, I have made just few inline note about minor typos that I expect to be fixed quick
|
||
This supports a basic search in the metadata. | ||
It will search in: | ||
* UUID (exact match) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if this is the already implemented behavior I'm fine to keep it, otherwise I would suggest to exclude UUID from the search as it is "by Metadata"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did indeed base this on the current implementation to avoid having to create a different service implementation
Merging, as this is at +2 |
[CST-11043] submission notify panel Approved-by: Andrea Bollini
Related ticket: https://jira.lyrasis.org/browse/DS-4026