Bug #6640
Updated by Tom Clegg about 9 years ago
h2. Background I (Brett) have I've attached two screenshots of the projects menu pulldown in two tabs opened back-to-back in the same session. They don't show the same list of projects. Presumably this has something to do with me being an admin, and there's some explicit or implicit limit on the number of projects Workbench renders. At the very least, the menu should always render all of my own projects, and it should always render the same set of projects. We can hash out how we want to deal with large project lists generally. I (now Tom) am guessing the "unpredictable subset of projects shown" bug means Workbench is fetching only one page of projects from the API, and without specifying a predictable order. But the real problem here is that we are _trying_ to show the entire set of readable projects in a dropdown in the first place. Rather than try to make the bogus UI work better, we're going to change the UI. h2. Implementation Instead of trying to show a large number of projects in a dropdown the "projects" drop-down should reduce to: * a "Search all projects (N)" item, where N is the total number of projects readable by the current user. This opens the "search projects" dialog, much like the existing "move to project..." feature does but with a "Show" action button instead of "Move". * a "Browse public projects" item. Just like we have now, but formatted as a menu item instead of a button. * a heading "My projects" * the current user's "Home" project * directly under "Home", a "[plus-icon] Create a new project" link. Just like we have now, but situated underneath Home (just like the new project will be) and formatted as a menu item instead of a button. If the "plus" icon isn't enough to set this off visually from the existing projects, perhaps bold or colored text will help? (Experiment/screenshot/test on some unsuspecting bystanders?) * the hierarchy below it (just like we have now) Similarly, the "project" dropdown in the "search" dialog should lose the "projects shared with me" part: only "All projects" and the "My projects" hierarchy will remain. The current API doesn't offer an efficient way to get a list of the current user's project hierarchy. For now, we'll just do it the way we do now (i.e., do multiple API calls to get all projects, arrange them into trees, and just show the tree whose root is current_user.uuid) in order to improve the UI. Adding a more efficient API might be done concurrently or in the future, but is not a dependency of this UI change in any case. Meanwhile this story _does_ require a new test case (and perhaps some fixtures) that specifically confirms the original bug here is fixed: i.e., if a user has more than one page worth of projects, possibly even in the "My projects" hierarchy, the same subset gets loaded every time (presumably this subset will be the full set).