Idea #8286
closed
[API] [Workbench] Allow users to choose which projects appear in their dropdown area
Added by Sarah Guthrie over 8 years ago.
Updated about 8 years ago.
Assigned To:
Radhika Chippada
Description
Background¶
Users find the fact that certain important shared projects are not visible to them unnerving, and often conclude the project no longer exists.
Using the search bar or "search all projects" is a temporary workaround, but is not intuitive.
It would be wonderful to be able to "star" shared projects that one wants to appear in the dropdown to avoid this problem.
This is a subset of the more general feature described by #5668 where any object can be starred/favorited.
Implementation¶
API side:
- Functional test: User UA creates project PA and shares it with user UB. User UB stars it. User UA deletes PA. Confirm: the deletion is successful; user UB's "star" link also gets deleted; user UA can see the log entry for the deletion of the "star" link.
- Functional test: User UA creates project PA and shares it with user UB. User UB stars it. User UA unshares PA. Confirm: UB cannot see PA. Now, user UA re-shares PA with UB. Confirm: user UB still has a "star" link for PA.
Workbench side:
- If a user is logged in, the "show project" page has a "star" icon ("fa-star-o" or "fa-star") to the left of the project title.
- If a "star" link exists (link_class="star", tail_uuid=current_user.uuid, head_uuid=project_uuid), the icon is "fa-star"; clicking the icon deletes the "star" link and changes the icon to "fa-star-o".
- If no link exists, the icon is "fa-star-o"; clicking the icon creates a new "star" link and changes the icon to "fa-star".
- Clicking the "star" icon creates/removes a "star" link
- When building the project dropdown menu (for the breadcrumb/nav dropdown, and for the dropdown in the search/select modal),
instead of retrieving the set of all readable projects and arranging them in a tree structure: above the "my projects" tree view:
- retrieve all star links with
filters=[["link_class","=","star"],["tail_uuid","=",current_user.uuid],["head_uuid","is_a","group"]] and select=["head_uuid"]
- retrieve all groups with
filters=["uuid","in",returned_head_uuids], order=["name"]
- just display them flat, in the order they appear in the API response; remove the "build project tree" code.
(acknowledging note-8 by deferring the "remove the all-my-projects tree" part to #8183)
- Target version set to Arvados Future Sprints
- Tracker changed from Bug to Idea
- Subject changed from Allow users to choose which projects appear in their dropdown area to [Workbench] Allow users to choose which projects appear in their dropdown area
- Favorites indicated by link
- Modal star icon on the project show page to create/destroy that link
- Projects pulldown in navbar and search popup only lists favorite projects, ordered by name ascending
- Subject changed from [Workbench] Allow users to choose which projects appear in their dropdown area to [API] [Workbench] Allow users to choose which projects appear in their dropdown area
- Description updated (diff)
- Target version changed from Arvados Future Sprints to 2016-02-17 Sprint
- Category set to Workbench
- Assigned To set to Radhika Chippada
a6310e8b0eedce1323f02d285c0709516558f937
Branch 8286-fav-projects implements star/unstar of projects. And, the projects dropdown in breadcrumbs is updated to display only starred projects instead of all "my projects".
I am concerned that impelementing this story description would result in serious compromising of user experience. It is my understanding that the science team expressed much concern when we last updated the projects dropdown and removed shared projects from it. This update is going to basically hide even the my projects and instead display only my favorite projects. In the little time I used this current update to manually test, I found it quite an ordeal to access any of my non-starred projects; I need to use the search box, which does not do a good job distinguishing between "my" and "shared" projects.
I suggest something like this instead. The projects dropdown shows two (actually three) sections: "My favorites" and "My projects". (We might even want to add back another section "Shared projects" like a few months ago). I think this will work well in a scenario where a user may have just a handful of favorites, but quite a few other "my" projects and several shared projects.
I support the project dropdown with 2 sections (My favorites and My projects). That will solve the usability problems that lead to the creation of this story.
- Description updated (diff)
I made this story a priority because of the fact that Workbench crashes when a user can see many projects. If this story no longer covers that, than I would like to see #8183 prioritized.
I really would encourage everyone to express concerns about planned interface changes during backlog grooming. It is difficult to plan software development when the story changes after the branch is written.
- Story points changed from 2.0 to 1.5
- Status changed from New to In Progress
Notes regarding updates in branch 8286-fav-projects
API side functional test: User UA creates project PA and shares it with user UB. User UB stars it. User UA deletes PA. Confirm: the deletion is successful; user UB's "star" link also gets deleted; user UA can see the log entry for the deletion of the "star" link.
We currently cannot delete a group that has any associated objects such as sharing links etc. I would assume this is case when it has other objects such as sub projects, collections, pipelines etc (though I did not specifically verify). So, I think this test requirement is not in scope for this story. Supporting deleting of groups should be separate ticket that can be addressed as time permits.
API side functional test: User UA creates project PA and shares it with user UB. User UB stars it. User UA unshares PA. Confirm: UB cannot see PA. Now, user UA re-shares PA with UB. Confirm: user UB still has a "star" link for PA.
I added a test for this on API side. I also added a workbench controller test since it does much better verification of the star link being excluded / included in the favorite projects tree. Also, added an integration test that actually clicks the Star icon to star/unstar as expected.
Workbench side:
- Added "star" icon to the left of project name in project#show
- In order to refresh the star icon without refreshing the whole page, I refactored the breadcrumbs code out of body.html into _breadcrumbs.html partial
- So the Project drop down now displays Favorites first and then "My projects"
- Added link to Home in Favorites section as well.
- Thus. link to Home is now included in both Favorites and MyProjects section. This helps avoid the need to scroll down all of the Favorite projects (assuming there are a handful of them) to get to it in MyProjects section.
- I think we can consider "cleaning up" after merging this branch into master. This clean up would include updating the Chooser dialog to use the Favorites + MyProjects view and then removing the then unused build_projects_tree code.
- Category deleted (
Workbench)
Reviewing 8286-fav-projects @ 549adc0
For some reason I expected the star to be over on the right side with the rest of the button bar. I think it is okay where it is, though.
The star needs to be bigger. Suggest 18pt or 20pt.
The star should be a yellow or gold color (needs to have good contrast with the white background.)
Suggest tweaking the presentation:
Combining "Favorites" and "My projects" into a single list, and listing "Favorites" first with a star next to each one?
So instead of:
My favorite projects
Home
My fav!
blub
---
My projects
Home
My fav!
blub
Something like:
My projects
* My fav!
* blub
Home
My fav!
blub
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|commit:b39ef1930d3e1a608ef632ed8c4f81a02f91b99f.
- Increased the star icon size to fa-lg from fa-fw and set the color to a lighter shade of red (yellow or gold were too pale and quite invisible).
- Per our discussion on jabber, didn't address the comment in note 16 and left the two sections as such.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Radhika Chippada 
Updated by Sarah Guthrie 
Updated by