• Christian Wittkowski <christian.wittkowski@devroom.de>: CWI
• Tatiana Durisova Eichenberger <tatiana.durisova@stepping-stone.ch>: TEI
• Michael Eichenberger <michael.eichenberger@stepping-stone.ch>: MEI (Transcript)

• Christian Affolter <christian.affolter@stepping-stone.ch>: CAF
• Pat Kläy <pat.klaey@stepping-stone.ch>: PKL
• Tiziano Müller <tiziano.mueller@stepping-stone.ch>: TMU

• Release Management:
  • We need to define the versioning.
  • URL in web browser (for the web client) will be defined through stepping stone GmbH, Feedback through CWI, what is easily implemented.
• Architecture
  • Modularisation: How do we want to modularise?
  • Application Programming Interface (API): Review through stepping stone GmbH
  • Testing: What and how?
  • Documentation: What and how?
• Roadmap in general
• Next steps:
  • stoney core: Requirements (self-care) with provider enhancement
  • stoney backup: Requirements (on-line backup) module with customer enhancement
  • New stoney mail: Requirements (mail with or without group-ware) module
• Possible future roadmap
  • New stoney vm: Requirements (subset of stoney conductor) module?
• Surrogate?

• Source-Code has patches. These are then needed, when we also change object classes, update or modify data.
• Check the optimal solution to roll out these patches between CWI and TMU
• Question: How shall we handle necessary roll-backs (for example if data modifications went wrong).

• Separate Modules into Web and Service

• Is ok, but the difference between stable and unstable must be explained better (Major can be unstable too? No).

• Requires more information about the minimum amount of need calls and what is expected.
• First step is the API for stoney core
• Second step is the API for stoney backup (on-line backup)
• Third step ist the API for stoney mail
• RestfullYii or on GitHub: RestfullYii makes a good impression on CWI.
• Communication between JavaScript (Client) and Yii-Framework (Server) need some thoughts from CWI.

• Will be done as described under Testing.

• sstBelongsToUID: 1

Reseller Person (can only belong to one reseller, but to multiple customers and can be employee of the reseller and the customers)

• sstBelongsToResellerUID: 1234567

Customer Person (can only belong to one reseller but to multiple customers and can be employee of these customers)

• sstBelongsToCustomerUID: 1234567

• Three separate forms
  • Super User (can add new Resellers, Modules, make People to Reseller People)
  • Reseller (

• The results need more information, depending on the level you have logged in. For example
  • Provider: Needs the information to which reseller and which customer the person belongs to.
  • Reseller: Needs the information to which reseller customer the person belongs to.
  • Customer: Knows, the person belongs to the customer.

• Provider Person: Product overview page of the provider, where they can also change the settings and defaults of a service/product (global activate/deactivate modules).
• Reseller Person: Product overview page of the reseller, where they can also change the settings and defaults of a service/product (activate/deactivate modules for themselves and therefore for their customers).
• Customer Person: Product overview page of their own services/products.

These views need to be defined.

• Will ODT work with current offer?
• A possibility would be to exchange PDF creation with the screen redesign.

• See stoney core: Requirements brainstorming.

• Prioritise the next functionality
• Create Mockups and documentation, including LDIFs
• Create Enhancements in the issue tracker and add to desired version
• Ask for quotation
  • Clarify any questions and update Enhancements/Documentation

• core
• services

• Change Reseller and Customer by adding Person

• Core
  • Provider View
  • API
  • Roles?
• VM
• Mail
• Backup Customer View