Arvados

How do we want to prevent page refresh on the dashboard refreshing the recently finished pipelines panel when the user has scrolled down and viewing "next" page(s)?

Do we want to "disable" page refresh to the panel in that scenario?

Discussed this feature with Tom some more. We agreed that instead of adding infinite scrolling to the dashboard panels, we should add infinite scrolling to individual pages such as pipeline_instances page.

At 7b4fc9f...

• -  <tbody data-infinite-scroller="recent-pipeline-instances-scroll" 
  +  <tbody data-infinite-scroller="#recent-pipeline-instances" id="recent-pipeline-instances" 
  

• -  data-filterable-target="table.arv-recent-pipeline-instances tbody" 
  -  data-filterable-target="table.arv-recent-pipeline-instances > tbody" 
  

• (Or even use the id of the tbody itself, if you add one as above)

Search/filter shouldn't require a remote form (I don't think we want Rails to do its remote:true ajax stuff here -- as is, the button generates a useless request, the result of which gets ignored somehow). Can it just be an input tag, like the search box in views/application/_choose.html.erb?

The params[:partial] handling in ApplicationController looks like it could fit inside the existing f.json{} instead of mirroring the logic. (As it stands, non-json with params[:partial] will render nothing at all, which doesn't seem like an important feature to add/preserve.)

I think we should get rid of the "pretend there is no next page if any filters were passed" stuff, and concentrate instead on making next_page_href (and everything else) propagate the filters to the next page correctly.

• partial: "show_#{params[:partial]}.html", formats: [:html]

Tom, addressed all your feedback. Also, search works with scrolling now for this page. Thanks.

Tom, question about apps/workbench/app/views/pipeline_instances/index.html.erb :

Does the "compare" form defined at line 2 work? I selected a couple of instances and still did not see the button. I then removed the "disabled: true, style: 'display: none'", just for testing, and clicking on the button (after selecting 2 or 3) gives Not found error for the URL "https://localhost:3031/pipeline_instances/compare?utf8=%E2%9C%93&commit=Compare+2+or+3+selected". Not sure if it worked before but was broken somewhere along the way or never worked. I don't think I found any tests for it. Let me know if you would like me to file a bug for this.

<%= form_tag({action: 'compare', controller: params[:controller], method: 'get'}, {method: 'get', id: 'compare', 
class: 'pull-right small-form-margin'}) do |f| %>
  <%= submit_tag 'Compare 2 or 3 selected', {class: 'btn btn-primary', disabled: true, style: 'display: none'} %>
  &nbsp;
<% end rescue nil %>

Radhika Chippada wrote:

Does the "compare" form defined at line 2 work?

This seems to have been broken by the tab loading code: the handler wasn't getting attached because the checkboxes weren't present at initial page load time. I've pushed a fix, 6c7bfabc, to your 4024 branch. Unfortunately it interferes with the layout (the search box next to the "compare" button looks a bit odd).

Radhika Chippada wrote:

Tom, addressed all your feedback. Also, search works with scrolling now for this page. Thanks.

Looks good! Couple of notes:

• +    if params[:search].andand.length.andand > 0
  +      @select ||= PipelineInstance.columns.map(&:name)
  +      base_search = PipelineInstance.select(@select)
  +      @objects = base_search.where(any: ['contains', params[:search]]).
  +                              uniq { |pi| pi.uuid }
  +    end
  +
  

1. View the pipeline instances page
2. Type a string in the search box
3. Click one of the pipelines to show the pipeline_instances#show page
4. Hit the browser "back" button
5. The instances page loads the first page of results
6. As soon as the first page is loaded, it erases and reloads again.

I suspect this means the first "first page load" AJAX happens before the filter state is properly set up. I think it would be a good idea to replicate this problem as a failing test case. If the solution isn't apparent, I wouldn't mind poking at it.

• merging 4388-workbench-update to eliminate javascript errors that were breaking workbench tests
• merging master
• fixing some resulting breakage (related to #3400).
  • 06afd90 3400: Do not fetch_multiple_pages in #index actions.
    • This caused infinite scroll to get all pages instead of one page at a time.
  • 83e73ed 4024: @limit override must happen before find_objects_for_index.
    • @limit=20 in pipeline_instances#index was being ignored.
  • 5d87bca 3400: Do not fetch API results just for the sake of looking up resource_class.
    • This used to cause one unnecessary API call; with 3400 it got much worse, causing an unnecessary fetch_multiple_pages

Tom,

• pipeline_instances page with no search string, with a matching search string works. However, if I were to enter a search filter with no matches (basically, some random / junk string), I see "Oops, request failed" error page. It appears that the response from API server seems incomplete / incorrect in this case.

#<NoMethodError: undefined method `+' for nil:NilClass>
/home/radhika/arvados/apps/workbench/app/controllers/application_controller.rb:227:in `next_page_offset'
/home/radhika/arvados/apps/workbench/app/controllers/application_controller.rb:238:in `next_page_href'
/home/radhika/arvados/apps/workbench/app/controllers/application_controller.rb:174:in `block (2 levels) in render_index'
/home/radhika/arvados/apps/workbench/vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_controller/metal/mime_responds.rb:258:in `call'
/home/radhika/arvados/apps/workbench/vendor/bundle/ruby/2.1.0/gems/actionpack-4.1.1/lib/action_controller/metal/mime_responds.rb:258:in `respond_to'
/home/radhika/arvados/apps/workbench/app/controllers/application_controller.rb:171:in `render_index'
/home/radhika/arvados/apps/workbench/app/controllers/application_controller.rb:214:in `index'

• I updated the integration test that is using "junk" search filter to assert that there is no error in page; this test fails for the time being due to this issue.