aptible / dashboard.aptible.com Goto Github PK

refs #51

If you navigate away from Stack#show and then click the back button, you are not returned to Stack#show.

This ticket audits our use of operations to ensure we are using them correctly across the board.

• Apps
  • Creation in wizard (does not require operation)
  • Provisioning upon wizard completion (happens at deploy)
  • Provisioning upon email verification (happens at deploy)
  • Creation (happens at deploy)
  • Update (unimplemented, possible to change handle, but there is no operation)
  • Destruction https://github.com/aptible/diesel.aptible.com/blob/master/app/app/deprovision/route.js#L18
• Services
  • Update (scaling container count) (#141) https://github.com/aptible/diesel.aptible.com/blob/master/app/app/services/route.js#L18
• Databases
  • Creation in wizard (does not require operation)
  • Provisioning upon wizard completion https://github.com/aptible/diesel.aptible.com/blob/master/app/welcome/payment-info/route.js#L99
  • Provisioning upon email verification https://github.com/aptible/diesel.aptible.com/blob/master/app/verify/route.js#L18
  • Creation https://github.com/aptible/diesel.aptible.com/blob/master/app/databases/new/route.js#L28
  • Update (unimplemented, possible to change handle, but there is no operation because we will not offer the chance to change disk size)
  • Destruction https://github.com/aptible/diesel.aptible.com/blob/master/app/database/deprovision/route.js#L18
• VHosts
  • Creation https://github.com/aptible/diesel.aptible.com/blob/master/app/app/vhosts/new/route.js#L35
  • Update https://github.com/aptible/diesel.aptible.com/blob/master/app/app/vhosts/edit/route.js#L27
  • Destruction (ref'd #123) https://github.com/aptible/diesel.aptible.com/blob/master/app/components/delete-vhost/component.js#L15
• Log Drains (discussed in #101) (issue: #138)
  • Creation https://github.com/aptible/diesel.aptible.com/blob/master/app/stack/log-drains/new/route.js#L20
  • Update (should update the log drain, then create an operation for "configure" — the UI does not currently allow a user to edit a log drain)
  • Destruction (unimplemented, and should not be)
• After deprovision operations (app, databases, log drains, vhosts) we propose that the API is responsible for deleting the resource after deprovisioning, and diesel will destroy the local version of that resource after the deprovision is complete (and no issue a DELETE API call for it).
  • server-side index endpoints will need to hide deprovisioning/deprovisioned entries
  • log drains don't have a button for delete, they can stay that way

• Staging deployment
• Forgot Password flow
• Email verification flow
• Create app styling
• Create db styling
• Auto-correct handles as typing (app, db)
• Create database needs size bar, type
• Style stack settings
• App show page
  • List services #21 PR open (#22)
  • scale services, add vhosts #23 PR open (#25)
  • History #24 PR open (#22)
  • Deprovision flow
• DB show page
  • Connection info
  • History

If they visit first-app or payment-info but already have a stack

The dropdown menu is obscured by the nav bar:

We should guarantee uniqueness of the following fields during signup flow. Ideally this validation can happen in context and should prevent a user from Nexting until they are addressed.

• User email
• Stack handle
• App handle
• DB handle

also

• Organization name (or handle) in #44

E.g.:

Currently we don't catch stack, app, or DB validation errors until the payment method step, which is confusing.

link to from databases or apps indexes

Per: #51

Rather than listing all organizations across the top, I think we can fit them into the user dropdown on top. For now, these will just link to the existing dashboard's organizations#show pages.

The API will return pagination info for collection resources (see https://github.com/aptible/api.aptible.com/pull/146). Diesel should use these to display pagination links, starting with the apps/:id/operations and and databases/:id/operations history pages.

Refs #28.

Diesel needs to read the roles for a user and permissions for a stack and use those to determine whether to show certain UI elements like the "create app" and "create database" links.

For the moment it should be sufficient to determine on a per-stack basis whether a user has the "manage" permission or not. The "read" permission is implied by the fact that the API returned the stack at all, and the "manage" permission is the only current permission that is required to be able to create/edit stacks, apps and databases.

See https://github.com/aptible/api.aptible.com/issues/144 for more on permissions and how they will change in the future.

A (probably) incomplete list of places in the UI where elements are conditionally shown based on the manage permission:

• Apps listing page
• App show page
• DB Listing page

display services, links for "operations" (audit trail) and deprovision.

If possible: add ability to edit services (scale containers, add vhosts)

from #20

There's a known bug in ember-data 14.1 that affects us, but when that is fixed this branch should be ready to merge.

Diesel is on 1.0.0-beta.12 now

from #51.

The empty app view screen shows info on how to deploy an app.
Should look like:

The delete button on the app vhost index page is not implemented.
It should be implemented to delete the vhost, or removed.

http://take.ms/mjhzO

from #20

• Index => 'Aptible Dashboard'
• Stack#show#apps => "${stack.handle} Apps - ${organization.name}"
• Stack#show#apps#new => "Create an App - ${stack.handle}"
• Stack#show#databases => "${stack.handle} Databases - ${organization.name}"
• Stack#show#databases#new => "Create a Database - ${stack.handle}"
• Stack#show#logging => "${stack.handle} Logging - ${organization.name}"
• App#show => "${app.handle} - ${stack.handle}" (note: this route currently immediately transitions to App#show#services, so this title would never be seen)
• App#show#services => "${app.handle} Services - ${stack.handle}"
• App#show#domains => "${app.handle} Domains - ${stack.handle}"
• App#show#domains#new => "Add a domain - ${app.handle} - ${stack.handle}"
• [ ] App#show#domains#edit => "Edit ${domain.virtual_domain} - ${app.handle}" (see #112)
• App#show#activity => "${app.handle} Activity - ${stack.handle}"
• App#show#deprovision => "Deprovision ${app.handle} - ${stack.handle}"
• Database#show#activity => "${database.handle} Activity - ${stack.handle}"
• Database#show#deprovision => "Deprovision ${database.handle} - ${stack.handle}"

from #51

Show last deploy and current git ref on app show page.

There's an 'edit' link on a vhost (domain) show page, but no route/template for editing yet.

• Edit page updates title to "Edit ${domain.virtual_domain} - ${app.handle}" (from #94)
  • style to match other pages
  • create "reprovision" operation after editing

@sandersonet Any important difference between an "add domain" page (shown below) and an "edit domain" page? Anything that should not be changeable when editing an existing domain?

Need to consider fixing the height for grid cells.

Required for launch

1. Apps & databases

• Operations history (infinite scroll?) (#29) (pagination of any kind is blocked by the API not supporting pagination)
• Scale slider, add db type selector (in progress: #33. PR: #37)
• Create disk when creating DB (#38 PR: #39 )

2. Roles & permissions

• Verify Stack permissions when CRUD apps/dbs (#42)
  • Users with a 'Privileged' role, can read and manage all stacks inside Org
  • User with Read or Manage permission can see a Stack and its apps and dbs
  • User must have Manage permission to edit stack settings, create/edit apps and dbs

3. First-time UX

• First-time wizard (#30)
  • Create SSH Key
  • Create App
  • Create Database
  • Configuration details

4. Deployment/CI

• Anything left here?

Optional for launch

1. Auth

• Account creation flow
• Organization creation
• Stack creation
• Password reset
• Invitation acceptance
• Organization switcher

Account on-boarding flow requires some Auth rework as we will have to move our Stripe integration from dashboard.aptible.com to auth.aptible.com.

2. User settings

• Profile
• Authentication settings: email/password
• SSH Key management

3. Organization settings

• Overview
  • Invitations CRUD
  • Member list
  • Billing Contact and Security Officer
  • Alert emails
• Stack management
• Role management
• Organization settings

#43 creates client-side validations for organization names. These should be expanded to check the server for an existing organization name.

After discussion with @fancyremarker we shouldn't DELETE /log_drains/:log_drain_id from diesel directly. Better to use a deprovision operation like we do when deprovisioning apps and dbs. The UI may need to change to avoid displaying deprovisioned log drains (treating them as though they are deleted).

refs #98

from #51

• total app containers used
• total disk size provisioned

Completed

• Invite acceptance functionality (@mixonic) #125
• Signup flow
  • Should restore users to previous state. E.g. if user exists before submitting payment information, they should not be able to skip to stacks/show
  • Currently, a stack is never actually created for a user when they enter payment information. After a subscription is successfully created, we should also create a stack that matches the subscription plan. We may need to update API to validate that stacks created have a valid type that matches the subscription level of the user. E.g. If a user has only a development subscription, they shouldn't be able to provision a production stack.
    • there is not form field for creating a stack. use the org name? Use the app name? - Currently we create a stack with the name ${organization.name} ${stack.type}
  • database should be provisioned after verification. App and db should be created after credit card data is entered (even before maybe, whatever is easier)
• Empty app view (screen 203) (#78)
  • An un-deployed app (app with no services) should show quick checklist for deploying their app.
  • Link out to manage SSH keys if user has none configured
• Improved styling#52
  • Sign up flow styling
  • New header and sub header styling
  • App/DB Index
  • App/DB Create
  • Service/VHost index
  • Service/VHost create
  • App/DB Activity
  • App/DB Deprovision
• Refactor existing ember app to match new design's architecture (screens 205 - 214)
  • Apps/DB index and new are now child outlets to Stack:show
  • Services, Vhosts, Activity, and Deprovision are child outlets to App:show
  • Activity and Deprovision are child outlets to Database:show
  • Soon stacks will return rate information from API. Consider how we'll use this with current container configuration to calculate an estimated cost of each service. (screen 212)
  • service list page (without rate information, for now) (in progress: #62)
• Paginated resources (screen 216)
  • Currently only applies to App/DB activity, but has bearing on eventual pagination of other resources and possibly compliance. (PR: #60)
• User settings (design unchanged)
  • SSH Keys display page (#66)
  • Email/Password display page (#66)
  • Name/Gravatar display page (#66)
  • SSH Key page allows user to add/remove keys
  • /settings/admin allows user to change email or password
  • /settings/profile allows user to change name (see #69)
• App show page
  • Populate last deployed by. Depends on 201-created/ember-data-hal-9000/issues/7 (PR: #88)
  • Populate current git ref. Depends on 201-created/ember-data-hal-9000/issues/7 (PR: #88)
  • Copy to clipboard for domain hostname (pr #88)
• Date format helper (in PR: #88 there is a format-date helper. See also #87)
• App create page
  • Handlify app handle as you type (#89)
• DB create page
  • Handlify db handle as you type (#89)
• DB deprovision (PR: #99)
• Logging (#98)
  • Log drain index (screen 210)
  • Log drain create (screen 211)
  • Remove stack settings page, instead Logging Configure should link to log drains
• Stacks Index page #92
• Multiple Organization UX #93
• Back button issues #95
• Bootstrap Components? (issue: #107, PR #108 ) I'd like to be able to use Tooltip, Popover, and Alert Bootstrap components, but I am not sure the best way to go about this. Angular has the popular UI Bootstrap library to handle this. Is there something comparable for Ember, or do we just have to write our own components?
• Update page titles #94 (PR: #113)
• Empty index pages need additional design #100
• Stack show page (#124)
  index
  • Total app containers used
  • Total disk size provisioned
• Forgot password functionality (@mixonic) #127
• Unverified account view (screen 201) (#128)
  • Don't block entire UX for unverified users. Provide glimpse of provisioned account and any "apps" they provisioned in set up flow.
  • Create the apps/databases but do not provision. Upon verification of a user, provision any apps/dbs they have not provisioned.
  • verify that deploys check for a verified user.
  • unverified users see a verify page (needs design for apps/dbs they have created)

Refs #28.

• port slider from dashboard
• port db type selector from dashbaord

the slider looks like:

Make the app/:id/services page match the design's implied features/behaviors as much as possible.

Looks like:

When the existing dashboard creates a new database, it also creates a disk (by queueing a provision operation) if the db creation succeeds.

Need to update diesel to do the same thing.

cc @fancyremarker Does that sound right to you? Or should the API be modified to accept a disk_size along with a POST to create a new db, and have the API handle both in the same action?

refs #28

These are of type operation and image, respectively, and are embedded by HAL.
The HAL adapter needs to be updated to handle embedded properties that have a different name (eg 'last_deploy_operation') than their type (eg 'operation').

See 201-created/ember-data-hal-9000#7

When creating a new App (or DB), a new record is created immediately when the route loads. If I then browse to another route and come back to apps/index, I see my unsaved app in the collection of other apps.

Unsaved resources should be immediately destroyed when the route exits and should not be accessible from any index pages.

After some thought, I think having an actual stacks index page is a better UX than using a dropdown for stack switching.

Implement the existing dashboard settings routes settings/ssh and settings/admin

refs #51

They look like this in dashboard now:

from #112

When diesel creates a new vhost it should also create a new operation of type 'provision' for that vhost.

• Apps
• Databases
• Log drains

The user model has password and email attrs and so ember data sends along these parameters to Auth via a PUT request. Auth expects PATCH requests with only the changing parameters, and in particular it doesn't like having password and email sent as parameters if they are not intended to be changed.

There's a pending PR in Auth that makes it accept PUT requests and tolerant of the inclusion of password and email parameters even if they are not changing.

After that PR is merged, auth should be able to accept a request like the one ember data sends, which looks like:

# PUT /users/:id
{
  name: 'new name',
  password: null,
  email: 'same-email-the-user-already-has'
}

When that is merged and #68 is merged, this issue will likely be fixed because #68 adds code that make the PUT request as described above.

The app activity and database activity pages should show operation createdAt dates as UTC timestamps in the format "monthName monthDay, fullYear HH:MMam/pm UTC":

from #51

• log drains index page
• log drains create page
• [ ] can delete log drain from index page (see #101)
• make styles match up
• DRY similarities in tests
• display log drain info in stack/-header.hbs (show first log drain's info)

Add a "logging" tab for a page that shows a list of logs, like so:

And a "new log" page that allows a user to create a new log drain, like so:

If you visit app#vhosts and the app currently has no vhosts, the route isn't fully loaded. This leaves other items in the nav with the ember-transitioning-out class. Ideally the route should fully resolve with a simple message like 'This app has no Domains.'

Handles should be limited to lowercase, alphanumerics, -, and _

Handles should match FORMAT = /\A[0-9a-z._-]{1,64}\z/

from #20

• User creation and initial session open in diesel
• Redirect after creation to /organizations/new in dashboard
• After email verification, user is redirected into account/stack FTUX at diesel

This will probably be addressed by work done to coalesce all stacks and organizations into a single dropdown selector.

Now that https://github.com/aptible/api.aptible.com/issues/149 has merged we should be able to app.get('vhosts') directly rather than retrieving them through the app's services as we do now.

from #51

• Don't block entire UX for unverified users. Provide glimpse of provisioned account and any "apps" they provisioned in set up flow.
• [ ] Create the apps/databases but do not provision. Upon verification of a user, provision any apps/dbs they have not provisioned. (already happens as of 2d1f2ae)
• verify that deploys check for a verified user.
  • Unverified users are prevented from creating operations in https://github.com/aptible/api.aptible.com/pull/168
• unverified users see a verify page (needs design for apps/dbs they have created)
• unverified users see a verify message with button to click to resend verification email