stoney core: Requirements

Revision as of 15:17, 5 December 2013 by Michael (Talk | contribs)


  • Use the new REST API.
  • Use JavaScript framework for the web client.
  • Use HTML5 and not HTML 4.01, not transitional, not XHTML
  • Testing
    • Use Jasmine for JavaScript testing
    • Use SeleniumHQ or PhantomJS for automated testing
    • 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 (for example via a bookmark)
  • 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)
    • 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
  • 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
Last modified on 5 December 2013, at 15:17