Difference between revisions of "stoney core: Requirements"
From stoney cloud
(35 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | * Use the new REST API. | + | * Use the new [[Application_Programming_Interface_(API)#REST_API | REST API]]. |
* Use JavaScript framework for the web client. | * Use JavaScript framework for the web client. | ||
− | ** Use | + | ** Use [http://angularjs.org/ AngularJS] as base (perhaps starting with [https://github.com/angular/angular-seed Angular Seed]?) |
+ | *** Add [https://github.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 | * Views | ||
Line 8: | Line 45: | ||
** [[stoney core: Global Breadcrumb Entries (Reseller View) Version 0.4.0]] | ** [[stoney core: Global Breadcrumb Entries (Reseller View) Version 0.4.0]] | ||
** Shorten entries on lines, so they don't have any line breaks | ** Shorten entries on lines, so they don't have any line breaks | ||
+ | *** Possible via CSS? | ||
** Use space on page (content section) more efficiently | ** Use space on page (content section) more efficiently | ||
− | ** Make menu on the left hand side a bit narrower, so the content section has more space | + | ** 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) | ** 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) | * Billing (belongs to core and to the modules, here we have the basic functionality) | ||
Line 16: | Line 58: | ||
*** Provider price plans need to be able to be overridden by the resellers, so that they can have their own 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). | *** A Reseller should be able to set individual price plans per customer (not yet). | ||
− | |||
** Currency | ** Currency | ||
** VAT (differentiate between the Swiss and foreign billing addresses) | ** VAT (differentiate between the Swiss and foreign billing addresses) | ||
Line 28: | Line 69: | ||
*** As a formula | *** As a formula | ||
*** or as a table with the discount steps | *** or as a table with the discount steps | ||
+ | ** Whitelabel Billing | ||
+ | |||
* Billing (per Module) | * Billing (per Module) | ||
Line 39: | Line 82: | ||
* Cancellation of | * Cancellation of | ||
** Services | ** Services | ||
+ | ** Display running period | ||
+ | ** Display the earliest cancellation date | ||
+ | ** Allow on-line cancellation | ||
+ | ** Allow cancellation for earliest cancellation date | ||
+ | |||
+ | |||
* Deletions of | * Deletions of | ||
** Services | ** Services | ||
Line 44: | Line 93: | ||
** Customers | ** Customers | ||
** Resellers | ** Resellers | ||
+ | |||
+ | |||
* Service-Transfer | * Service-Transfer | ||
** From one person to another (in the same company). | ** 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, same reseller)? No yet. | ||
** From one person to another (another company, other reseller)? Not 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. | * 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 | * Password | ||
** Change password. | ** Change password. | ||
Line 71: | Line 169: | ||
** List | ** List | ||
* Modules | * Modules | ||
− | ** Load/Install new modules | + | ** The actual module installation happens via ebuild (deployment of the code) |
+ | ** Load/Install new modules (update the configuration file) | ||
** Configure Modules (configuration / defaults) | ** Configure Modules (configuration / defaults) | ||
** Release Module for single, multiple or all Resellers | ** Release Module for single, multiple or all Resellers |
Latest revision as of 14: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 AngularJS as base (perhaps starting with Angular Seed?)
- 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:
- 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
- Frisby, partially uses Jasmine and integrates via JUnit XML output with Jenkins
- 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
- Price Plans
- 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?
- Pricing
- 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