We don't want to subscribe if we're at any other routes, because there is no
data there. The main target is to avoid all of the notifications from a common
channel if we're on the /dashboard route.
For some reason when we run get('build.jobs.firstObject.id') it returns
different result than get('build.jobs').objectAt(0).get('id'). I can't reproduce
it on a clean Ember application, so it's probably a consequence of something
that we do in our views.
We added regenerate key button in order to allow people reset their private key
on Travis CI after a possible security breach. Travis CI users can't leak the
key, because they don't even have access to it, so at this point it's not needed
anymore.
Almost all actions on views were not properly handled, because they were still
methods directly on a view object rather than in `actions` property. This commit
fixes it.
This commit starts refactoring of one of the remaining areas where we do weird
tricks to get the desired behaviour. Namely, we were treating "my_repositories"
and "recent" not as individual routes with separate URLs, but only different
states on the repos controller. Such approach leads to various problem with
connecting outlets on rerenders (ie. we don't explicitly connect outlets when
changing from one view to another programatically).
A new cleaner way is to change both tabs into routes.
Layout handling in travis-web was implemented in a dynamic way, so we
could change a main layout from any of the routes. This needed a
`rerender` call which was making things harder and needed some hacks. It
also broke a few transitions when upgrading to 1.8.1.
After examining our usage of layouts I've noticed that we don't need to
change the entire layout dynamically and instead we can set layout on
root routes (like "index", "profile" and other root routes).
My understanding is that this setting is actually a value used to
control job concurrency, not build concurrency, so this clarifies that
by referring to jobs instead of builds.
