Cannot easily tell similar named EPeople or Groups apart (usability issue)

[tdonohue]

Describe the bug
In testing other PRs, I've had to recently add some new EPeople & assign them to groups, I've found that the current UI screens rely too much on UUID and Name, making it very difficult to tell similar named EPeople apart. Examples below...

To Reproduce

Issue 1: Difficult to tell apart two EPeople of same name:

1. Create two EPerson users with the same name
2. Now, edit a group on the Groups page (http://localhost:4000/admin/access-control/groups)
3. Usability Issue: Search for an EPerson with that name...you will not be able to tell the users apart, e.g. in this screenshot there are two "Tim Donohue" Epeople, but no other information provided besides UUID:
   
4. Bug: Even worse, clicking on one of the names brings me to the list of Groups instead of to that EPerson.
5. EXPECTED BEHAVIOR: We should list an EPerson's email address next to their name (in same column or separate column) in any browse/search results, as an email address is a simple way of distinguishing two people.

Issue 2: Difficult to tell apart two Groups of a similar name:

1. Create two Collection Admin groups
2. Now, go to the Groups page (http://localhost:4000/admin/access-control/groups) and try to find the Collection Admin group of a specific Collection.
3. Usability Issue 1: You will be unable to tell the Groups apart unless you click on each Collection Admin group one by one.
4. Usability Issue 2: Now, click Edit on one of the Collection Admin groups. It's difficult to tell which Collection it refers to, unless you read the detailed note at the top of the page.
5. EXPECTED BEHAVIOR 1: Any Role-based Group should list the name of the Community or Collection next to it (either in the Name column or in a new column) in any browse/search results
6. EXPECTED BEHAVIOR 2: When editing a Role-based Group, we should show a Read-only field at the top which lists the Collection or Community name which the Group references.

[mwoodiupui]

email address may not work in some settings where netid is used. The EPerson may have a netid but no email. Probably we should display whichever is available. Which should we prefer if both are available? or should we just punt and show both?

Possibly this should be abstracted into a new EPersonService method. Then, if we someday invent a third external unique identifier possibility, we only have to fix the service and we'll be working in there anyway.

[tdonohue]

@mwoodiupui : Good point, I'd say for now we just display either netid or email (with a preference for email if available).

At this point, I'd recommend a quick fix here (as we are in the final stages of Beta 5). But, I'd like the opinion of others on the DSpace 7 team regarding the best fix. It seems (to me) we may already have all the information we need, we just are not displaying enough of that information.

[atarix83]

@tdonohue
For the issue 1 the possibility to show eperson's email and netid, if not empty, requires about 2hours.

Regarding the changes needed for the issue 2 the estimation is about 3/4 hours.
A further improvement should be to allow the collection name to be used to search the group but this requires a much larger rest side change in order to use solr. This requires to be discussed so it is to be deferred to another ticket for 7.1/7.2 release

[tdonohue]

@atarix83 : That all sounds fine. I've added a total estimate of 6 hours to this PR & kept it assigned to you for your team to work on. Keep in mind, this work is lower priority than finishing up any theming work, as technically these screens work, but they are just difficult to use.