Hi, Yes, that is the advanced use case. The plan is to achieve this in steps i.e. having the editable property for selected users based on role. We thought of having everything as editable at the start since in UES the default case is to have a editable dashboard.
I think we can achieve this in steps. So, what we will be doing is 1. Identifying the items that need to be published - almost done 2. Publishing these to BAM in steps - e.g. All application creation related event data in the first milestone 3. Create the hive scripts and the converters for these 4. Create dashboards for all these items and leave as editable at the start. 6. Do the above for other events incrementally (in next milestones) and 5. Then introduce the type of users as you say with the ability to either change their dashboard or keep it static. e.g. We can allow users of roles such as CXO, admin user to change their dashboards when they need but also make sure that users of normal roles such as devs, QAs to have a fixed dashboard once created for an organisation. Once a dashboard is created and published into the store then it is accessible by all - so we might have to find a way to disallow this based on the role. The last step needs to be added to the milestone plan and redmine since I talked about those items with Nuwan after the mail was sent. Hope this clarifies the picture. Thank you, Shiro On Wed, Jul 17, 2013 at 5:20 PM, Samisa Abeysinghe <[email protected]> wrote: > Being able to create the dashboards the user want is the advanced use > case. > What about the simple use case of simple pre-defined dashboards? > > In others words, like in the case of UES, we should have various > "profiles" of users in here and cater for them all: > lame:average:advanced:geek > > > > On Wed, Jul 17, 2013 at 4:06 PM, Shiroshica Kulatilake <[email protected]>wrote: > >> Hi All, >> >> The following are architectural notes that were made after having quick >> chats with AmilaM and Nuwan regarding the dashboard effort for aPaaS. >> >> *1. Expectation of the aPaaS dashboards.* >> - A user of aPaaS should be able to create dashboards for various >> events that are created within aPaaS (i.e. within the application creation >> process as well as the runtimes). These dashboards should be context >> specific based on what the user wants to see. e.g CXO needs to see CXO >> level dashboard whereas a PM needs to see a different type of a dashboard. >> Once a user logs in to the dashboard creator (UES) gadgets can be >> selected and datasources which have been predefined can be linked to these. >> A dashboard can be created for a particular role type in a tenant - so if >> another user who has the same role logs in, then he/she would see the same >> dashboard. The driving force behind allowing the user to create dashboards >> themselves is to reduce changes that may sometimes be conflicting amongst >> separate clients. >> >> *2. BAM integration * >> - There will be a BAM server which will be shared across the AF setup >> plus the runtime environments. AF will publish event data into BAM through >> a BAMPublisher which is a osgi bundle which AF depends on. >> AF will simply send the data to the BAMPublisher and from thereon >> BAMPublisher will push that data into BAM. All data will be published into >> the super tenant's space. >> >> *3. UES integration* >> - In UES we will provide pre-created data sources that can be selected >> via a dropdown. These would be linked to the UES gadgets that can be >> selected. >> - Since UES follows the normal platform multi-tenancy in place, we will >> show dashboards based on a tenant and the role which that logged user >> belongs to. This way once a dashboard has been created for a particular >> role it will be shown to all users who have the same role. >> >> *4. Things that need to be finalized.* >> - We have not finalized on which UES to use still. (i.e. seperate UES on >> AF or the one with BAM) >> - We also need to talk with the BAM folks to get details as to when they >> will be integrating UES into BAM. >> - There is still a grey area on a user seeing a dashboard for a role and >> then being able to edit it thereby - right now it can be seen as a feature >> but we need to address this soon as to whether that should be allowed or >> not. (preferably via configuration) >> - We also need to incorporate the logs into the dashboard. >> >> The top level diagram is shown below. >> [image: Inline image 1] >> The tasks for the above have been created in the milestone >> plan<https://docs.google.com/a/wso2.com/spreadsheet/ccc?key=0Aq1ORUvnyMi6dGJNb0MtRlhBalJGTk9Ha2QzbWVnUUE#gid=5>and >> the redmine issues have been created beneath version 1.1.0 under the >> AppFactory >> project. <https://redmine.wso2.com/projects/wso2-app-factory/roadmap> >> >> >> Thoughts and suggestions are welcome. >> >> >> Thank you, >> Shiro >> >> -- >> Shiroshica Kulatilake >> >> Architect, >> WSO2, Inc. http://wso2.com/ >> Phone: +94 776523867 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Thanks, > Samisa... > > Samisa Abeysinghe > VP Engineering > WSO2 Inc. > http://wso2.com > http://wso2.org > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Shiroshica Kulatilake Architect, WSO2, Inc. http://wso2.com/ Phone: +94 776523867
<<aPaaSDashboard.jpg>>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
