Arvados

I worked around the problem with this crude patch, which rips out the listing from the Projects dropdown:

workbench:/var/www/workbench.su92l.arvadosapi.com/current/app/views/layouts# diff body.html.erb.bu body.html.erb -uw
--- body.html.erb.bu    2016-01-11 20:25:33.411584442 +0000
+++ body.html.erb    2016-01-11 20:25:39.667584446 +0000
@@ -226,14 +226,6 @@
                 <% end %>
               </li>
               <li role="presentation" class="divider"></li>
-              <%= render partial: "projects_tree_menu", locals: {
-                  :project_link_to => Proc.new do |pnode, &block|
-                    link_to(project_path(pnode[:object].uuid),
-                      data: { 'object-uuid' => pnode[:object].uuid,
-                              'name' => 'name' },
-                      &block)
-                  end,
-              } %>
             </ul>
           </li>
           <% if @name_link or @object %>

Then I also added this patch at Tom's recommendation:

--- app/models/arvados_resource_list.rb.bu    2016-01-11 21:33:11.952660291 +0000
+++ app/models/arvados_resource_list.rb    2016-01-11 20:31:26.727584653 +0000
@@ -184,6 +184,7 @@
     api_params[:order] = @orderby_spec if @orderby_spec
     api_params[:filters] = @filters if @filters
     api_params[:distinct] = @distinct if @distinct
+    api_params[:limit] = 10000

     item_count = 0
     offset = @offset || 0

Note that the API server default max is 1000, so in reality the number of elements returned will be capped at 1000. Still, that's 10x fewer calls than before.

The code that builds the project tree is also used by the "move object to project / assign project to object" popup. So, we need to discuss and make sure we address (1) projects dropdown, and (2) project selection popup.

1. Start at Home and navigate through that tree (expanding one level means ~1 API call)
2. Starred projects
3. Search

How about a tree view that can expand/collapse one item at a time by clicking a caret? That would let you navigate your whole tree without any expensive queries.

(initial)     (after clicking   (after clicking
               ▶Project 2)       ▶Project 2c)

Home          Home              Home
 ▶Project 1    ▶Project 1        ▶Project 1
 ▶Project 2    ▼Project 2        ▼Project 2
 ▶Project 3      ▶Project 2a       ▶Project 2a
 ▶Project 4      ▶Project 2b       ▶Project 2b
                 ▶Project 2c       ▼Project 2c
                                     ▶Project 2c1
                                     ▶Project 2c2

Can we hook up all the AJAX to make that happen in the relevant dropdowns?

I'm guessing it will improve usability if we move this nav element out of dropdowns... hopefully that doesn't have too much impact on the implementation and it can be a separate story.

The proposal in note 13 still does not address the entire problem. The tree building code is also used by the popup to move an object into a project. So, assuming we can pull of an expanding tree as in note 13 #8183-13 for "My projects", how do we handle the move object scenario; more specifically the "Projects shared with me" portion of the tree in this popup?

branch 8183-projects-dropdown: 97e018a1a8b9d4da6c99a9eb7be36a7f368615f9

• Projects dropdown is updated to show only toplevel projects. Updated views/application/_projects_tree_menu.html.erb accordingly.
  • Now 'My projects' lists only toplevel projects. One issue I noticed with this: let's say I have a project with 2 or more levels of subprojects. Home -> Project 1 -> Project 1.1 -> Project 1.1.1. The search dialog (accessed by clicking on search link in topnav) shows toplevel projects in 'My projects'. I see Porject 1 in it. If I click on it, the left portion of search dialog now display Project 1.1. I do not have a way of going to Project 1.1.1. The only way to go to it is by knowing it's name and entering it in the search box in the dialog.
  • Being able to build the expandable list as in note-13 #8183-13 should help resolve this issue.

• The dialog displayed when an object is moved to a project 'views/projects/_choose.html.erb' is untouched and hence will continue to use the previous implementation of tree building

The message "Showing X of your projects out of Y total projects" gives a count of all projects that accessible to you. However, this is misleading because the count includes projects shared with you that are currently never displayed in the menu. If possible, fix it to give the number projects you own, otherwise I suggest removing one or both of the numbers and changing the text to say something like "Showing your top projects, some projects have been omitted".

On further inspection, the behavior is even more confusing for the user:

If there are less than page_size*3 projects, they can see all projects (including those shared).

But if there are more than page_size*3 projects, then the shared projects go away entirely.

Also, if there are more than page_size*3 projects, the first request assigned to "all" is not used which means it the time spent making the request was wasted.

I suggest the routine should only use the code path that builds the tree for the user's own projects:

  def my_wanted_projects page_size=100
    return @my_wanted_projects if @my_wanted_projects

    from_top = []
    uuids = [current_user.uuid]
    while from_top.size <= page_size*2
      current_level = Group.filter([['group_class','=','project'],
                                    ['owner_uuid', 'in', uuids]])
                      .order('name').limit(page_size*2)
      break if current_level.results.size == 0
      from_top.concat current_level.results
      uuids = current_level.results.collect { |x| x.uuid }
    end
    @my_wanted_projects = from_top
  end

Implemented the update suggested in note 19 at 42db5188e104e94ce73d743edaafb1c2053e3c0c

Regarding note 20: We currently (already) do not show shared project. And, from conversations with Tom about this for this ticket and #8286, Tom wants to remove it from the chooser dialog also and instead wants the user to use the favorite projects feature to have access to them in this context.

I will check with Tom on Monday and act accordingly. Thanks.

We can probably put aside the question of whether we want to show shared projects for now.

However, I have another suggestion, which to limit the loop in #19 to up to three iterations, so it only shows projects up to three levels deep (and only makes a maximum of 3 API calls.)

884558f4505049685c7cdb5b50c4b8948f38cd1b

Enhanced code to display only the top three levels of projects. Improved the message displayed when projects / levels are omitted. Improved test a little more.