For some cases (like coming env vars) we will need to also pass a
repository id to the URL, so I'm passing it from createRecord and other
methods which handle records.
When I started working on settings I had a bit different vision on tabs
and I've added that code prematurely. It seems that the best way to go
is to create separate routes and controllers for each tab - that way we
can just rely on Ember.js for customizing, not some custom code in tabs
helpers etc.
A while ago I introduced a change to auth code which signs out user on
failed try to get user data. The problem with it was it signed out on
all kind of errors, like network error. I changed the code to log out on
401 status, but I haven't tested it properly, we actually return 403 on
unauthenticated queries for user data.
We no longer need this check, because it was only relevant with Ember
Data. Additionally it was a cause of a travis-ci/travis-ci#1992, because
of wrong syntax:
unless someFunction false or true
will only check for a result of someFunction with an argument being the
result of `or` expression.
User data needs to be refreshed on sign in, otherwise we don't have
fresh data regarding isSyncing property and other fields which can
change between refreshing page.
This commit changes a way we load accounts for profile view:
* instead of using several views with profile controllers, always use
one view to render hooks. This is achieved by redirecting to
individual account page from main profile page (for example when going
into /profile as a user drogus, the effective address will be
/profile/drogus)
* instead of using observers to wait for accounts to load I just use
promise in ProfileRoute#model which effectively ensures that accounts
are loaded at the time we want to select an individual account
* profile controller is split into profile and account controller
Specyfing "pane" as an outlet name here was a legacy thing. In current
form it doesn't give us anything and results in more code, as we need to
specify outlet everytime we want to render something there.
We use promise when fetching a repository which means that any nested
routes already have all the repository data loaded. Thanks to that there
is no need to setup observers, we can check what to render right away in
RepoIndexRoute
