Difference between revisions of "stoney core: Requirements"

Latest revision as of 13:56, 16 April 2014

• Use the new REST API.
• Use JavaScript framework for the web client.
  • Use AngularJS as base (perhaps starting with Angular Seed?)
    • Add Restangular to make it even easier to connect to the REST-API, see also this answer on stackoverflow
    • From angular-ui use:
      • UI-Bootstrap to integrate with Bootstrap 3
      • UI-Utils as needed
      • UI-router as needed
      • UI-Alias as needed
    • Integrate RequireJS
    • See comparison based on a simple webapp. All suggestions have corresponding Yii extensions.
• Use HTML5 and not HTML 4.01, not transitional, not XHTML
  • Use bootstrap (version 3) resp. AngularUI-Bootstrap to get a working pre-defined environment including compat-shims for IE, etc.
• Translation:
  • http://pascalprecht.github.io/angular-translate/
• Testing
  • Use Jasmine for JavaScript testing
  • Use SeleniumHQ or PhantomJS for automated testing
  • Possibly use GruntJS for an automated workflow
  • Use one of the following options for the REST API Testing (& documentation):
    • Frisby, partially uses Jasmine and integrates via JUnit XML output with Jenkins
      • Has integrated JSON Schema Testing!
    • Dredd+apiblueprint (perhaps directly via the webservice at http://apiary.io/) which makes it possible to keep specification, documentation and example in one place and test the REST API against the specification and use the examples as test cases.
    • Swagger
    • JSON Schema
  • Use static mock json objects under different URLs to provide mock server-side data for testing the webfrontend

• Clean URLs
  • URLs are specified by stepping stone GmbH
  • URLs have to be bookmarkable
  • When using a MVC-Javascript-Framework, the URL will partially be managed by javascript and not directly reach the server, therefore either Yii or the webserver must be able to handle such URLs when a user directly accesses such a page ("deep linking", for example via a bookmark). In AngularJS this is supposed to be done by serving the same page as for a an URL higher in the hierarchy and the JavaScript Framework will then do the right thing.

• Interaction design
  • When directly accessing a URL and the session is invalid, the user must be forwarded to the requested page after successful authentication (clean referrer handling)
  • Back-Button must be working properly, even when using a single-page design (see above), ensured by using a proper JavaScript framework.
  • Make sure that filters, current page, etc. are preserved when going into detail view of an item and back again

• Entry in the directory for the core module (selfcare)
  • Version
  • Maintenance

• Views
  • stoney core: Global Breadcrumb Entries (Provider View)
  • stoney core: Global Breadcrumb Entries (Reseller View) Version 0.4.0
  • Shorten entries on lines, so they don't have any line breaks
    • Possible via CSS?
  • Use space on page (content section) more efficiently
  • Make menu on the left hand side a bit narrower (but with a fixed value), so the content section has more space
  • Optimize the screen for minimum notebook screens (1366x768) (instead of the current 1200)
    • New minimum of 1300. The content part is allowed to grow.
    • Left orientated
    • Still keep a minimum white space on left and right borders
• Create a fluid layout, for example using bootstrap

• Billing (belongs to core and to the modules, here we have the basic functionality)
  • Price Plans
    • Provider price plans need to be able to be overridden by the resellers, so that they can have their own price plans
    • A Reseller should be able to set individual price plans per customer (not yet).
  • Currency
  • VAT (differentiate between the Swiss and foreign billing addresses)
  • Billing per Reseller or per Customer
  • Invoice
    • Classic paper invoice
    • PDF invoice
    • E-bill (for Swiss Customers)
    • Card payments (Postcard, Creditcard, ... wiht the corresponding gateway information)
  • Reseller discount
    • As a formula
    • or as a table with the discount steps
  • Whitelabel Billing

• Billing (per Module)
  • Pricing
    • Base Fee for the service
    • Possible free items (for example
    • Formula (Quantity x price per item, 3 Gigabyte x 4.00 CHF/Gigabyte)
    • Free test period?

• Cancellation of
  • Services
  • Display running period
  • Display the earliest cancellation date
  • Allow on-line cancellation
  • Allow cancellation for earliest cancellation date

• Deletions of
  • Services
  • People
  • Customers
  • Resellers

• Service-Transfer
  • From one person to another (in the same company).
  • From one person to another (another company, same reseller)? No yet.
  • From one person to another (another company, other reseller)? Not yet.
  • Keep Data? Default is FALSE (what this means is probably different per service)
  • Provisioning mode could be: transfer or transferwithdata, ...

• Roles and rights.
  • Notes from the 20th of December 2012
  • sstMethod would probably be more like the API-Call in the form of a URI.
  • We need to define default Roles
    • Service Administrator -> Needs to be chosen
    • Service User -> Default Role
  • Shall we have the possibility to collect roles together in the form of groups
  • Forms
    • Either Different forms for the different functionality
    • Or define, which fields are read write, read only are not to displayed

The following LDIF is just a collection of ideas and needs to be simplified to reduce the hierarchy:

# Default Roller "VM Backup"
ou=roles,dc=foo-cloud,dc=org
uid=1234567,ou=roles,dc=foo-cloud,dc=org
sstRoleName: VM Backup
sstIsActive: TRUE
ou=api calls,uid=1234567,ou=roles,dc=foo-cloud,dc=org

ou=create,ou=account,ou=backup,ou=api calls,uid=1234567,ou=roles,dc=foo-cloud,dc=org

sstMethod: ou=create,ou=backup,ou=sections,ou=virtualization,ou=services,dc=foo-cloud,dc=org
sstReadWrite: quota
sstReadWrite: userPassword
ou=delete,ou=api calls,uid=1234567,ou=roles,dc=foo-cloud,dc=org
sstReadOnly: givenName
sstReadOnly: surname

sstMandatory?

sstMethod: ou=delete,ou=backup,ou=sections,ou=virtualization,ou=services,dc=foo-cloud,dc=org

• How and where do we store the possible api-calls and the corresponding fields in the directory for the core and service?
• How do want to display and/or list the roles without overwhelming the users?
• Different default roles for different person types (reseller, customer, provider)
• Service restriction is possible per user in his roles?

• Support Switch-User (with Switch Back)
  • Hierarchical Switches are not supported, meaning: if you want to change into the role of a second user, you need to leave (switch back) the role of the first user.
  • Where shall we display this information?
  • Shall we add new editing functionalities by the people listing at the end of the table lines? A pop menu (a bit like in Alfresco).
  • Would be valid for all other screens as well.

• Password
  • Change password.
  • Forgot password (the owner of the mail account is guide to the password retrieval process).
  • Reset password (and send newly created credentials to either person logged in oder to the owner of the mail account).

Provider View

• Reseller
  • Add
  • Modify
  • Delete
  • List
• People of Reseller
  • Add
  • Modify
  • Delete
  • List
• Employees
  • Add
  • Modify
  • Delete
  • List
• Modules
  • The actual module installation happens via ebuild (deployment of the code)
  • Load/Install new modules (update the configuration file)
  • Configure Modules (configuration / defaults)
  • Release Module for single, multiple or all Resellers

Reseller View

• Modules
  • Configure Modules (configuration / defaults)
  • Release Module for single, multiple or all Customers