UI Improvements for Manage Groups/People

[artlowel]

I suggested a number of UI improvements in my review of #613

I discussed them with @tdonohue on slack and while they weren't critical issues and there wasn't time to fix them right away, we agreed to move them to this ticket so they could be handled as soon as there was time.

Those suggested improvements were: (original comment)

• Please add a trail:
  • Home > Manage (Groups|People)
  • Home > Manage (Groups|People) > New (Group|Person)
  • Home > Manage (Groups|People) > Edit ${name}
• I think it would be clearer if the EPeople and Groups sections on the edit group page were separate tabs.
  • I'd also rename "EPeople" to "Members" and "Groups" to "Subgroups"
  • And put the number of members/subgroups next to that tab name, that way you can see the number without having to go to that tab.
• It would also be nice if a search query was part of the URL, that way if you click on a result, and then go back, you don't have to re-enter your query
  • This can work on the Manage Groups page, not currently on the edit group page because there are multiple search boxes
  • But if the edit group gets tabs, and they get URLs of their own, then there's only one search box per page anymore.
• I'd add css widths the columns of the results tables, so they're consistent across all of them.
• I'd remove the border-bottom from the add EPeople and add Subgroup headers the two borders underneath on another looks weird and the "browse all" button doesn't help matters.
• The cancel and submit buttons on the edit group form and the border above them aren't algined with the rest of the page. The same happens on the edit eperson page.
• The edit EPerson page doesn't have its own URL. Meaning if you click away from it and go back, you'll end up on the list page again

Related ticket #1059

[tdonohue]

An additional improvement:

• Per PRs Edit Community - Assign Roles/Groups #632 and Edit collection - assign roles groups #643 , when an Administrator starts from the Edit Community / Collection interface, and clicks on a role-based Group to edit, they jump over to /admin/access-control/groups/[uuid]. At that point, there's not way to return to the Edit Community/Collection interface.
  • This might be resolved either via a smarter "trail" (which knows whether you started Group editing from Manage Groups or from a Collection/Community Edit page). However, that may be more complex.
  • Or, it could simply be a link/button from a role-based group back to editing of the Community/Collection it is associated with. A role-based group can be determined based on whether the Group has a related DSpace Object

[tdonohue]

From #653 (comment), the Manage People interface should also include a button to "Impersonate an EPerson" next to the Edit/Delete buttons.

[bbranan]

Related to:

• It would also be nice if a search query was part of the URL, that way if you click on a result, and then go back, you don't have to re-enter your query

It would be nice if the page number were maintained so that when you edit a group on page 3 of a group search, then select "Back", you're taken back to page 3 rather than to page 1.

[bbranan]

Also, the Groups search results table should include a column that includes information about the community or collection that is managed by each auto-generated group.

Browsing through pages of groups that all have names like COLLECTION_a1fea3fc-b0d8-401b-82cb-ca15b59c5c12_ADMIN and no other information to indicate what that might mean makes it really hard to track down which group you need to edit to give someone the permissions they need.

[tdonohue]

See also #1059