Bug #6234
closed[Workbench] Admins should be able to edit their own user records, and view other users' home projects" from title
Description
Admins need to be able to see their own user page to manage their group memberships, etc.
Right now, going to the usual URL for that renders your home project. This was first filed as #3756. We fixed this by making the user page inaccessible, and hiding the Show button for it from the users listing.
It's now clear we need a better solution. In #3756, Tom suggested implementing a "better way to ensure {"move this project to..." → Home → OK} redirects to projects#show with uuid=current_user.uuid instead of users#show." He noted that "solution is a waste of trouble if we decide to switch to the "special undeletable project" implementation for "Home"," but we still haven't done that, so it seems like it's time to implement the longer solution and undo the Show button hiding hack.
After this change (subject to permission, of course):- {workbench}/projects/{user_uuid} will show the home project of the given user
- {workbench}/groups/{user_uuid} will redirect to /projects/{user_uuid} if necessary/convenient (this might not be necessary any more, but it doesn't seem to break anything either, so it's fine to leave it alone).
- {workbench}/users/{user_uuid} will show the "edit/manage user" page for the given user
Updated by Brett Smith over 9 years ago
- Description updated (diff)
- Category set to Workbench
- Target version changed from Bug Triage to 2015-07-08 sprint
Updated by Brett Smith over 9 years ago
- Subject changed from [Workbench] User can not edit oneself to [Workbench] User can not edit oneself/Cannot view other users' home project
Updated by Tom Clegg over 9 years ago
This bug will be trivial to fix if we resolve the "owner_uuid can be a user or a project" design oddity: i.e., change from "home project == user" to "each user has exactly one home/default project". See #6274
Updated by Brett Smith over 9 years ago
- Subject changed from [Workbench] User can not edit oneself/Cannot view other users' home project to [Workbench] User cannot edit oneself/view other user's home project
Updated by Radhika Chippada over 9 years ago
- Assigned To set to Radhika Chippada
Updated by Radhika Chippada over 9 years ago
- Status changed from New to In Progress
Updated by Tom Clegg over 9 years ago
- Subject changed from [Workbench] User cannot edit oneself/view other user's home project to [Workbench] Admins should be able to edit their own user records, and view other users' home projects
Updated by Radhika Chippada over 9 years ago
- Subject changed from [Workbench] Admins should be able to edit their own user records, and view other users' home projects to [Workbench] Admins should be able to edit their own user records
Updated by Radhika Chippada over 9 years ago
- Subject changed from [Workbench] Admins should be able to edit their own user records to [Workbench] Admins should be able to edit their own user records, and view other users' home projects" from title
Reverted previous title update.
Updated by Radhika Chippada over 9 years ago
About updates in branch 6234-user-edit-self:
- Admin user can now see the "Show" button in /users page and access it
- Also, updated to allow admin user to see other users' home pages
- Added Home project link in each row of /users page
- I added the Home project link for root as well as anonymous users. If we hate it very much, I can add logic to suppress these for specific users.
- I didn't do anything about second from last bullet point in description "{workbench}/groups/{user_uuid} will redirect to /projects/{user_uuid} if necessary/convenient (this might not be necessary any more, but it doesn't seem to break anything either, so it's fine to leave it alone)." I noticed that /groups/{user_uuid} does not currently work in production. And, since it does not seem necessary, I did not want to invest the time to address this as part of this exercise.
Updated by Peter Amstutz over 9 years ago
Per our discussion, it is extremely confusing when you are viewing the home project of (or any project owned by) another user but the "Home" link in the breadcrumbs bar links to your own home project. This is a preexisting bug, but with the ability to visit other user's home projects it is now even more confusing.
This should be addressed, ideally by having the "Home" link in the breadcrumbs change to point to the topmost owner of the project currently being viewed. There are two other links on the page to your own home project so this does not hurt navigation in any way.
Updated by Peter Amstutz over 9 years ago
Proposed behavior for breadcrumb rendering:
- When looking at your home project or a subproject of your home project, show "Home" at the root of the breadcrumbs
- When looking at another user's home project, put the name (or username or email address) at the root of the breadcrumbs
- When looking at a subproject owned by another user, but we can't read all the way to that user's home project, put the name (or username or email address) at the root of the breadcrumbs with a rendering style to indicate clicking is disabled.
- When looking at the home project for a group, put the name at the root of the breadcrumbs
- When looking at a subproject owned by a group, but we can't read all the way to the group home project, put the name at the root of the breadcrumbs with a rendering style to indicate clicking is disabled.
Updated by Tom Clegg over 9 years ago
Moving further discussion of breadcrumbs to #3573.
Updated by Brett Smith over 9 years ago
Peter Amstutz wrote:
Per our discussion, it is extremely confusing when you are viewing the home project of (or any project owned by) another user but the "Home" link in the breadcrumbs bar links to your own home project. This is a preexisting bug, but with the ability to visit other user's home projects it is now even more confusing.
This should be addressed, ideally by having the "Home" link in the breadcrumbs change to point to the topmost owner of the project currently being viewed. There are two other links on the page to your own home project so this does not hurt navigation in any way.
As evidenced by the discussion since, fixing this bug is a story in its own right, and it's not high enough priority to disrupt the current sprint for. Let's deal with #3573 separately, and leave it out of scope for this story. Thanks.
Updated by Radhika Chippada over 9 years ago
- Status changed from In Progress to Resolved
Applied in changeset arvados|commit:665b0fbe5f57866f9d0183a08e713fe07e8db8de.