Skip to content
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

Merged
merged 28 commits into from
Feb 13, 2020
Merged

Group and eperson management #41

merged 28 commits into from
Feb 13, 2020

Conversation

benbosman
Copy link
Member

@benbosman benbosman commented Dec 19, 2018

Related ticket: https://jira.lyrasis.org/browse/DS-4026

  • Created a Rest Contract for EPerson Groups (some of the API behavior already exists in the API)
  • Updated the Rest Contract for EPersons (some of the API behavior already exists in the API)
  • Created a Rest Contract for adding child Groups to parent groups (and deleting, querying)
  • Created a Rest Contract for adding EPersons to parent groups (and deleting, querying)

Copy link
Member

@abollini abollini left a 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)

epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersons.md Outdated Show resolved Hide resolved
group2eperson.md Outdated Show resolved Hide resolved
epersons.md Outdated Show resolved Hide resolved
Copy link
Member

@tdonohue tdonohue left a 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.

epersongroups.md Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersons.md Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersons.md Show resolved Hide resolved
@cwilper
Copy link
Contributor

cwilper commented Feb 28, 2019

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
Removing duplicate section
Copy link
Member

@tdonohue tdonohue left a 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 Show resolved Hide resolved
epersongroups.md Outdated
**GET /api/eperson/groups/<:uuid>/parentgroups**

Retrieves direct parent groups of the given group.
Requesting indirect parent groups is not supported
Copy link
Member

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.

Copy link
Member

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

epersons.md Show resolved Hide resolved
Copy link
Member

@abollini abollini left a 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 Show resolved Hide resolved
epersongroups.md Outdated
**GET /api/eperson/groups/<:uuid>/parentgroups**

Retrieves direct parent groups of the given group.
Requesting indirect parent groups is not supported
Copy link
Member

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

epersongroups.md Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersons.md Show resolved Hide resolved
epersongroups.md Show resolved Hide resolved
@benbosman
Copy link
Member Author

I've updated this PR to prepare it for the beta 2 sprint implementation.
There are quite a few small fixes to the contract, and I've removed the parentgroups endpoint completely since it's not even implemented in the service, so most likely not relevant

Copy link
Member

@tdonohue tdonohue left a 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
Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

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 Show resolved Hide resolved
epersongroups.md Show resolved Hide resolved
epersongroups.md Show resolved Hide resolved
epersongroups.md Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
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**
Copy link
Member

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".

Copy link
Member Author

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**
Copy link
Member

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

Copy link
Member Author

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.
Copy link
Member

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.

Copy link
Member Author

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

epersons.md Show resolved Hide resolved
Copy link
Member

@tdonohue tdonohue left a 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.

Copy link
Member

@abollini abollini left a 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

epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved
epersongroups.md Outdated Show resolved Hide resolved

This supports a basic search in the metadata.
It will search in:
* UUID (exact match)
Copy link
Member

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"

Copy link
Member Author

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

@tdonohue
Copy link
Member

Merging, as this is at +2

@tdonohue tdonohue merged commit d487d80 into DSpace:master Feb 13, 2020
@benbosman benbosman deleted the group-person branch March 6, 2020 09:15
abollini pushed a commit to 4Science/Rest7Contract that referenced this pull request Nov 10, 2023
[CST-11043] submission notify panel

Approved-by: Andrea Bollini
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants