* Use the new [[Application_Programming_Interface_(API)#REST_API | REST API]].
* Use JavaScript framework for the web client.
** Use one of the following MVC-Javascript-Framework[http: //angularjs.org/ AngularJS ] as base (Google), Backboneperhaps starting with [https://github.js (Twittercom/angular/angular-seed Angular Seed]?) or Ember*** Add [https://github.JS (Apple)com/mgonto/restangular Restangular] to make it even easier to connect to the REST-API, see also this [http://stackoverflow. com/questions/16394089/how-to-access-the-services-from-restful-api-in-my-angularjs-page answer on stackoverflow]*** From [http://angular-ui.github.io/bootstrap/ angular-ui] use:**** [http://angular-ui.github.io/bootstrap/ UI-Bootstrap] to integrate with Bootstrap 3**** [http://angular-ui.github.io/ui-utils/ UI-Utils] as needed**** [https://github.com/angular-ui/ui-router UI-router] as needed**** [https://github.com/angular-ui/alias UI-Alias] as needed*** Integrate [http://requirejs.org/ RequireJS]*** See [http://todomvc.com/ comparison based on a simple webapp]. All suggestions have corresponding Yii extensions.* Use HTML5 and not HTML 4.01, not transitional, not XHTML** Use [http://getbootstrap.com/ bootstrap] (version 3) resp. [http://angular-ui.github.io/bootstrap/ AngularUI-Bootstrap] to get a working pre-defined environment including compat-shims for IE, etc.* Translation:** http://pascalprecht.github.io/angular-translate/* Testing** Use [http://pivotal.github.io/jasmine/ Jasmine] for JavaScript testing** Use SeleniumHQ or [http://phantomjs.org/ PhantomJS] for automated testing** Possibly use [http://gruntjs.com/ GruntJS] for an automated workflow** Use one of the following options for the REST API Testing (& documentation):*** [http://frisbyjs.com/ Frisby], partially uses Jasmine and integrates via JUnit XML output with Jenkins**** Has integrated JSON Schema Testing!*** [https://github.com/apiaryio/dredd Dredd]+[http://apiblueprint.org/ 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.*** [http://developers.helloreverb.com/swagger/ Swagger]*** [http://json-schema.org/ 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 (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 [http://getbootstrap.com/ bootstrap]
* Billing (belongs to core and to the modules, here we have the basic functionality)
*** 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)
*** As a formula
*** or as a table with the discount steps
** Whitelabel Billing
* Billing (per Module)
* Cancellation of
** Services
** Display running period
** Display the earliest cancellation date
** Allow on-line cancellation
** Allow cancellation for earliest cancellation date
* Deletions of
** Services
** 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:
<pre>
# 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
</pre>
* 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.
** 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