Difference between revisions of "stoney core: Requirements"

Revision as of 15:11, 18 October 2013

• Use the new REST API.
• Use JavaScript framework for the web client.
  • Use one of the following MVC-Javascript-Framework: AngularJS (Google), Backbone.js (Twitter?) or Ember.JS (Apple). See comparison based on a simple webapp. All suggestions have corresponding Yii extensions.

• 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

• 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

• 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