5apps/stashboard

A remoteStorage account dashboard

Stashboard

Stashboard is a dashboard application for managing one's remoteStorage account. It has been created by 5apps as the front-end for 5apps Storage.

Storage providers & developers

Feel free to use this for your own server implementation, and also to just re-use parts of the code (e.g. markup and styles).

If you are genuinely interested in adopting this front-end for your server implementation, we would also be willing to help with making the app more customizable, so that you wouldn't have to run a custom fork per se. The GitHub issues are open for any and all requests.

Users

For security reasons, it is not currently possible to log into your 5apps account when the app is not opened from rs.5apps.com. This may change in the future.

Prerequisites

You will need the following things properly installed on your computer.

• Git
• Node.js (with npm)
• Ember CLI
• Google Chrome

Installation

• git clone [email protected]:5apps/stashboard.git this repository
• cd stashboard
• npm install

Running / Development

• npm start
• Visit your app at http://localhost:4200.
• Visit your tests at http://localhost:4200/tests.

Running Tests

• ember test
• ember test --server

Linting

• npm run lint:hbs
• npm run lint:js
• npm run lint:js -- --fix

Deploying

• npm run deploy:staging or npm run deploy:production

stashboard's Issues

Remove footer links

Fix account settings link

Right now the link is relative (/account/settings), but should link to the full URL including the base domain name instead.

Add note for users with JS disabled

Some privacy-conscious users will inevitably arrive with JS turned off. They may not yet have learned that RS apps are all JS. Just adding a simple sentence explaining it would help to not be stuck with an empty page and potential nerd rage.

Should contain a link to the RS website for understanding details.

TypeError: t.errors is undefined

https://sentry.io/organizations/5apps/issues/1502053445/?referrer=github_plugin

TypeError: t.errors is undefined
  at callback (storage-frontend/routes/application.js:33:1)
  at invokeCallback (rsvp.js:494:1)
  at publish (rsvp.js:477:1)
  at publishRejection (rsvp.js:413:1)
  at invoke (backburner.js:384:1)
...
(4 additional frame(s) were not displayed)

If user logged in without "remember me" checked, use session storage for OAuth token

Currently, as a user logging into the site, you would expect to not stay logged in after closing the session, unless you check the "remember me" box (which, btw, we should probably explain better in a hover title or sth).

However, now that the OAuth token for the storage front-end is stored on the client-side, this behavior is not the case anymore. I'd propose to switch to sessionStorage instead of localStorage, in case the remember me box hasn't been checked. This info could be given to the front-end as a state param in the OAuth redirect.

Always doing auth redirect when using SessionStorage

In Firefox, even though the storage seems to survive page reloads (as intended and documented by Mozilla), it always does the auth redirect for me when reloading the page. Not sure if it's a bug in Firefox or Ember Simple Auth, or Stashboard.

Can someone confirm this?

Use ServiceWorker for caching app assets

See e.g. Webmarks or Hyperchannel for Ember add-on usage.

Deploy to production

• Set up Deploy app on rs.5apps.com
• Deploy the app

Move deploy target config to dotenv

We shouldn't hardcode deployment configs like e.g. API URLs, Sentry DSN, etc.. in the main environment config file. These values should come from .env.staging etc..

TypeError: Cannot read property 'length' of null

https://sentry.io/organizations/5apps/issues/1510122910/?referrer=github_plugin

TypeError: Cannot read property 'length' of null
  at generatedDetailedMessage (addon-tree-output/@ember-data/adapter/rest.js:1089:1)
  at apply (addon-tree-output/@ember-data/adapter/rest.js:817:1)
  at apply (addon-tree-output/ember-simple-auth/mixins/data-adapter-mixin.js:65:1)
  at handleResponse (@ember/-internals/utils/index.js:427:1)
  at ajaxError (addon-tree-output/@ember-data/adapter/rest.js:1142:1)
...
(9 additional frame(s) were not displayed)

TypeError: Cannot read property 'split' of undefined

https://sentry.io/organizations/5apps/issues/1739553292/?referrer=github_plugin

TypeError: Cannot read property 'split' of undefined
  at call (stashboard/models/user.js:24:1)
  at callback (@ember/-internals/metal/index.js:3458:1)
  at untrack (@ember/-internals/metal/index.js:1413:1)
  at get (@ember/-internals/metal/index.js:3457:1)
  at obj (@ember/-internals/metal/index.js:1003:1)
...
(31 additional frame(s) were not displayed)

Looks like this errors happens while the user profile data is still loading.

Fix endless redirects

Right now, when the network request to /users/me fails, the frontend just assumes an auth error and attempts to re-authorize. This leads to endless redirects between the 5apps server and the frontend app.

Instead it should only attempt the reauthorization when the request failed with an actual auth error, and show an error message otherwise.

Implement status alerts

We currently render status alerts from https://status.5apps.com in the front-end of the respective service. It would be useful to do this again in the new Storage UI.

Add Web Manifest and Storage icon with transparent background

Not sure if it should be set to fullscreen or not.

Use new RS widget for getting started page

Show storage address in topbar

Instead of just showing the username, it should show the whole storage address. Maybe with the "@5apps.com" less emphasised.

Link to help site from somewhere

Ellipsis on overlong app names doesn't work

Latest stable FF:

Rename account to dashboard?

What do you think about renaming the namespace from account to dashboard? Account is ambiguous, because we also have the actual account settings, and this frontend's "account" namespace is about the storage dashboard UI.

Update Ember

Use new header design

Deploy staging front-end to 5apps

Fix content layout issues on small screens

Open-sourcing the front-end

I think our original plans were for this front-end to be entirely open-source. Both because it's all client-side code anyway, and providing the sources makes it more trustworthy, but also because in theory any RS server author could use the code and adapt it for their server, so they wouldn't have to create their own UI for everything.

Questions:

1. Is that still the plan?
2. If so, when do we consider it ready to be open-sourced?

Upload source maps to Sentry and make sure everything works correctly

Add Sentry integration

Gotta be informed about exceptions.