Arvados

So I like what I've done so far. To finish it off - if this approach meets with approval - we would make it so that any operation that would change the count of one of the tabs would have as a side effect a $.get to the tab_counts url in the data attribute of the nav-tabs, which would update the counts in each tab's title.

Reviewing 893f659

• You could make tab_counts a little more predictable by using contents.items_available rather than contents.count. This tells you how many results the API server has, even it they didn't all fit in the response.
• As the guy who added @user_is_manager to this controller, if you're feeling gung-ho about moving this is a before_filter, I think that'd be a nice improvement. I don't think it's necessary for this story, though, if you'd rather put it off. Your call.

Thanks.

Done, as you've recommended.

Now, the thing is, if we like this approach, we have to do another iteration to properly complete this story. Unless there is some existing hook I don't know about, we'll want to find all the various AJAX actions that could alter these counts and have them trigger an event that we listen for. Right now it only listens for document ready. Am I thinking along the right lines?

Phil Hodgson wrote:

Now, the thing is, if we like this approach, we have to do another iteration to properly complete this story. Unless there is some existing hook I don't know about, we'll want to find all the various AJAX actions that could alter these counts and have them trigger an event that we listen for. Right now it only listens for document ready. Am I thinking along the right lines?

I think you're right that that's the next step. I don't know if it's strictly necessary before you merge your current work—defining the exact scope of story requirements is Tom's job. This bug report seems primarily concerned with "tell me if there are zero items so I don't bother clicking the tab," so I could see a case for having a separate follow-up story.

If you do go ahead, the only action I'm aware of that changes the count dynamically is the delete icon on each row. Creating items usually whisks you off to the page for the new thing, so most of the other obvious candidates are out.

Well if the only places to track changes are on deletions then the job's pretty easy, so I just did it now and committed. I added a javascript event called "count-change" which gets fired from destroy.js.erb and remove_items.js.erb. It will be easy to add triggers elsewhere if it turns out other actions can change the count.

If it all still seems sane, I can go ahead and merge.

Okay, I've created a new before_filter. I was overly concerned about before_filter ordering, which behaves as we would like and expect (ApplicationController before_filters go first). Rather than specifying the same :except list for the new before_filter, I just made it conditional on @object being set, which is all that it really cares about. The Workbench test suite passes.

I also addressed your other observations. Thanks for your patience!

Phil Hodgson wrote:

I also addressed your other observations. Thanks for your patience!

Thank you. 3ef64886 looks good to merge, so go for it.