[Architecture] Dashboard Component Permission Model

[Tanya Madurapperuma]

Hi IS Team and all,

Purpose of this mail is to discuss about $ Subject.

There are two main artifact types associated with the dashboard component;
Dashboards and Widgets.

*Widgets*
According to the current implementation a widget can be an UUF fragment or
an UUF component.
So the plan is to have permission info for each widget in a config
yaml/json file which will be stored in the file system.

*Dashboards*
With the previous versions of Dashboard Server we used the role based model
instead of permission model due to limitations in creating permissions
dynamically in C4.
Since this limitation is not there in C5 (@ IS team : please correct me if
I am wrong), for dashboards also we will go with the permission model.
Dashboard permission will be stored in the dashboard json file in the file
system for predefined dashboards. If there is any change in the dashboard
json file, it will be stored in the database.

So from the dashboard components POV, we will consider that dashboard
components knows the principle.
And there will be an isAuthorized method provided from identity end where
we can pass the resource and action to validate whether the logged in user
is authorized for that particular action.

Based on the above model we have following questions.
1. How can we call the isAuthorized method from dashboard component ?
2. Is there any standard / approval process for permission strings ?
3. How should we register the permissions dynamically at the time of
creating a dashboard?

Appreciate your insight.

Thanks,
Tanya

-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Dashboard Component Permission Model

[Tanya Madurapperuma]

Hi Sinthuja,

This was discussed in a previous thread (Subject : [Dashboards] Where to
store the dashboard.json?) quoting the conclusion below.

- default dashboard definitions are in the product pack somewhere in the
file system
- for server level changes, they can copy that file to wherever, edit it
(textually or using dashboard editor) and then register it using
deployment.properties by setting a property like wso2.dashboards.<
DashboardName>.config=path-to-file
- any per user changes are stored in a db by the component's back end
service

Thanks,
Tanya


On Wed, Jan 4, 2017 at 10:51 AM, Sinthuja Ragendran 
wrote:

> Hi Tanya,
>
> Small question.
>
> On Wed, Jan 4, 2017 at 10:43 AM, Tanya Madurapperuma 
> wrote:
>
>> Hi IS Team and all,
>>
>> Purpose of this mail is to discuss about $ Subject.
>>
>> There are two main artifact types associated with the dashboard
>> component; Dashboards and Widgets.
>>
>> *Widgets*
>> According to the current implementation a widget can be an UUF fragment
>> or an UUF component.
>> So the plan is to have permission info for each widget in a config
>> yaml/json file which will be stored in the file system.
>>
>> *Dashboards*
>> With the previous versions of Dashboard Server we used the role based
>> model instead of permission model due to limitations in creating
>> permissions dynamically in C4.
>> Since this limitation is not there in C5 (@ IS team : please correct me
>> if I am wrong), for dashboards also we will go with the permission model.
>> Dashboard permission will be stored in the dashboard json file in the
>> file system for predefined dashboards. If there is any change in the
>> dashboard json file, it will be stored in the database.
>>
>
> In that case also can't we update the dashboard.json in the file system
> directly? IMHO having the same artefact both in file system, and database
> will bring problems of syncing, and I think it's better to have one config
> storage.
>
>>
>> So from the dashboard components POV, we will consider that dashboard
>> components knows the principle.
>> And there will be an isAuthorized method provided from identity end where
>> we can pass the resource and action to validate whether the logged in user
>> is authorized for that particular action.
>>
>> Based on the above model we have following questions.
>> 1. How can we call the isAuthorized method from dashboard component ?
>> 2. Is there any standard / approval process for permission strings ?
>> 3. How should we register the permissions dynamically at the time of
>> creating a dashboard?
>>
>> Appreciate your insight.
>>
>> Thanks,
>> Tanya
>>
>> --
>> Tanya Madurapperuma
>>
>> Senior Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439 <071%20818%204439>
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>
>
>
> --
> *Sinthuja Rajendran*
> Technical Lead
> WSO2, Inc.:http://wso2.com
>
> Blog: http://sinthu-rajan.blogspot.com/
> Mobile: +94774273955 <077%20427%203955>
>
>
>


-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Dashboard Component Permission Model

[Tanya Madurapperuma]

Hi Dilan,

On Wed, Jan 4, 2017 at 2:48 PM, Dilan Udara Ariyaratne 
wrote:

> Hi Tania,
>
> Are we going to keep one dashboard permission or multiple ? The reason
> that I am asking this is if we can allow multiple, we can
> separate out access for critical functions like dashboard view, edit and
> manage via those permissions.
>
As explained offline each dashboard will have its own permission for view ,
edit/ update, delete. The only difference in this with the previous
versions is that instead of the role we will use permissions.

>
> Also, have you looked into the scenario of restricting access of
> dashboards for different users ?
>
A permission is resource + action. So we can restrict access with the
permission.

> AFAIU, it's only by having multiple permissions, we can do this.
>

Thanks,
Tanya

>
> Cheers,
> Dilan.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. <http://wso2.com/>
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Wed, Jan 4, 2017 at 1:56 PM, Johann Nallathamby 
> wrote:
>
>>
>>
>> On Wed, Jan 4, 2017 at 1:04 PM, Nipuna Chandradasa 
>> wrote:
>>
>>> [+adding Sajith]
>>> Please find the my questions and suggestions in line
>>>
>>>>
>>>>>> Based on the above model we have following questions.
>>>>>> 1. How can we call the isAuthorized method from dashboard component ?
>>>>>>
>>>>>
>>> Isn't this isAuthorized method should be exposed through UUF as
>>> dashboard component is basically a UUF component? It might not be good to
>>> expose a such a functionality through a UI framework but it'll be lot
>>> cleaner than invoking a OSGI service inside our component.
>>>
>>
>> Once you login using CAAS (carbon authentication and authorization
>> service) components you will get a CAAS User object [1]. This User object
>> is a proxy object which can be used to call all the underlying identity
>> store and authorization store methods. Ideally you will store this User
>> object in the user's logged in session and perform those operations when
>> necessary.
>>
>> [1] https://github.com/wso2/carbon-security/blob/release-1.
>> 0.0-m2/components/org.wso2.carbon.security.caas/src/main/jav
>> a/org/wso2/carbon/security/caas/user/core/bean/User.java
>>
>> Regards,
>> Johann.
>>
>>
>>
>>>
>>>
>>>> 2. Is there any standard / approval process for permission strings ?
>>>>>>
>>>>> 3. How should we register the permissions dynamically at the time of
>>>>>> creating a dashboard?
>>>>>>
>>>>>> Appreciate your insight.
>>>>>>
>>>>>
>>>>>
>>> Thank you,
>>>
>>> --
>>> Nipuna Marcus
>>> *Software Engineer*
>>> WSO2 Inc.
>>> http://wso2.com/ - "lean . enterprise . middleware"
>>> Mobile : +94 (0) 713 667906 <+94%2071%20366%207906>
>>> nipu...@wso2.com
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Technical Lead & Product Lead of WSO2 Identity Server
>> Governance Technologies Team
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] wso2is-analytics 5.3.0 how store:// resolved to url ?

[Tanya Madurapperuma]

Hi Dmitry,

WSO2IS-Analytics 5.30 version is using carbon dashboards 2.0.3 version.
[1]. This particular version of carbon dashboards has pluggable store
support where you can plug any desired third party gadget store. The
default store is fs (file system).
So even though you specified the gadget url or thumbnail url prefixing with
a store:// this version of carbon dashboards doesn't require that.

"data": {
"url": "gadget/generic-gadget/index.xml"
},

instead of

"data": {
"url": "store://gadget/generic-gadget/index.xml"
},

But even if you used store:// , it also should work since this feature is
written in a backward compatible way. [2]

URL resolving logic for the default store fs can be found at  [3] which
uses relativePrefix function at [4]

AFAIR if you have a different host other than localhost, you need to define
your hostname at [5] in designer.json file. @ NipunaC : Please correct me
if I am wrong.


[1] https://github.com/wso2/analytics-is/blob/v5.3.0/pom.xml#L523
[2]
https://github.com/wso2/carbon-dashboards/commit/10f9934e4a58867115359b3150ef6f06128f6fc7
[3]
https://github.com/wso2/carbon-dashboards/blob/v2.0.3/apps/portal/extensions/uris/fs/index.js
[4]
https://github.com/wso2/carbon-dashboards/blob/v2.0.3/apps/portal/js/ues.js#L7
[5]
https://github.com/wso2/carbon-dashboards/blob/v2.0.3/apps/portal/configs/designer.json#L76

Thanks,
Tanya

On Sat, Jul 1, 2017 at 3:04 AM, Gimantha Bandara  wrote:

>
> On Sat, Jul 1, 2017 at 2:04 AM Dmitry Lukyanov  wrote:
>
>> Hello all,
>>
>> Please help me to understand how "store://" resolved to real url.
>> wso2 analytics connects to itself by localhost for urls defined as
>> store://... and I need to change this for docker.
>>
>> Sample gadget.json file:
>> https://docs.wso2.com/display/DS200/Creating+a+Gadget#
>> CreatingaGadget-Step3-Definethegadget.jsonfile
>>
>> Thanks,
>>  Dmitry
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
> --
> Gimantha Bandara
> Software Engineer
> WSO2. Inc : http://wso2.com
> Mobile : +94714961919 <071%20496%201919>
>



-- 
Tanya Madurapperuma

Associate Technical Lead,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Securing Product Apis and Product artifacts

[Tanya Madurapperuma]

Hi all,

We (Prabath, NuwanD, Suho, few IS team members, few analytics team members)
had an offline discussion regarding $ Subject.

*Problem*
With the new rewrite of C5 based products, we have moved from SOAP based
backend product APIs to  REST APIs. And there needs to be a mechanism to
secure these product APIs. It can be either OAuth tokens based approach or
basic auth.

But the products like Analytics do not have in built OAuth support for
token generation, validation  etc to achieve the above requirement.

Also there needs to be an approach to secure product level artifacts such
as Dashboards, widgets etc as well.

Regardless of the securing mechanism that we use, product users should be
able to try out and evaluate the default distribution of the product
without much effort of setting up an external IDP.

*Suggested solution*
We will be implementing a custom IDP that has OAuth capabilities (password
grant type) and required SCIM api implementations (Initially from Analytics
dashboard pov we will need SCIM api for getting role list of users).
And this custom IDP will be shipped with the product.


​


*Securing Product APIs*
Product APIs can be secured either with OAuth or basic auth interceptors
based on the request header.

We will have to maintain a scope to role mapping list in the product side
and using a scope registration service we can register those at the custom
IDP as same as APIM C5 doing.

*Securing Product Artifacts*
Artifacts such as dashboards, widgets are secured using a role based
approach. Each product will maintain its own list of resources (artifacts)
and respective roles in a database. This database will be updated upon a
new resource addition, modification etc.

*Securing Product UI elements*
User facing application of the product will require to hide/show certain UI
elements based on the logged in user. This also we can achieve using the
scopes that we use to secure the product apis and roles that we use to
secure product artifacts. Scopes and roles will be stored in the browser.

For example, if we want to show/hide "create dashboard" button depending on
the logged in user, we can show/hide, if the logged in user has the
create_dashboard scope which is required to call the product api for
creating a dashboard.

For the product artifacts, say to decide on showing Foo Dashboard's edit
button, we can use roles for that resources.


Thanks,
Tanya

-- 
Tanya Madurapperuma

Associate Technical Lead,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dashboard] Introducing a base widget component

[Tanya Madurapperuma]

x. 2) CSS isolation
>>>
>>> For CSS isolation we can isolate the widget content using React shadow
>>> DOM. For that we can introduce a new method called renderWidget() in the
>>> widget base class and all the widgets can define the renderWidget() instead
>>> of the React's render() method. Within the render() method of the widget
>>> class we can invoke the renderWidget() method and wrap the resultant
>>> content using React shadow DOM. High level implementation of those
>>> components will be as follows.
>>>
>>> *Widget base component:*
>>>
>>> class Widget extends React.Component {
>>> /* ... */
>>> render() {
>>> return (
>>> 
>>> renderWidget()
>>> 
>>>     );
>>> }
>>> /* ... */
>>> }
>>>
>>>
>>> *Widget component:*
>>>
>>> class MyWidget extends Widget {
>>> /* ... */
>>> renderWidget() {
>>> return ;
>>> }
>>> /* ... */
>>> }
>>>
>>>
>>> Any feedback on this?
>>>
>>> Regards,
>>>
>>> *Lasantha Samarakoon* | Software Engineer
>>> WSO2, Inc.
>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>> <https://maps.google.com/?q=20,+Palm+Grove,+Colombo+03,+Sri+Lanka&entry=gmail&source=g>
>>> Mobile: +94 (71) 214 1576 <+94%2071%20214%201576>
>>> Email:  lasant...@wso2.com
>>> Web:www.wso2.com
>>>
>>> lean . enterprise . middleware
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>


-- 
Tanya Madurapperuma

Associate Technical Lead,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Option for the customer to change the app context path in React based web apps

[Tanya Madurapperuma]

As a temporary solution we have retrieved app context by manipulating
window.location which is not the correct approach as it might break if
there is no context. (ex: if url is abc.com instead of abc.com/appContext )

+1 for the suggested approach as we can use the defined contextPath
variable  in routing as well [1]

[1]
https://github.com/wso2/carbon-dashboards/blob/master/components/dashboards-web-component/src/App.jsx

Thanks,
Tanya

On Thu, Oct 12, 2017 at 10:34 PM, SajithAR Ariyarathna 
wrote:

> Hi All,
>
> *What is app context path?*
>
> In http://localhost:8080/store/apis/1234 URL, the app context path is
> /store. Customer might want to deploy the Store app in /my-store context
> path (in that case the URL will be http://localhost:8080/my-
> store/apis/1234).
>
>
> Currently in React based web apps, the app context path is hard-coded in
> the index.html file (see [1], [2]). This makes harder to change the app
> context path for a deployment. One approach that has been suggested to
> avoid hard-cording the app context path in the index.html is to use
> relative URLs for stylesheets and scripts. However the browser resolves
> these relative URLs into absolute URLs by prepending the current page
> URL. Therefore we cannot use relative URLs for stylesheets and scripts.
>
> e.g./>  If the current page is http://localhost:8080/store/ then the absolute
> URL will be  http://localhost:8080/store/public/themes/default/
> css/styles.css. If the current page is http://localhost:8080/
> store/apis/12345 then the absolute URL will be http://localhost:8080/
> store/apis/12345/public/themes/default/css/styles.css which is incorrect.
>
>
> In order to resolve this, we need to generate proper URLs (with the
> context path). However its difficult to find and fix relative URLs inside
> the index.html. (Carbon UI Server has to parse the index.html file, then
> find necessary tags like ,  and prepend the app context
> path to their relative URLs and generate the final HTML. This process is
> cumbersome & will affect negatively on performance.) We can have a template
> file instead of a HTML file. Handlebars is a good candidate for this task
> as we have much experience with Handlebars template in web apps. So if we
> choose Handlebars then index.html will be index.hbs. e.g.
>
> <htmL>
> <head>
> ...
> <link rel="stylesheet" 
> href="{{contextPath}}/public/themes/default/css/styles.css"/>
> </head>
> <body>
> ...
> </body>
> </htmL>
>
> This approach opens-up other useful features. For example, if someone
> needs the app context path in the client-side JS, they can send it as a
> variable to the client-side. e.g.
>
> <head>
> ...
> <script>
> var contextPath = *{{contextPath}}*;
> 
> 
>
>
> *Configuring app context path*
>
> Since app context path is decided for a deployment, deployment.yaml is
> the ideal place to define it.
>
> wso2.ui-server:
>   contextPaths:
> # : 
> "store": "/store"
>
> Here app name is the name of the directory where web app resides. If
> context path is not defined in the deployment.yaml then the default
> context path will be / (e.g. /store).
>
>
> [1] https://github.com/wso2/carbon-apimgt/blob/
> 530351f5a48243bbc7cf082e5e5c88e83de9e385/features/apimgt/
> org.wso2.carbon.apimgt.store.feature/src/main/resources/
> store/public/index.html#L29
> [2] https://github.com/this/carbon-dashboards/blob/
> 8f63194abdd52c1f9060c7da5a44c33686d40fab/features/org.wso2.
> carbon.dashboards.portal.feature/src/main/resources/
> portal/pages/index.html#L11
>
> WDYT?
> Thanks
>
> --
> Sajith Janaprasad Ariyarathna
> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
> <https://wso2.com/signature>
>



-- 
Tanya Madurapperuma

Associate Technical Lead,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Analytics] Introducing a common permission model.

[Tanya Madurapperuma]

Hi Lasantha,

Where do we maintain the resource to permission mapping? Is it at the
common component level or each app has to maintain its own mapping?

Thanks,
Tanya

On Wed, Oct 18, 2017 at 1:34 PM, Lasantha Samarakoon 
wrote:

> Hi all,
>
> In the new React based dashboard component we need to implement a
> permission model based on user roles to limit access to dashboard
> resources. Since this can be a common requirement among all the React based
> apps in under Analytics we thought of introducing a common component to
> serve the purpose. Therefore we are thinking of add this component into
> carbon-analytics repository.
>
> Implementation:
>
> As we discussed internally this component will expose an OSGi service
> which provides all the necessary APIs. This includes the following.
>
>- CRUD operations on permissions (i.e. add/edit/delete/get/list
>permissions)
>- Grant and revoke permissions from particular roles.
>
> In order to persist permissions following database will be implemented.
>
> *PERMISSIONS*
>
> ID INT AUTO_INCREMENT PRIMARY KEY
> APP_NAME VARCHAR(3) NOT NULL
> PERMISSION_STRING VARCHAR(50) NOT NULL
>
>
>
> *ROLE_PERMISSIONS*
>
> ID INT AUTO_INCREMENT PRIMARY KEY
> PERMISSION_ID INT NOT NULL
> ROLE_NAME VARCHAR(100) NOT NULL
>
>
> Since we are not maintaining the roles withing this database schema we
> suppose to retrieve them via the SCIM API.
>
> Appreciate your feedback.
>
>
> Regards,
>
> *Lasantha Samarakoon* | Software Engineer
> WSO2, Inc.
> #20, Palm Grove, Colombo 03, Sri Lanka
> <https://maps.google.com/?q=20,+Palm+Grove,+Colombo+03,+Sri+Lanka&entry=gmail&source=g>
> Mobile: +94 (71) 214 1576 <071%20214%201576>
> Email:  lasant...@wso2.com
> Web:www.wso2.com
>
> lean . enterprise . middleware
>



-- 
Tanya Madurapperuma

Associate Technical Lead,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Analytics] Introducing a common permission model.

[Tanya Madurapperuma]

On Wed, Oct 18, 2017 at 2:20 PM, Lasantha Samarakoon 
wrote:

> ​Where do we maintain the resource to permission mapping? Is it at the
> common component level or each app has to maintain its own mapping?
>
> Resource to permission mapping needs to be maintained at each app level.
> Common component doesn't need to know about the resources but only roles
> and permissions. At the app level we can implement a hasPermission() method
> which check whether any of the roles of the current user has respective
> permission.​
>
IMO we should bring that also to the common component. If not every app
developer will have to have their own hasPermission method.
Instead of that i think it would be better if we can provide a common api
for adding resource permission mapping and a common api to check
hasPermission. WDYT?

Thanks,
Tanya

>
> *Lasantha Samarakoon* | Software Engineer
> WSO2, Inc.
> #20, Palm Grove, Colombo 03, Sri Lanka
> <https://maps.google.com/?q=20,+Palm+Grove,+Colombo+03,+Sri+Lanka&entry=gmail&source=g>
> Mobile: +94 (71) 214 1576 <071%20214%201576>
> Email:  lasant...@wso2.com
> Web:www.wso2.com
>
> lean . enterprise . middleware
>
> On Wed, Oct 18, 2017 at 2:04 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi Lasantha,
>>
>> Where do we maintain the resource to permission mapping? Is it at the
>> common component level or each app has to maintain its own mapping?
>>
>> Thanks,
>> Tanya
>>
>> On Wed, Oct 18, 2017 at 1:34 PM, Lasantha Samarakoon 
>> wrote:
>>
>>> Hi all,
>>>
>>> In the new React based dashboard component we need to implement a
>>> permission model based on user roles to limit access to dashboard
>>> resources. Since this can be a common requirement among all the React based
>>> apps in under Analytics we thought of introducing a common component to
>>> serve the purpose. Therefore we are thinking of add this component into
>>> carbon-analytics repository.
>>>
>>> Implementation:
>>>
>>> As we discussed internally this component will expose an OSGi service
>>> which provides all the necessary APIs. This includes the following.
>>>
>>>- CRUD operations on permissions (i.e. add/edit/delete/get/list
>>>permissions)
>>>- Grant and revoke permissions from particular roles.
>>>
>>> In order to persist permissions following database will be implemented.
>>>
>>> *PERMISSIONS*
>>>
>>> ID INT AUTO_INCREMENT PRIMARY KEY
>>> APP_NAME VARCHAR(3) NOT NULL
>>> PERMISSION_STRING VARCHAR(50) NOT NULL
>>>
>>>
>>>
>>> *ROLE_PERMISSIONS*
>>>
>>> ID INT AUTO_INCREMENT PRIMARY KEY
>>> PERMISSION_ID INT NOT NULL
>>> ROLE_NAME VARCHAR(100) NOT NULL
>>>
>>>
>>> Since we are not maintaining the roles withing this database schema we
>>> suppose to retrieve them via the SCIM API.
>>>
>>> Appreciate your feedback.
>>>
>>>
>>> Regards,
>>>
>>> *Lasantha Samarakoon* | Software Engineer
>>> WSO2, Inc.
>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>> <https://maps.google.com/?q=20,+Palm+Grove,+Colombo+03,+Sri+Lanka&entry=gmail&source=g>
>>> Mobile: +94 (71) 214 1576 <071%20214%201576>
>>> Email:  lasant...@wso2.com
>>> Web:www.wso2.com
>>>
>>> lean . enterprise . middleware
>>>
>>
>>
>>
>> --
>> Tanya Madurapperuma
>>
>> Associate Technical Lead,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439 <+94%2071%20818%204439>
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>
>


-- 
Tanya Madurapperuma

Associate Technical Lead,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dashboard] Message queuing mechanism to prevent losing messages in PubSub

[Tanya Madurapperuma]

+1 for the implementation.
One main advantage with the above approach is publisher and subscriber
widget authors don't need to worry about the load order as it is entirely
handled by the parent widget component. They just have to write their
publishing and subscribing logic thinking that subscriber widget will be
always loaded before the publisher widget.

Thanks,
Tanya

On Mon, Nov 27, 2017 at 12:34 AM, Nisala Nanayakkara 
wrote:

> Hi All,
>
> Purpose of this mail is to discuss the solution regarding the 'Message
> queuing mechanism to prevent losing messages in PubSub"*. *Please find
> the below information in order to get more context regarding the $subject
> *.*
>
> *Problem & C4 solution*
>
> Let's consider a situation where there is a dashboard with publisher and
> subscriber widgets. If the publisher widget is rendered before the
> subscriber widget, the subscriber widget may miss the initial messages that
> are published by the publisher. As a real-world example, we can consider a
> scenario where date picker widget publishes initial date range and the
> other widgets should be rendered according to that published date range. If
> the date picker widget is rendered before the other widgets, these widgets
> will not able to get the published date-range. In C4, we have implemented a
> feature to control the load order of the widgets. So that we can control
> the load order of widgets and resolve the above-mentioned problem.
>
> *Proposed Solution*
>
> In C5 dashboard component implementation, we have used Golden Layout to
> handle the layouting and rendering of the dashboards. Please refer the mail
> thread[1] for more information. Because of this reason, we do not have the
> control over the widget load order in dashboards. So we have come up with
> the following solution in order to resolve this issue.
>
>- Publisher widgets publish messages using its parent(base) widget.
>Please refer mail thread[2] for more information about parent widget
>component.
>- If the dashboard is not initialized, messages will be queued at the
>widget level and start listening to dashboard initialized event. Once the
>dashboard is initialized, queued messages will be sent to the respective
>channel. So that the subscriber widgets can get the published messages
>without any issue.
>
> The above implementation will be available with the stream processor beta
> version. If you have any concerns or issues. Please feel free to ask.
>
> [1] - Mail Subject - [Meeting Notes] Discussion on way forward with
> Dashboards @ Wed Jun 14, 2017 10am - 11am (IST) (WSO2 Platform Team Group)
>
> [2] - Mail Subject - [Dashboard] Introducing a base widget component
> Thanks,
> Nisala
>
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile | +94 717600022
> WSO2 Inc | http://wso2.com/
>



-- 
Tanya Madurapperuma

Associate Technical Lead,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Sharing common SPA components within and between product(s)

[Tanya Madurapperuma]

ke a new feature named
>>>>>>>>*org.wso2.carbon.apimgt.spa.commons.feature* in *carbon-apimgt * 
>>>>>>>> repo
>>>>>>>>and push the npm package located in that feature into npm registry
>>>>>>>>2. Create separate GitHub repository like *carbon-apimgt-spa-commons
>>>>>>>>*and organize all the commonly used React components and other
>>>>>>>>JS modules into that GitHub repository and publish it to npm 
>>>>>>>> registry as-is.
>>>>>>>>
>>>>>>>> with the method[1] we could use the same carbon-apimgt GitHub repo
>>>>>>>> and use a subdirectory of it to hold shareable js modules(like the
>>>>>>>> @wso2-dashboards/widget[5] package). But with this approach fixing an 
>>>>>>>> issue
>>>>>>>> in commons module require sending fixes to the carbon-apimgt 
>>>>>>>> repository.
>>>>>>>> With the [2] approach we could use separate GitHub repo associated
>>>>>>>> with npm package and setup auto release for npm package per commit 
>>>>>>>> similar
>>>>>>>> to what we are doing with other repositories.
>>>>>>>> Please give your suggestion and ideas on this, what would be the
>>>>>>>> better approach for publishing common components/modules to npm.
>>>>>>>>
>>>>>>>> And also, for npm package name we could use a name like 
>>>>>>>> *@wso2-apimgt/commons
>>>>>>>> *with the scoping.
>>>>>>>> Please give your suggestions for a better package name as well J.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> ~KasunTe
>>>>>>>>
>>>>>>>> [1]: https://github.com/wso2/carbon-apimgt/tree/master/featu
>>>>>>>> res/apimgt/org.wso2.carbon.apimgt.publisher.feature/src/main
>>>>>>>> /resources/publisher
>>>>>>>> [2]: https://github.com/wso2/carbon-apimgt/tree/master/featu
>>>>>>>> res/apimgt/org.wso2.carbon.apimgt.store.feature/src/main/res
>>>>>>>> ources/store
>>>>>>>> [3]: https://github.com/wso2/carbon-apimgt/tree/master/featu
>>>>>>>> res/apimgt/org.wso2.carbon.apimgt.admin.feature/src/main/res
>>>>>>>> ources/admin
>>>>>>>> [4]: https://github.com/wso2/carbon-apimgt/blob/master/featu
>>>>>>>> res/apimgt/org.wso2.carbon.apimgt.publisher.feature/src/main
>>>>>>>> /resources/publisher/source/src/app/data/User.js
>>>>>>>> [5]: https://www.npmjs.com/package/@wso2-dashboards/widget
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Kasun Thennakoon*
>>>>>>>> Software Engineer
>>>>>>>> WSO2, Inc.
>>>>>>>> Mobile:+94 711661919
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> With regards,
>>>>>>> *Manu*ranga Perera.
>>>>>>>
>>>>>>> phone : 071 7 70 20 50
>>>>>>> mail : m...@wso2.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Kasun Thennakoon*
>>>>>> Software Engineer
>>>>>> WSO2, Inc.
>>>>>> Mobile:+94 711661919
>>>>>>
>>>>>> ___
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Menaka Jayawardena*
>>>>> *Software Engineer - WSO2 Inc*
>>>>> *Tel : 071 350 5470 <071%20350%205470>*
>>>>> *LinkedIn: https://lk.linkedin.com/in/menakajayawardena
>>>>> <https://lk.linkedin.com/in/menakajayawardena>*
>>>>> *Blog: https://menakamadushanka.wordpress.com/
>>>>> <https://menakamadushanka.wordpress.com/>*
>>>>>
>>>>>
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> --
>>>> *Joseph Fonseka*
>>>> WSO2 Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> mobile: +94 772 512 430
>>>> skype: jpfonseka
>>>>
>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> *Kasun Thennakoon*
>>> Software Engineer
>>> WSO2, Inc.
>>> Mobile:+94 711661919
>>>
>>
>>
>>
>> --
>> *Kasun Thennakoon*
>> Software Engineer
>> WSO2, Inc.
>> Mobile:+94 711661919
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Associate Technical Lead,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Workflow integration with ES

[Tanya Madurapperuma]

We had initial discussions regarding this feature last year and
implementation got defered due to other priorities. You can refer to [1],
[2] and [3] mail threads for more information.

[1] Generic workflow executor across the platform
[2] [Architecture][ES] Workfow Extension Model
[3] [ES] Workflow extensions support - Approval task pages or app ?

Thanks,
Tanya

On Tue, Jan 26, 2016 at 4:03 PM, Kasun Thennakoon  wrote:

> Hi Vinod,
>
> Thanks for the comment, No it's not IS scenario is not suitable rather I
> looked into current implementations of workflow integration on user signups
> available in our products and try to get the best out of them.And yes IS do
> have UI component for  Workflow Engagements and Workflow definitions which
> abstract the underline BPEL definitions from the user.IMO for the ES
> workflow integration scenario, we can also use those existing UI components
> rather than reimplementing the logic.
>
> Regards,
> ~KasunTe
>
> On Tue, Jan 26, 2016 at 3:16 PM, Vinod Kavinda  wrote:
>
>> Hi Kasun,
>> AFAIR, in IS they have a generic workflow template (bpel) and they allows
>> users to modify this via a UI component. With this behavior users don't
>> have to learn bpel and we have more control over the workflow.
>> I don't see any point in allowing users to upload workflows. (We can
>> always use BPS UI if a very rare use case occurred)
>> Why do you think the IS scenario is not suitable for yours?
>>
>> In another note, you can use BPMN also for this. We now prefer using BPMN
>> over BPEL.
>>
>> Regards,
>> Vinod
>>
>>
>> On Tue, Jan 26, 2016 at 2:50 PM, Kasun Thennakoon 
>> wrote:
>>
>>> I'm currently working on implementing workflow integration with
>>> Enterprise Store.Problem scenario is when a user signup with the user store
>>> their registration should be approved by an authorized user  in the user
>>> store before accessing the store.As I did a background study on the problem
>>> I found that currently similar feature is available with API manager store
>>> and IS dashboard with different architectures.
>>> In IS implementation, it provides UI features for adding workflow
>>> definitions and Workflow Engagements. where a user doesn't need to
>>> upload human tasks (archived file) and business process (archived files)
>>> to BPS separately, where those configurations are created in BPS via
>>> service calls to BPS.And if the workflows are added to trigger on Add user
>>> operation, when a user create an account in IS dashboard and if there is a
>>> workflow engagement associate for Add user operation, then the newly
>>> created user will be queued for approval by an authorized user.
>>> In API manager user case[2], we have to upload human tasks and business
>>> process files to BPS and disable the Simple Workflow Executor and enable WS
>>> Workflow Executor in workflow-extensions.xml.Other than those manual
>>> configurations it is similar to IS user signup workflow.
>>>
>>> IMHO, It would be easy for the user if we provide a UI for deploying
>>> human task and BPELs by getting required inputs from the user.So we can use
>>> already existing workflow Integration components from IS for user signup
>>> approval processes.
>>>
>>> any suggestions and recommendations on implementing workflow integration
>>> would be helpful.
>>>
>>> [1]:
>>> http://wso2.com/library/articles/2015/09/article-wso2-identity-server-5.1.0-workflow-feature-and-use-cases/
>>> [2]: https://docs.wso2.com/display/AM1100/Adding+a+User+Signup+Workflow
>>>
>>> Thanks
>>> --
>>> *Kasun Thennakoon*
>>> Software Engineer
>>> WSO2, Inc.
>>> Mobile:+94 711661919
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Vinod Kavinda
>> Software Engineer
>> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.*
>> Mobile : +94 (0) 712 415544
>> Blog : http://soatechflicks.blogspot.com/
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Kasun Thennakoon*
> Software Engineer
> WSO2, Inc.
> Mobile:+94 711661919
>



-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Dev] WSO2 Dashboard Server 2.0.0 Released !!!

[Tanya Madurapperuma]

The WSO2 DS team is pleased to announce the release of version 2.0.0 of
Open Source WSO2 Dashboard Server.

WSO2 Dashboard Server (DS) provides a tool set to create dashboards and
visualizations for enterprise requirements. Unlike traditional solutions,
DS exposes the power of the server to the dashboard or app developers.

The configuration of the created dashboard is stored in JSON files, and
developers have full flexibility to work with Jaggery APIs to retrieve,
manipulate, and compose data. The dashboards can be created from the
default layouts, which are shipped with the default distribution, or the
developer can create a blank layout and include gadget placeholders
wherever he/she likes, to create his/her own layout to visualize. Users can
add any amount of pages per dashboard, and determine which pages need to
have the anonymous user view and secured user view.

For more information on WSO2 Dashboard Server, please visit our product page
. You can also look at our online
product documentation
.

WSO2 Dashboard Server 2.0.0 includes following new features, improvements
and bug fixes.
New Features

   -

   [UES-901 ] - Supporting multiple
   dashboard pages within a dashboard app
   -

   [UES-902 ] - Enable SSO in
   Dashboard Server
   -

   [UES-903 ] - Fixed mobile view on
   Android devices
   -

   [UES-904 ] - Visually link pub-sub
   gadgets
   -

   [UES-905 ] - Fixed mobile view on
   iDevices
   -

   [UES-906 ] - Implement anonymous
   view of dashboard
   -

   [UES-907 ] - Themes for DS
   dashboard view mode
   -

   [UES-908 ] - Role based dashboard
   access
   -

   [UES-909 ] - Add banners to theme
   the dashboard per user
   -

   [UES-910 ] - Ship samples with
   dashboard server product
   -

   [UES-911 ] - Create a sample
   dashboard for drill down gadgets
   -

   [UES-912 ] - Per-user dashboard
   customization
   -

   [UES-913 ] - Add OAuth support for
   gadgets and pub/sub communication in DS
   -

   [UES-914 ] - Dynamic layout
   customization for dashboard editor
   -

   [UES-915 ] - Restructure the
   designer to enhance the UX
   -

   [UES-916 ] - Create JMeter scripts
   for performance tests
   -

   [UES-917 ] - Gadget Maximization
   -

   [UES-918 ] - User Profile can be
   accessed by the gadget
   -

   [UES-919 ] - Show gadget/widget
   userPref settings in view mode


Improvements

   - [UES-726 ] - Direct the user to
   anonymous page when "Make Anonymous" option is selected
   - [UES-874 ] - [Mobile] Remove the
   option to go to the edit mode from a mobile view
   - [UES-324 ] - Remove or update
   gadget without removing the layout block
   - [UES-663 ] - Filter the
   available widgets when searching
   - [UES-668 ] - Disable the
   "Personalizable" check box in USA Map when editing a anon view
   - [UES-671 ] - Option to upload
   widgets/gadgets directly to the portal
   - [UES-719 ] - Add a log message
   in the startup to print the portal URL
   - [UES-720 ] - Shall we remove the
   option to edit the banner in anon mode?
   - [UES-759 ] - Replace anon view
   toggle button with tabs in dashboard designer
   - [UES-764 ] - Add new dashboard
   layout - blank layout
   - [UES-828 ] - Look and feel of
   dashboard list not proper
   - [UES-834 ] - Look and feel
   issues with Sample 0
   - [UES-840 ] - The color theme of
   the add gadgets description does not match with the overall color theme
   - [UES-861 ] - [IE] Can add more
   than the recommended grid size in IE 11
   - [UES-739 ] - Add a horizontal
   scroll bar in all the pages of the dashboard
   - [UES-8

[Architecture] [DS] Gadget Generation Framework

[Tanya Madurapperuma]

Hi all,

*Introduction*

The purpose of this feature is to provide a framework to generate gadgets
where you can plug datasource providers and chart templates.

For an example, you will be able to plug your RDBMS datasource, rest api ,
csv file , real time datsources etc as pluggable providers.

*Flow*

Select datasource provider (stage 1) --> Configure datasource parameters
(stage 2) --> Configure chart parameters (stage 3) --> Preview gadget
(stage 4) --> Generate gadget (stage 5)

*Proposed Architecuture*

Provider developers can plug their providers to DS by adding their
respective provider into the designer.json

*{*
**
*"gadgetGeneration" :{*
*"isCreateGadgetEnable": false,*
*"providers": ["batch", "rdbms", "rest", "rt"]*
*},*
*   *
*}*

Provider implementation should be placed under /portal/extensions/providers
and should mainly contain 2 files.

   - config.json - contains the expected configuration in the "Configure
   datasource parameters" stage 2

*example config*
*   {*

*"id":"rdbms",*
*"name" : "Relational Database Source",*
*"image" : "",*
*"config" : [*
*{*
*"fieldLabel" : "Database URL",*
*"fieldName" :"db_url",*
*"fieldType" : "text",*
*"defaultValue" : "",*
*"isRequired" : true*
*},*
*{*
*"fieldLabel" : "Username",*
*"fieldName" :"username",*
*"fieldType" : "text",*
*"defaultValue" : "",*
*"isRequired" : true*
*},*
*{*
*"fieldLabel" : "Password",*
*"fieldName" :"password",*
*"fieldType" : "password",*
*"defaultValue" : "",*
*"isRequired" : true*
*},*
*{*
*"fieldLabel" : " Database Driver",*
*"fieldName" :"driver",*
*"fieldType" : "dropDown",*
*"valueSet" : [ ],*
*"isRequired" : true*
*},*
*{*
*"fieldLabel" : " Check Box",*
*"fieldName" :"checkbox",*
*"fieldType" : "checkbox",*
*"isRequired" : true*
*},*
*{*
*"fieldType" : "advanced",*
*"partialName" : "myPartial"*
*}*
*]*
*} *

The configuration UI will be dynamically generated for the data types
text-box, checkbox, password field and drop-down. And a provider can plug
his own UI blocks as partials when there are advanced fields.


   - index.js - implements the provider api for
  - validateData (providerConfig)
 - To validate the inputs provided at the stage 2
 - providerConfig will be key value pairs of provided field names
 and values
  - getSchema (providerConfig)
 - Returns the list of column names and their data types of the
 configured data provider
  - getData (providerConfig,schemaPropertyList)
 - schemaPropertyList  will be list of column names selected at
 stage 3


Similarly chart templates can also be plugged via configuring at
designer.json
Chart template mplementations also goes under
/portal/extensions/chart-templates and have 2 main files.


   - config.json - contains the fields that needs to be populated at stage 3

*example config*

*{*
*"id":"lineChart",*
*"name" : "Line Chart",*
*"config": [*
*{*
*"fieldLabel": "X axis",*
*"fieldName": "x",*
*"fieldType": "String",*
*"fieldValue" : ["$COLUMN_NAMES"]*
*},*
*{*
*"fieldLabel": "Y axis",*
*"fieldName": "y",*
*    "fieldType": "Int",*
*"fieldValue" : ["$COLUMN_NAMES"]*
*},*
*{*
*"fieldLabel": "Chart Colour",*
*"fieldName": "colour",*
*"fieldType": "String"*
*}*
*]*

*}*

If the first element of field value is * ["$COLUMN_NAMES"]  *,it will
populate the list of column names retrieved getSchema method of provider
api.


   - index.js - implements the chart template api for
   - draw (chartConfig, data)
 - responsible for plotting the chart/gadget
 - chartConfig will be key value pairs of chart configurations
 provided at stage 3
 - data will be the actual data retrieved by calling getData method
 of provider api


Appreciate your input on the above approach.

Thanks,
Tanya

-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [DS] Gadget Generation Framework

[Tanya Madurapperuma]

Hi Suho,

Please find my comments.

On Fri, Apr 29, 2016 at 9:42 PM, Sriskandarajah Suhothayan 
wrote:

> Please see the comments inline.
>
> On Fri, Apr 29, 2016 at 7:52 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> *Introduction*
>>
>> The purpose of this feature is to provide a framework to generate gadgets
>> where you can plug datasource providers and chart templates.
>>
>> For an example, you will be able to plug your RDBMS datasource, rest api
>> , csv file , real time datsources etc as pluggable providers.
>>
>> *Flow*
>>
>> Select datasource provider (stage 1) --> Configure datasource parameters
>> (stage 2) --> Configure chart parameters (stage 3) --> Preview gadget
>> (stage 4) --> Generate gadget (stage 5)
>>
>> *Proposed Architecuture*
>>
>> Provider developers can plug their providers to DS by adding their
>> respective provider into the designer.json
>>
>> *{*
>> **
>> *"gadgetGeneration" :{*
>> *"isCreateGadgetEnable": false,*
>> *"providers": ["batch", "rdbms", "rest", "rt"]*
>> *},*
>> *   *
>> *}*
>>
>> Can't we load this dynamically by scanning the files at server start?
>
Yes, we can. But the intention of having this config was to turn off some
providers based on this config. If we load providers dynamically based on
the files then it is not possible to turn them off if required.

>
> Provider implementation should be placed under
>> /portal/extensions/providers and should mainly contain 2 files.
>>
>>- config.json - contains the expected configuration in the "Configure
>>datasource parameters" stage 2
>>
>> *example config*
>> *   {*
>>
>> *"id":"rdbms",*
>> *"name" : "Relational Database Source",*
>> *"image" : "",*
>> *"config" : [*
>> *{*
>> *"fieldLabel" : "Database URL",*
>> *"fieldName" :"db_url",*
>> *"fieldType" : "text",*
>> *"defaultValue" : "",*
>> *"isRequired" : true*
>> *},*
>> *{*
>> *"fieldLabel" : "Username",*
>> *"fieldName" :"username",*
>> *"fieldType" : "text",*
>> *"defaultValue" : "",*
>> *"isRequired" : true*
>> *},*
>> *{*
>> *"fieldLabel" : "Password",*
>> *"fieldName" :"password",*
>> *"fieldType" : "password",*
>> *"defaultValue" : "",*
>> *"isRequired" : true*
>> *},*
>> *{*
>> *"fieldLabel" : " Database Driver",*
>> *"fieldName" :"driver",*
>> *"fieldType" : "dropDown",*
>> *"valueSet" : [ ],*
>> *"isRequired" : true*
>> *},*
>> *{*
>> *"fieldLabel" : " Check Box",*
>> *"fieldName" :"checkbox",*
>> *"fieldType" : "checkbox",*
>> *"isRequired" : true*
>> *},*
>> *{*
>> *"fieldType" : "advanced",*
>> *"partialName" : "myPartial"*
>> *}*
>> *]*
>> *} *
>>
>> The configuration UI will be dynamically generated for the data types
>> text-box, checkbox, password field and drop-down. And a provider can plug
>> his own UI blocks as partials when there are advanced fields.
>>
>>
>>- index.js - implements the provider api for
>>   - validateData (providerConfig)
>>  - To validate the inputs provided at the stage 2
>>  - providerConfig will be key value pairs of provided field
>>  names and values
>>   - getSchema (providerConfig)
>>  - Returns the list of column names and their data types of the
>>  configured data provider
>>   - getData (providerConfig,schemaPropertyList)
>>

Re: [Architecture] [DS] Gadget Generation Framework

[Tanya Madurapperuma]

Hi Dunith,

On Mon, May 2, 2016 at 6:54 AM, Dunith Dhanushka  wrote:

> Hi Tanya,
>
> I too have few comments.
>
> 1. Can we add data access mode parameter to the provider config as well?
> So there can be a parameter named "mode" which will have either "push" or
> "pull"
>
IMO gadget creator doesn't need the flexibility to decide the mode, hence
we don't need to provide mode as a provider config element. Rather we can
have a method in the index.js of provider as getMode().
But provider can add the poll interval to the provider config if he allows
user to configure it.


> 2. Like Suhu mentioned, we can derive the list of providers by iterating
> over specific FS directory.
>
Please see my comment for Suho's mail.

> 3. Can we merge wizard steps 3 and 4 together? Then user may instantly see
> the preview of a chart whenever he makes some chart configuration.
>
+1

>
> 4. Like Suho mentioned, we'll have to pass the schemaPropertyList to the
> chats index.js and generate the config.json.
>
+1

>
> Regards,
> Dunith
>
> Thanks,
Tanya

>
> On Fri, Apr 29, 2016 at 9:42 PM, Sriskandarajah Suhothayan 
> wrote:
>
>> Please see the comments inline.
>>
>> On Fri, Apr 29, 2016 at 7:52 PM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi all,
>>>
>>> *Introduction*
>>>
>>> The purpose of this feature is to provide a framework to generate
>>> gadgets where you can plug datasource providers and chart templates.
>>>
>>> For an example, you will be able to plug your RDBMS datasource, rest api
>>> , csv file , real time datsources etc as pluggable providers.
>>>
>>> *Flow*
>>>
>>> Select datasource provider (stage 1) --> Configure datasource parameters
>>> (stage 2) --> Configure chart parameters (stage 3) --> Preview gadget
>>> (stage 4) --> Generate gadget (stage 5)
>>>
>>> *Proposed Architecuture*
>>>
>>> Provider developers can plug their providers to DS by adding their
>>> respective provider into the designer.json
>>>
>>> *{*
>>> **
>>> *"gadgetGeneration" :{*
>>> *"isCreateGadgetEnable": false,*
>>> *"providers": ["batch", "rdbms", "rest", "rt"]*
>>> *},*
>>> *   *
>>> *}*
>>>
>>> Can't we load this dynamically by scanning the files at server start?
>>
>> Provider implementation should be placed under
>>> /portal/extensions/providers and should mainly contain 2 files.
>>>
>>>- config.json - contains the expected configuration in the
>>>"Configure datasource parameters" stage 2
>>>
>>> *example config*
>>> *   {*
>>>
>>> *"id":"rdbms",*
>>> *"name" : "Relational Database Source",*
>>> *"image" : "",*
>>> *"config" : [*
>>> *{*
>>> *"fieldLabel" : "Database URL",*
>>> *"fieldName" :"db_url",*
>>> *"fieldType" : "text",*
>>> *"defaultValue" : "",*
>>> *"isRequired" : true*
>>> *},*
>>> *{*
>>> *"fieldLabel" : "Username",*
>>> *"fieldName" :"username",*
>>> *"fieldType" : "text",*
>>> *"defaultValue" : "",*
>>> *"isRequired" : true*
>>> *},*
>>> *{*
>>> *"fieldLabel" : "Password",*
>>> *"fieldName" :"password",*
>>> *"fieldType" : "password",*
>>> *"defaultValue" : "",*
>>> *"isRequired" : true*
>>> *},*
>>> *{*
>>> *"fieldLabel" : " Database Driver",*
>>> *"fieldName" :"driver",*
>>> *"fieldType" : "dropDown",*
>>> *"valueSet" : [ ],*
>>> *"isRequired" : true*
>>> *},*
>>> *{*
>>> *"fie

Re: [Architecture] [DS] Gadget Generation Framework

[Tanya Madurapperuma]

Hi all,

We had a discussion again regarding this and please find the modified notes
below.

Provider api (index.js) needs to implement the following functions.

   - validate(providerConfig)
  - same as described before - is to validate the user input for
  provider configuration
   - getConfig()
   - This will require the existing config.json and push any dynamic fields
  that needs to be populated in the UI. If not will return the
config.json as
  it is.
   - getMode()
   - This will return whether the data provider supports polling or pushing
   - getSchema(providerConfig)
   - This will take user filled in provider configuration and  return all
  the column names and all column types
  - getData(providerConfig, schema, limit)
  - schema - will take the full table schema returned from  getSchema
  method
  - limit is to get the number of records required
   - registerCallBackforPush(providerConfig, schema)
   - used when the mode is push


Chart api (index.js) will also have a similar set of functions to provider
api.

   - getConfig(schema)
   - will take the schema returned from getSchema function of provider api
  and return the config to be populated in the chart configuration UI
   - validate(chartConfig)
   - similar to provider api, will validate the user input for chart
  configuration
   - isProviderRequired()
   - To be used provider configs need to be skipped in the generation
  framework
   - draw (chartConfig, schema, data)
   - Return the gadget content
   - update(data)

@ Manu : +1 for fetching from FS by default and to have ignore list in the
config.

Thanks,
Tanya


On Mon, May 2, 2016 at 10:06 AM, Tanya Madurapperuma  wrote:

> Hi Dunith,
>
> On Mon, May 2, 2016 at 6:54 AM, Dunith Dhanushka  wrote:
>
>> Hi Tanya,
>>
>> I too have few comments.
>>
>> 1. Can we add data access mode parameter to the provider config as well?
>> So there can be a parameter named "mode" which will have either "push" or
>> "pull"
>>
> IMO gadget creator doesn't need the flexibility to decide the mode, hence
> we don't need to provide mode as a provider config element. Rather we can
> have a method in the index.js of provider as getMode().
> But provider can add the poll interval to the provider config if he allows
> user to configure it.
>
>
>> 2. Like Suhu mentioned, we can derive the list of providers by iterating
>> over specific FS directory.
>>
> Please see my comment for Suho's mail.
>
>> 3. Can we merge wizard steps 3 and 4 together? Then user may instantly
>> see the preview of a chart whenever he makes some chart configuration.
>>
> +1
>
>>
>> 4. Like Suho mentioned, we'll have to pass the schemaPropertyList to the
>> chats index.js and generate the config.json.
>>
> +1
>
>>
>> Regards,
>> Dunith
>>
>> Thanks,
> Tanya
>
>>
>> On Fri, Apr 29, 2016 at 9:42 PM, Sriskandarajah Suhothayan > > wrote:
>>
>>> Please see the comments inline.
>>>
>>> On Fri, Apr 29, 2016 at 7:52 PM, Tanya Madurapperuma 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> *Introduction*
>>>>
>>>> The purpose of this feature is to provide a framework to generate
>>>> gadgets where you can plug datasource providers and chart templates.
>>>>
>>>> For an example, you will be able to plug your RDBMS datasource, rest
>>>> api , csv file , real time datsources etc as pluggable providers.
>>>>
>>>> *Flow*
>>>>
>>>> Select datasource provider (stage 1) --> Configure datasource
>>>> parameters (stage 2) --> Configure chart parameters (stage 3) --> Preview
>>>> gadget (stage 4) --> Generate gadget (stage 5)
>>>>
>>>> *Proposed Architecuture*
>>>>
>>>> Provider developers can plug their providers to DS by adding their
>>>> respective provider into the designer.json
>>>>
>>>> *{*
>>>> **
>>>> *"gadgetGeneration" :{*
>>>> *"isCreateGadgetEnable": false,*
>>>> *"providers": ["batch", "rdbms", "rest", "rt"]*
>>>> *},*
>>>> *   *
>>>> *}*
>>>>
>>>> Can't we load this dynamically by scanning the files at server start?
>>>
>>> Provider implementation should be placed under
>>>> /portal/extensions/providers and should

Re: [Architecture] [DS] Gadget Generation Framework

[Tanya Madurapperuma]

Hi all,

This is to provide an update regarding the above framework.

We have currently completed a draft version of the wizard up to stage 2
with dynamic partial support and the source can be found at [1].
Please note that we have not paid any attention to fine tuning the UI yet.

[1]
https://github.com/wso2/carbon-dashboards/tree/gadget-generation-framework

Thanks,
Tanya

On Tue, May 3, 2016 at 10:33 AM, Tanya Madurapperuma  wrote:

> Hi all,
>
> We had a discussion again regarding this and please find the modified
> notes below.
>
> Provider api (index.js) needs to implement the following functions.
>
>- validate(providerConfig)
>   - same as described before - is to validate the user input for
>   provider configuration
>- getConfig()
>- This will require the existing config.json and push any dynamic
>   fields that needs to be populated in the UI. If not will return the
>   config.json as it is.
>- getMode()
>- This will return whether the data provider supports polling or
>   pushing
>- getSchema(providerConfig)
>- This will take user filled in provider configuration and  return all
>   the column names and all column types
>   - getData(providerConfig, schema, limit)
>   - schema - will take the full table schema returned from  getSchema
>   method
>   - limit is to get the number of records required
>- registerCallBackforPush(providerConfig, schema)
>- used when the mode is push
>
>
> Chart api (index.js) will also have a similar set of functions to provider
> api.
>
>- getConfig(schema)
>- will take the schema returned from getSchema function of provider
>   api and return the config to be populated in the chart configuration UI
>- validate(chartConfig)
>- similar to provider api, will validate the user input for chart
>   configuration
>- isProviderRequired()
>- To be used provider configs need to be skipped in the generation
>   framework
>- draw (chartConfig, schema, data)
>- Return the gadget content
>- update(data)
>
> @ Manu : +1 for fetching from FS by default and to have ignore list in the
> config.
>
> Thanks,
> Tanya
>
>
> On Mon, May 2, 2016 at 10:06 AM, Tanya Madurapperuma 
> wrote:
>
>> Hi Dunith,
>>
>> On Mon, May 2, 2016 at 6:54 AM, Dunith Dhanushka  wrote:
>>
>>> Hi Tanya,
>>>
>>> I too have few comments.
>>>
>>> 1. Can we add data access mode parameter to the provider config as well?
>>> So there can be a parameter named "mode" which will have either "push" or
>>> "pull"
>>>
>> IMO gadget creator doesn't need the flexibility to decide the mode, hence
>> we don't need to provide mode as a provider config element. Rather we can
>> have a method in the index.js of provider as getMode().
>> But provider can add the poll interval to the provider config if he
>> allows user to configure it.
>>
>>
>>> 2. Like Suhu mentioned, we can derive the list of providers by iterating
>>> over specific FS directory.
>>>
>> Please see my comment for Suho's mail.
>>
>>> 3. Can we merge wizard steps 3 and 4 together? Then user may instantly
>>> see the preview of a chart whenever he makes some chart configuration.
>>>
>> +1
>>
>>>
>>> 4. Like Suho mentioned, we'll have to pass the schemaPropertyList to
>>> the chats index.js and generate the config.json.
>>>
>> +1
>>
>>>
>>> Regards,
>>> Dunith
>>>
>>> Thanks,
>> Tanya
>>
>>>
>>> On Fri, Apr 29, 2016 at 9:42 PM, Sriskandarajah Suhothayan <
>>> s...@wso2.com> wrote:
>>>
>>>> Please see the comments inline.
>>>>
>>>> On Fri, Apr 29, 2016 at 7:52 PM, Tanya Madurapperuma 
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> *Introduction*
>>>>>
>>>>> The purpose of this feature is to provide a framework to generate
>>>>> gadgets where you can plug datasource providers and chart templates.
>>>>>
>>>>> For an example, you will be able to plug your RDBMS datasource, rest
>>>>> api , csv file , real time datsources etc as pluggable providers.
>>>>>
>>>>> *Flow*
>>>>>
>>>>> Select datasource provider (stage 1) --> Configure datasource
>>>>> parameters (stage 2) --> Configure chart parameters 

Re: [Architecture] [DS] Gadget Generation Framework

[Tanya Madurapperuma]

Hi Suho and all,

Seems like we need to do a small modification to the registerCallBackforPush
function. Even though we agreed to pass providerConfig and schema, we need
to have a callback function as well. Proposed modification is as follows.

*provider's index.js*
registerCallBackforPush (providerConfig, schema, callback){
//logic to fetch data
callback();
}

*in the generated gadget*
registerCallBackforPush(providerConfig, schema , function(providerData){
   draw(placeholder', chartConfig, schema, providerData);
})

Appreciate if you could provide your input.

Thanks,
Tanya




On Fri, May 6, 2016 at 2:58 PM, Tanya Madurapperuma  wrote:

> Hi all,
>
> This is to provide an update regarding the above framework.
>
> We have currently completed a draft version of the wizard up to stage 2
> with dynamic partial support and the source can be found at [1].
> Please note that we have not paid any attention to fine tuning the UI yet.
>
> [1]
> https://github.com/wso2/carbon-dashboards/tree/gadget-generation-framework
>
> Thanks,
> Tanya
>
> On Tue, May 3, 2016 at 10:33 AM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> We had a discussion again regarding this and please find the modified
>> notes below.
>>
>> Provider api (index.js) needs to implement the following functions.
>>
>>- validate(providerConfig)
>>   - same as described before - is to validate the user input for
>>   provider configuration
>>- getConfig()
>>- This will require the existing config.json and push any dynamic
>>   fields that needs to be populated in the UI. If not will return the
>>   config.json as it is.
>>- getMode()
>>- This will return whether the data provider supports polling or
>>   pushing
>>- getSchema(providerConfig)
>>- This will take user filled in provider configuration and  return
>>   all the column names and all column types
>>   - getData(providerConfig, schema, limit)
>>   - schema - will take the full table schema returned from
>>getSchema method
>>   - limit is to get the number of records required
>>- registerCallBackforPush(providerConfig, schema)
>>- used when the mode is push
>>
>>
>> Chart api (index.js) will also have a similar set of functions to
>> provider api.
>>
>>- getConfig(schema)
>>- will take the schema returned from getSchema function of provider
>>   api and return the config to be populated in the chart configuration UI
>>- validate(chartConfig)
>>- similar to provider api, will validate the user input for chart
>>   configuration
>>- isProviderRequired()
>>- To be used provider configs need to be skipped in the generation
>>   framework
>>- draw (chartConfig, schema, data)
>>- Return the gadget content
>>- update(data)
>>
>> @ Manu : +1 for fetching from FS by default and to have ignore list in
>> the config.
>>
>> Thanks,
>> Tanya
>>
>>
>> On Mon, May 2, 2016 at 10:06 AM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi Dunith,
>>>
>>> On Mon, May 2, 2016 at 6:54 AM, Dunith Dhanushka 
>>> wrote:
>>>
>>>> Hi Tanya,
>>>>
>>>> I too have few comments.
>>>>
>>>> 1. Can we add data access mode parameter to the provider config as
>>>> well? So there can be a parameter named "mode" which will have either
>>>> "push" or "pull"
>>>>
>>> IMO gadget creator doesn't need the flexibility to decide the mode,
>>> hence we don't need to provide mode as a provider config element. Rather we
>>> can have a method in the index.js of provider as getMode().
>>> But provider can add the poll interval to the provider config if he
>>> allows user to configure it.
>>>
>>>
>>>> 2. Like Suhu mentioned, we can derive the list of providers by
>>>> iterating over specific FS directory.
>>>>
>>> Please see my comment for Suho's mail.
>>>
>>>> 3. Can we merge wizard steps 3 and 4 together? Then user may instantly
>>>> see the preview of a chart whenever he makes some chart configuration.
>>>>
>>> +1
>>>
>>>>
>>>> 4. Like Suho mentioned, we'll have to pass the schemaPropertyList to
>>>> the chats index.js and generate the config.json.
>>>>
>>> +1
>>>
>>>>
>>>> Regards,
>

Re: [Architecture] Access Level Model For WSO2 Dashboard Server

[Tanya Madurapperuma]

Is this model scalable? Because per dashboard we will have to create 4
internal roles. So if we have N number of dashboards we will end up having
4 * N number of internal roles.

@ IS team : is this approach fine? Or is there any better approach?

Thanks,
Tanya

On Mon, Jun 6, 2016 at 3:44 PM, Nisala Nanayakkara  wrote:

> adding Johan and Manuranga
>
> Thanks,
> Nisala
>
> On Mon, Jun 6, 2016 at 3:41 PM, Nisala Nanayakkara 
> wrote:
>
>> Hi all,
>>
>> I am working on implementing an access levels model for WSO2 Dashboard
>> Server. Currently global permission model for create/delete/login is
>> implemented by Megala. Since it does not support to provide per dashboard
>> level access for the users. I am going to extend it and implement a
>> permission model that can be used to provide per dashboard level access for
>> the users.
>>
>> In order to implement this feature, I am going to add four roles at
>> dashboard creation time as follows,
>>
>>- internal/dashboard/{dashboardID}/editor
>>- internal/dashboard/{dashboardID}/viewer
>>- internal/dashboard/{dashboardID}/settings
>>- internal/dashboard/{dashboardID}/delete
>>
>> At the dashboard creation time, the user who creates the dashboard will
>> get all the four roles. But other users have to get above roles to do
>> appropriate actions to the dashboard. So that we can set above four roles
>> for the users and They will be given different access levels according to
>> their roles.
>>
>> Please feel free to give any feedback.
>>
>> Thanks,
>> Nisala
>> --
>> *Nisala Niroshana Nanayakkara,*
>> Software Engineer
>> Mobile:(+94)717600022
>> WSO2 Inc., http://wso2.com/
>>
>
>
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile:(+94)717600022
> WSO2 Inc., http://wso2.com/
>



-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi all,

During an offline discussion with Jerad following modification were
suggested regarding the directory structure of the extension model. All
these changes are subjected to js and css file locations.

*Chart template structure*

|── line-chart
  │   ├── css
  │   │   └── line-chart.css
  │   └── js
  │   ├── d3.min.js
  │   ├── vega.js
  │   └── VizGrammar.min.js
   |── config.json
  ├── api.js


*Changes to the existing model*

   - rename index.js to api.js
   - rename chart-libs folder to js
   - have a css folder in the same level


*Generated gadget structure*

└── test_gadget
│   │   ├── conf.json
│   │   ├── css
│   │   │   └── line-chart.css
│   │   ├── gadget-controller.jag
│   │   ├── gadget.json
│   │   ├── index.png
│   │   ├── index.xml
│   │   └── js
│   │   ├── core
│   │   │   ├── gadget-core.js
│   │   │   ├── line-chart-api.js
│   │   │   └── provider-api.js
│   │   ├── d3.min.js
│   │   ├── vega.js
│   │   └── VizGrammar.min.js


*Changes to the existing model*

   - Instead of the *chart-libs* folder inside *js* folder, have a
*core *folder
   inside *js *folder and place chart specific js files in js folder


*Folder structure for storing common libs*

portal
  |── gadget-commons

   ├── css
   │   └── common.css
   └── js
   └── common.js


*Changes to the existing model*

   - Now we have common libs inside portal/libs/common-chart-libs/

*chart config.json*

"common": {
"js": ["common"],
"css": ["common"]
},
"chart": {
"js": ["d3.min", "vega", "VizGrammar.min"],
"css": ["line-chart"]
}

*existing config.json*

"common-libs" : ["wso2gadgets","chart-utils"],
"chart-libs" : ["d3.min","vega","VizGrammar.min"]

I think this model is cleaner and intuitive than the exiting model.
AFAIK existing wizard is only used for IOT analytics. If there are no
concerns from them shall we move to this new model?

@ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
Appreciate your input.

Thanks,
Tanya

-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi Rajith,

We have not done any GA release, not even an Alpha release of the product
with this, but a component repo release.

Thanks,
Tanya

On Tue, Jun 7, 2016 at 3:17 PM, Rajith Vitharana  wrote:

> Hi Tanya,
>
> On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> During an offline discussion with Jerad following modification were
>> suggested regarding the directory structure of the extension model. All
>> these changes are subjected to js and css file locations.
>>
>> *Chart template structure*
>>
>> |── line-chart
>>   │   ├── css
>>   │   │   └── line-chart.css
>>   │   └── js
>>   │   ├── d3.min.js
>>   │   ├── vega.js
>>   │   └── VizGrammar.min.js
>>|── config.json
>>   ├── api.js
>>
>>
>> *Changes to the existing model*
>>
>>- rename index.js to api.js
>>- rename chart-libs folder to js
>>- have a css folder in the same level
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> │   │   ├── conf.json
>> │   │   ├── css
>> │   │   │   └── line-chart.css
>> │   │   ├── gadget-controller.jag
>> │   │   ├── gadget.json
>> │   │   ├── index.png
>> │   │   ├── index.xml
>> │   │   └── js
>> │   │   ├── core
>> │   │   │   ├── gadget-core.js
>> │   │   │   ├── line-chart-api.js
>> │   │   │   └── provider-api.js
>> │   │   ├── d3.min.js
>> │   │   ├── vega.js
>> │   │   └── VizGrammar.min.js
>>
>>
>> *Changes to the existing model*
>>
>>- Instead of the *chart-libs* folder inside *js* folder, have a *core
>>*folder inside *js *folder and place chart specific js files in js
>>folder
>>
>>
>> *Folder structure for storing common libs*
>>
>> portal
>>   |── gadget-commons
>>
>>├── css
>>│   └── common.css
>>└── js
>>└── common.js
>>
>>
>> *Changes to the existing model*
>>
>>- Now we have common libs inside portal/libs/common-chart-libs/
>>
>> *chart config.json*
>>
>> "common": {
>> "js": ["common"],
>> "css": ["common"]
>> },
>> "chart": {
>> "js": ["d3.min", "vega", "VizGrammar.min"],
>> "css": ["line-chart"]
>> }
>>
>> *existing config.json*
>>
>> "common-libs" : ["wso2gadgets","chart-utils"],
>> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>>
>> I think this model is cleaner and intuitive than the exiting model.
>> AFAIK existing wizard is only used for IOT analytics. If there are no
>> concerns from them shall we move to this new model?
>>
> If we have released a version with earlier method, there may be people
> using it in future(even though only IOT is using that for now) so it's
> better to think of a migration process as well. Or else proper
> documentation and ask not to use earlier version (which I feel is not a
> good thing)
>
> Thanks,
>
> --
> Rajith Vitharana
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94715883223
> Blog : http://lankavitharana.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi all,

Thank you for your inputs.

@ Dakshika :
Based on your input following modifications were made.

*Chart template structure*

└── line-chart
├── api.js
├── config.json
├── chart-libs
│   └── vendorName_version
│   └── js_css_images_etc_as_same_as_vendor_ships
├── css
│   └── line-chart.css
└── js
└── line-chart.js


*Generated gadget structure*

└── test_gadget
├── conf.json
├── gadget-controller.jag
├── gadget.json
├── index.png
├── index.xml
├── chart-libs
│   └── vendorName_version
│   └── js_css_images_etc_as_same_as_vendor_ships
├── css
│   └── line-chart.css
└── js
├── core-js
│   ├── gadget-core.js
│   ├── line-chart-api.js
│   └── provider-api.js
└── line-chart.js


*Folder structure for storing common libs*

portal
  |── libs

  ├── vendorName_version
  │   ├── 


*Changes to the existing model*

   - common libs will reside inside portal/libs/

*chart config.json*

"common": {
"js": ["vendorName_version/common"],
"css": ["vendorName_version/common"]
},
"chart": {
"js": ["vendorName_version/d3.min", "vendorName_version/vega",
"line-chart"],
"css": ["vendorName_version/graph, line-chart"]
}

"common" is for libs fetched from /portal/libs
"chart" is for both chart specfic libs inside js folder of chart template
and chart-libs that are coming from vendors.

So with the change suggested by Dakshika we will have to specify the
directory path of chart-libs in the config.json (ex:
 "vendorName_version/d3.min" )
But if it is a chart specific js file (in this example line-chart.js)
specifying the file name is enough.

In the gadget xml of the generated gadget we will be using the relative
path for libs fetched from /portal/libs.

@ Suho : Yes, the gadgets generated via old wizard will still work, I was
worried about the consistency between old gadgets and new gadgets generated
via the wizard. As per the offline chat we had, no obligations from IOT
side.

Thanks,
Tanya

-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com

On Tue, Jun 7, 2016 at 3:53 PM, Dakshika Jayathilaka 
wrote:

> Hi All,
>
> IMO it's better if we can maintain third-party libraries as a separate
> entity. Usually, most of the third party libs have their own dependencies
> (ex: some CSS files refer images/ fonts ). If we place them separately it's
> hard to identify relevant dependency at a glance.
>
>  At the same time, I would like to propose to have library version as
> well. This will really useful if someone wants to upgrade third-party lib
> etc.
>
> Regards,
>
> *Dakshika Jayathilaka*
> PMC Member & Committer of Apache Stratos
> Senior Software Engineer
> WSO2, Inc.
> lean.enterprise.middleware
> 0771100911
>
> On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> During an offline discussion with Jerad following modification were
>> suggested regarding the directory structure of the extension model. All
>> these changes are subjected to js and css file locations.
>>
>> *Chart template structure*
>>
>> |── line-chart
>>   │   ├── css
>>   │   │   └── line-chart.css
>>   │   └── js
>>   │   ├── d3.min.js
>>   │   ├── vega.js
>>   │   └── VizGrammar.min.js
>>|── config.json
>>   ├── api.js
>>
>>
>> *Changes to the existing model*
>>
>>- rename index.js to api.js
>>- rename chart-libs folder to js
>>- have a css folder in the same level
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> │   │   ├── conf.json
>> │   │   ├── css
>> │   │   │   └── line-chart.css
>> │   │   ├── gadget-controller.jag
>> │   │   ├── gadget.json
>> │   │   ├── index.png
>> │   │   ├── index.xml
>> │   │   └── js
>> │   │   ├── core
>> │   │   │   ├── gadget-core.js
>> │   │   │   ├── line-chart-api.js
>> │   │   │   └── provider-api.js
>> │   │   ├── d3.min.js
>> │   │   ├── vega.js
>> │   │   └── VizGrammar.min.js
>>
>>
>> *Changes to the existing model*
>>
>>- Instead of the *chart-libs* folder inside *js* folder, have a *core
>>*folder inside *js *folder and place chart specific js files in js
>>folder
>>
>>
>

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi Manu,

On Tue, Jun 7, 2016 at 8:05 PM, Manuranga Perera  wrote:

> Hi Tanya,
>
> 1) Are we really generating gadgets, though the wizard or generating
> JSONs? (I personally don't like the former, as we have discussed before)
>
We are generating the gadget not JSONs.

>
> 2) If we are generating, which files are dynamic generated Vs. which files
> are copies? I think it should be possible to figure out by looking at files.
>
You can find the template that we use now at [1]. Rest of the files will be
directly copied from the chart or provider template.

[1]
https://github.com/wso2/carbon-dashboards/tree/master/apps/portal/templates/gadgets/gadget-generation-templates


Thanks,
Tanya

>
> On Tue, Jun 7, 2016 at 5:41 AM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> During an offline discussion with Jerad following modification were
>> suggested regarding the directory structure of the extension model. All
>> these changes are subjected to js and css file locations.
>>
>> *Chart template structure*
>>
>> |── line-chart
>>   │   ├── css
>>   │   │   └── line-chart.css
>>   │   └── js
>>   │   ├── d3.min.js
>>   │   ├── vega.js
>>   │   └── VizGrammar.min.js
>>|── config.json
>>   ├── api.js
>>
>>
>> *Changes to the existing model*
>>
>>- rename index.js to api.js
>>- rename chart-libs folder to js
>>- have a css folder in the same level
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> │   │   ├── conf.json
>> │   │   ├── css
>> │   │   │   └── line-chart.css
>> │   │   ├── gadget-controller.jag
>> │   │   ├── gadget.json
>> │   │   ├── index.png
>> │   │   ├── index.xml
>> │   │   └── js
>> │   │   ├── core
>> │   │   │   ├── gadget-core.js
>> │   │   │   ├── line-chart-api.js
>> │   │   │   └── provider-api.js
>> │   │   ├── d3.min.js
>> │   │   ├── vega.js
>> │   │   └── VizGrammar.min.js
>>
>>
>> *Changes to the existing model*
>>
>>- Instead of the *chart-libs* folder inside *js* folder, have a *core
>>*folder inside *js *folder and place chart specific js files in js
>>folder
>>
>>
>> *Folder structure for storing common libs*
>>
>> portal
>>   |── gadget-commons
>>
>>├── css
>>│   └── common.css
>>└── js
>>└── common.js
>>
>>
>> *Changes to the existing model*
>>
>>- Now we have common libs inside portal/libs/common-chart-libs/
>>
>> *chart config.json*
>>
>> "common": {
>> "js": ["common"],
>> "css": ["common"]
>> },
>> "chart": {
>> "js": ["d3.min", "vega", "VizGrammar.min"],
>> "css": ["line-chart"]
>> }
>>
>> *existing config.json*
>>
>> "common-libs" : ["wso2gadgets","chart-utils"],
>> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>>
>> I think this model is cleaner and intuitive than the exiting model.
>> AFAIK existing wizard is only used for IOT analytics. If there are no
>> concerns from them shall we move to this new model?
>>
>> @ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
>> Appreciate your input.
>>
>> Thanks,
>> Tanya
>>
>> --
>> Tanya Madurapperuma
>>
>> Senior Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>



-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

@ Manu :
Edit/ Re-generate function is not supported yet. The initial plan was to
have a gadget generation tool which is similar to what was there in DAS but
with extension points to plug providers and chart templates.

@ Jerad :
Please see my inline comments.
On Wed, Jun 8, 2016 at 10:04 AM, Jerad Rutnam  wrote:

> Hi Tanya,
>
> Few more suggestions for the offline chat we had previously, what if we do
> below changes?
>
> *Chart template structure*
>
> └── line-chart
> ├── api.js
> ├── config.json
> ├── chart-libs - *libs **[template folder could be something other
> than a chart type. e.g. Map, Widget]*
> │   └── vendorName_version
> │   └── [ js_css_images_etc_as_same_as_vendor_ships ]
> ├── css
> │   └── line-chart.css
> └── js
> └── line-chart.js
>
>
> *Generated gadget structure*
>
> └── test_gadget
> ├── conf.json
> ├── gadget-controller.jag
> ├── gadget.json
> ├── index.png
> ├── index.xml
> ├── chart-libs - *libs **[this folder can have any third party
> libraries, not only chart libraries]*
> │   └── vendorName_version
> │   └── [ js_css_images_etc_as_same_as_vendor_ships ]
> ├── css
> │   └── line-chart.css
> └── js
> ├── core-js - *core **[we are already in js folder - so we can
> take out the js part]*
> │   ├── gadget-core.js
> │   ├── line-chart-api.js
> │   └── provider-api.js
> └── line-chart.js
>
>
> And in chart *config.json*: What if we have file extensions along with
> the file name? Any reason to remove it?
>
> "*imports*": {
> "js": ["vendorName_version/common*.js*"],
> "css": ["vendorName_version/common*.css*"]
> },
> "*shared_imports*": { *[indicates users that all these are shared
> imports]*
> "js": ["vendorName_version/d3.min*.js*", "vendorName_version/vega
> *.js*", "line-chart*.js*"],
> "css": ["vendorName_version/graph*.css*, line-chart*.css*"]
> }
>
> Shouldn't this be other way round? First one should be shared_imports
(fetched from /portal/libs/ ) and second one will be imports (inside chart
template folder)

>
> WDYT? This will make it more generic. So we can avoid restricting to the
> term "chart".
>
>
> Cheers!
> Jerad
>
>
> On Tue, Jun 7, 2016 at 5:49 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> Thank you for your inputs.
>>
>> @ Dakshika :
>> Based on your input following modifications were made.
>>
>> *Chart template structure*
>>
>> └── line-chart
>> ├── api.js
>> ├── config.json
>> ├── chart-libs
>> │   └── vendorName_version
>> │   └── js_css_images_etc_as_same_as_vendor_ships
>> ├── css
>> │   └── line-chart.css
>> └── js
>> └── line-chart.js
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> ├── conf.json
>> ├── gadget-controller.jag
>> ├── gadget.json
>> ├── index.png
>> ├── index.xml
>> ├── chart-libs
>> │   └── vendorName_version
>> │   └── js_css_images_etc_as_same_as_vendor_ships
>> ├── css
>> │   └── line-chart.css
>> └── js
>> ├── core-js
>> │   ├── gadget-core.js
>> │   ├── line-chart-api.js
>> │   └── provider-api.js
>> └── line-chart.js
>>
>>
>> *Folder structure for storing common libs*
>>
>> portal
>>   |── libs
>>
>>   ├── vendorName_version
>>   │   ├── 
>>
>>
>> *Changes to the existing model*
>>
>>- common libs will reside inside portal/libs/
>>
>> *chart config.json*
>>
>> "common": {
>> "js": ["vendorName_version/common"],
>> "css": ["vendorName_version/common"]
>> },
>> "chart": {
>> "js": ["vendorName_version/d3.min", "vendorName_version/vega",
>> "line-chart"],
>> "css": ["vendorName_version/graph, line-chart"]
>> }
>>
>> "common" is for libs fetched from /portal/libs
>> "chart" is for both chart specfic libs inside js folder of chart template
>> and chart-libs that are coming from vendors.
>>
>> So with the change suggested by Dakshika we will have to specify the
>> 

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

On Thu, Jun 9, 2016 at 1:10 AM, Manuranga Perera  wrote:

> 1) We had a chat about how we can use gadget parameters instead of
>>> generation, have you guys considered that approach?
>>>
>>> We have cases like database credentials which should not be shown to the
>> user and should not be editable from the gadget properties. Further we also
>> need a model that gadget should be greeted by some privileged user and used
>> by others, so the gadget generation is the appropriate model to handle
>> this.
>>
>  I thought we can come up with a way to attach permissions to the params,
> so they can be hidden depending on the user. (this will help us generally
> not just for gadget gen case)
>
> Edit/ Re-generate function is not supported yet.
>>>
>>> 2) The issues is, with this model it will be harder to support that even
>>> in the future. At least we should serialize all the parameters with the
>>> generated gadget.
>>>
>> Editing is something we can achieve with very little effort, if we store
>> all the properties that we have passed in the UI in a config file within
>> the gadget then we can simply load that to the gadget generation wizard
>> when we need to modify the gadget.
>>
> Ya, that's what I also meant by serialize. But in that case the UX is
> broken compared to the parameter method, since the user still has to go
> though the wizard again, and you can't see the values from the left panel.
>
As Suho said with this model we store all the user inputs for provider
configuration and chart configuration in a  json file (conf.json), so if
required we can provider an UI option for the *priviledged* users to edit
those properties in the future. So that user doesn't have to go through the
wizard again.

Thanks,
Tanya

>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Sharing Dashboards that have gadgets with role restriction

[Tanya Madurapperuma]

To add into what Megala has explained..

We decided the above approach due to below reasons.

   1. In the gadget listing page of the designer mode, we list only the
   intersection of the gadget that are authorized for the logged in user and
   restricted viewers of that particular view. So if we warn the dashboard
   creator saying "you have added a restricted gadget, if you share or
   planning share this dashboard across tenants, those gadget will be shown to
   the tenant users" at the time of adding a new gadget to the dashboard, he
   will be frustrated if he doesn't want to share this dashboard. So we
   skipped that option.
   2. We decided* only to warn* the user at the time of sharing the
   dashboard rather than hiding those gadgets in tenants view, because say a
   particular gadget is restricted only for Role1 in super tenant. There can
   be a role with the same name in another tenant which serves a different
   purpose. So blindly we can't hide gadgets in tenant mode based on the role
   specified in the gadget.

Thanks,
Tanya

On Thu, Jun 9, 2016 at 10:09 AM, Megala Uthayakumar  wrote:

> Hi All,
>
> We have created a new feature for DS which allows the dashboard created
> from super-tenant to be shared among all the tenants. For more information,
> please refer to documentation at [1]. With the new release we are going to
> introduce fine-grained permission for gadgets. So that, gadgets' access can
> be restricted using roles. In that case, when we share the dashboards
> across tenants the gadgets with role restriction will not be shown as roles
> are limited to each tenant.
>
> But if we think this from the point-of view of the user, who is willing to
> share the dashboard, he/she will expect tenants to have the same level
> functionality in the view mode.In order to solve this problem, we have
> come up with following option.
>
> When a super-tenant user tries to share the dashboard, we will give a
> warning saying, this set of gadgets in this dashboard are restricted to
> these roles. If he/she share the dashboard, then it will be shown to all
> other tenant users regardless of role of the user. Then it is user`s
> decision on whether to share/not to share the dashboard.  WDYT ?
>
> Any comments on this is highly appreciated.
>
> [1]
> https://docs.google.com/a/wso2.com/document/d/1JjB0Ehf6LzJ13krLwN3vo3fLVU4AHQevBtfzN8XqZ70/edit?usp=sharing
>
> Thanks.
>
> Regards,
> Megala
> --
> Megala Uthayakumar
>
> Software Engineer
> Mobile : 0779967122
>



-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Access Level Model For WSO2 Dashboard Server

[Tanya Madurapperuma]

Hi,

On Thu, Jun 9, 2016 at 12:43 PM, Nisala Nanayakkara  wrote:

> Hi Sinthuja,
>
> This email is to clarify several issues regarding this feature. Up-to now
> I have created a four internal roles as above. All these four roles are
> assigned to the user who created the dashboard initially. If we want to
> give specific permission to another user, we can assign appropriate role to
> that user. As an example if we want to give access to the settings page to
> a user, we can assign appropriate role to that user.
>
> But lets think that we have to give access to settings page of dashboard X
> for all the users who have role A. Then how can we achieve that use-case
> here ? Are we going to the add UI configuration in settings page as for
> editor and viewer ? Otherwise we have to go through all the users who have
> role A and assign them with the dashboard X settings role using carbon
> management console.
>
We thought of adding this to the UI because there can be use cases where we
want to give the settings/delete permission to an already existing role in
the LDAP.

> Another suggestion from me, Shall we create a single role called 'owner'
> by merging settings role and delete role as manuranga mentioned ?
>
+1 If a user has delete role, then I don't see any necessity in restricting
him accessing the settings page.

Thanks,
Tanya

>
> Thanks,
> Nisala
>
> On Tue, Jun 7, 2016 at 9:15 PM, Manuranga Perera  wrote:
>
>> If we want to model with the permissions then we should be able to add
>>> the permissions dynamically, but this is not possible with current carbon -
>>> 4.x. And as I have mentioned above, this cannot be included in the global
>>> level as well, because having a settings or delete privileges for dashboard
>>> - X, doesn't mean you have the same privileges for dashboard - Y. And hence
>>> we thought of going with roles approach for this one as well. I agree, the
>>> role names for settings and delete is bit odd, we need to come up with
>>> proper names for those. :)
>>>
>>
>> I think it is possible to dynamically create any permissions via the API
>> even in C4
>>
>> 2) Does "settings" make sense, because if you are an editor, anyway
>>>> you'll have full access to the JSON, don't you?
>>>
>>> In settings you have the full privileges, ie, you can even remove the
>>> user who initially created the dashboard, IMHO it provides the full control
>>> of the dashboard. Designer doesn't have such privileges, he/she can only
>>> add/remove gadgets, pages etc which is related to designing the dashboard.
>>> Therefore we need to have a different role to control the access of the
>>> settings page.
>>
>>
>> We may call this "Owners"?
>>
>> --
>> With regards,
>> *Manu*ranga Perera.
>>
>> phone : 071 7 70 20 50
>> mail : m...@wso2.com
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile:(+94)717600022
> WSO2 Inc., http://wso2.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Sharing Dashboards that have gadgets with role restriction

[Tanya Madurapperuma]

Hi Dilini,

On Fri, Jun 10, 2016 at 9:38 AM, Dilini Gunatilake  wrote:

> Hi Tanya/Megala,
>
> Can't we share the anonymous view with other tenants as a normal view?
>
We have only a dashboard sharing option as per now but not view sharing
option.


> In that case if a particular user gets a waning as you said at the time of
> sharing, the user can create an anonymous view without those restricted
> gadgets and share the dashboard with other tenants. Then, those tenant
> users will be able to view the dashboards as explained in the above doc[1].
> Just an opinion.
>
Also anon view is for any non logged in users and we don't have to
explicitly share it across tenants.

>
> Also, I think hiding gadgets won't work because it will introduce
> unnecessary complications in re-arranging the template. If the restricted
> gadget is in the middle of the template we can't keep a blank space in the
> middle rather re-arrange it in a suitable way.
>
As I have explained in my previous reply,  actual issue here is we are not
aware of the existing roles in each tenant to hide a gadget based on gadget
level permissions.

Thanks,
Tanya

>
> Regards,
> Dilini
>
> On Thu, Jun 9, 2016 at 10:27 AM, Tanya Madurapperuma 
> wrote:
>
>> To add into what Megala has explained..
>>
>> We decided the above approach due to below reasons.
>>
>>1. In the gadget listing page of the designer mode, we list only the
>>intersection of the gadget that are authorized for the logged in user and
>>restricted viewers of that particular view. So if we warn the dashboard
>>creator saying "you have added a restricted gadget, if you share or
>>planning share this dashboard across tenants, those gadget will be shown 
>> to
>>the tenant users" at the time of adding a new gadget to the dashboard, he
>>will be frustrated if he doesn't want to share this dashboard. So we
>>skipped that option.
>>2. We decided* only to warn* the user at the time of sharing the
>>dashboard rather than hiding those gadgets in tenants view, because say a
>>particular gadget is restricted only for Role1 in super tenant. There can
>>be a role with the same name in another tenant which serves a different
>>purpose. So blindly we can't hide gadgets in tenant mode based on the role
>>specified in the gadget.
>>
>> Thanks,
>> Tanya
>>
>> On Thu, Jun 9, 2016 at 10:09 AM, Megala Uthayakumar 
>> wrote:
>>
>>> Hi All,
>>>
>>> We have created a new feature for DS which allows the dashboard created
>>> from super-tenant to be shared among all the tenants. For more information,
>>> please refer to documentation at [1]. With the new release we are going to
>>> introduce fine-grained permission for gadgets. So that, gadgets' access can
>>> be restricted using roles. In that case, when we share the dashboards
>>> across tenants the gadgets with role restriction will not be shown as roles
>>> are limited to each tenant.
>>>
>>> But if we think this from the point-of view of the user, who is willing
>>> to share the dashboard, he/she will expect tenants to have the same level
>>> functionality in the view mode.In order to solve this problem, we have
>>> come up with following option.
>>>
>>> When a super-tenant user tries to share the dashboard, we will give a
>>> warning saying, this set of gadgets in this dashboard are restricted to
>>> these roles. If he/she share the dashboard, then it will be shown to all
>>> other tenant users regardless of role of the user. Then it is user`s
>>> decision on whether to share/not to share the dashboard.  WDYT ?
>>>
>>> Any comments on this is highly appreciated.
>>>
>>> [1]
>>> https://docs.google.com/a/wso2.com/document/d/1JjB0Ehf6LzJ13krLwN3vo3fLVU4AHQevBtfzN8XqZ70/edit?usp=sharing
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Megala
>>> --
>>> Megala Uthayakumar
>>>
>>> Software Engineer
>>> Mobile : 0779967122
>>>
>>
>>
>>
>> --
>> Tanya Madurapperuma
>>
>> Senior Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Dilini GunatilakeSoftware Engineer - QA Team*
> Mobile : +94 (0) 771 162518
> dili...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Maintaining analytics related JS libraries outside carbon-dashboards repository

[Tanya Madurapperuma]

+1  to replace the analytics-wso2_1.0 from the analytics comon repo.
We will maintain a required files from analytics-wso2_1.0 inside
carbon-dashboards just to allow anybody to try out the gadget generation
feature with line-chart sample.

Thanks,
Tanya

On Fri, Jun 10, 2016 at 4:55 PM, Dunith Dhanushka  wrote:

> Hi all,
>
> Gadgets developed for analytics products (E.g ESB, IS,MB, IoTs etc) depend
> on JS libraries which are currently been referred from multiple locations.
>
> For instance
>
> 1. JS utilities common to all gadgets like wso2gadgets.js and
> chart-utils.js (Currently referred from /portal/libs/common-chart-libs)
> 2. JS libraries used by chart template authors (related to gadget wizard).
> E.g VizGrammar, Vega etc (Currently referred from gadget level js folder)
>
> Since above JS libraries do tasks specific to analytics (E.g mostly for
> data visualization), it is better to maintain them in a analytics
> repository like
> carbon-analytics-common. Advantage is that a simple change in those JS
> files will not require a new carbon-dashboards release.
>
> Another issue is when generating a gadget, libraries like VizGrammar are
> packed with each gadget. If there are considerable amount of gadget's
> exist, it is quite difficult to propagate a library change across all
> gadgets.
>
> So as a solution, we came up like this.
>
> 1. There's a feature [1] in carbon-analytics-common to put all analytics
> UX related artifcats such as chart templates and data providers. We can
> have a room for JS files as well.
>
> 2. All analytics related JS files will be maintained inside [1] and
> analytics folks will have total control over them.
>
> 3. When building an analytics product, required analytics JS files will be
> copied to /portal/libs/analytics-wso2_1.0 folder (Can be instructed in
> p2.inf file of feature [1]).
>
> 4. Gadgets generated using wizard will refer JS files from above location
> so that change in one file will be reflected in every generated gadget.
> E.g /portal/libs/analytics-wso2_1.0/VizGrammar.min.js
>
> By this way, carbon-dashboards repo will no longer needing to maintain any
> analytics specific JS files.
>
> @DS Team, @Dakshika can we have your feedback on this please? Suggest a
> naming standard if possible.
>
> [1]
> https://github.com/wso2/carbon-analytics-common/tree/master/features/analytics-gadget-templates
>
> Regards,
>
> Dunith Dhanushka,
> Associate Technical Lead
> WSO2 Inc,
>
> Mobile - +94 71 8615744
> Blog - *https://medium.com/@dunithd <https://medium.com/@dunithd>*
> Twitter - @dunithd <http://twitter.com/dunithd>
>



-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

 the dependency of analytics gadget generation part from
>> the carbon-dashboards repo, and people can have their own providers and
>> chart types, in their repo and they can include that in the build time to
>> get only into their product.
>>
>> Thanks,
>> Sinthuja.
>>
>> Edit/ Re-generate function is not supported yet.
>>>>>
>>>>> 2) The issues is, with this model it will be harder to support that
>>>>> even in the future. At least we should serialize all the parameters with
>>>>> the generated gadget.
>>>>>
>>>> Editing is something we can achieve with very little effort, if we
>>>> store all the properties that we have passed in the UI in a config file
>>>> within the gadget then we can simply load that to the gadget generation
>>>> wizard when we need to modify the gadget.
>>>>
>>> Ya, that's what I also meant by serialize. But in that case the UX is
>>> broken compared to the parameter method, since the user still has to go
>>> though the wizard again, and you can't see the values from the left panel.
>>>
>>> --
>>> With regards,
>>> *Manu*ranga Perera.
>>>
>>> phone : 071 7 70 20 50
>>> mail : m...@wso2.com
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Sinthuja Rajendran*
>> Technical Lead
>> WSO2, Inc.:http://wso2.com
>>
>> Blog: http://sinthu-rajan.blogspot.com/
>> Mobile: +94774273955
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sajith Janaprasad Ariyarathna
> Software Engineer; WSO2, Inc.;  http://wso2.com/
>



-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Maintaining analytics related JS libraries outside carbon-dashboards repository

[Tanya Madurapperuma]

Hi Tharik,

On Fri, Jun 10, 2016 at 5:41 PM, Tharik Kanaka  wrote:

> Hi All,
>
> @Damith
> These are common libs for portal wizard which is common for analytics
> products (analytics-is, analytics-esb, analytics-apim and etc), product-das
> and product-cep. shared-analytics repository was created for analytics
> products, product-das and product-cep does not have dependencies.
>
> @Dunith and others
> On the other hand keeping these in carbon-analytics-common could cause
> maintenance difficulties. For an instance if there is a bug in one of chart
> wizard view,
>
I guess you mean in a vizgrammer js files etc, but not in wizard.

> we need to fix it carbon-analytics-common and release that and then need
> to release all the repositories depending on carbon-analytics-common.
>
You only need to release all the repositories depending on
carbon-analytics-common only if those repo's require that fix immediately.
Otherwise they can upgrade the  carbon-analytics-common version in their
next release.

> This can be resolved if we keep these in some repo like shared-analytics
> and include those features in the products-cep and product-das. Again then
> we need reconsider about the name "shared-analytics" as it has become a
> common repository for products-cep and product-das as well.
>
> Regards,
>
> On Fri, Jun 10, 2016 at 5:13 PM, Damith Wickramasinghe 
> wrote:
>
>> Hi Dunith,
>>
>> +1 . isn't these should go shared-analytics repository since we are using
>> it to hold all common artifacts used in analytics effort.
>>
>> Regards,
>> Damith.
>>
>> On Fri, Jun 10, 2016 at 4:55 PM, Dunith Dhanushka 
>> wrote:
>>
>>> Hi all,
>>>
>>> Gadgets developed for analytics products (E.g ESB, IS,MB, IoTs etc)
>>> depend on JS libraries which are currently been referred from multiple
>>> locations.
>>>
>>> For instance
>>>
>>> 1. JS utilities common to all gadgets like wso2gadgets.js and
>>> chart-utils.js (Currently referred from /portal/libs/common-chart-libs)
>>> 2. JS libraries used by chart template authors (related to gadget
>>> wizard). E.g VizGrammar, Vega etc (Currently referred from gadget level js
>>> folder)
>>>
>>> Since above JS libraries do tasks specific to analytics (E.g mostly for
>>> data visualization), it is better to maintain them in a analytics
>>> repository like
>>> carbon-analytics-common. Advantage is that a simple change in those JS
>>> files will not require a new carbon-dashboards release.
>>>
>>> Another issue is when generating a gadget, libraries like VizGrammar are
>>> packed with each gadget. If there are considerable amount of gadget's
>>> exist, it is quite difficult to propagate a library change across all
>>> gadgets.
>>>
>>> So as a solution, we came up like this.
>>>
>>> 1. There's a feature [1] in carbon-analytics-common to put all analytics
>>> UX related artifcats such as chart templates and data providers. We can
>>> have a room for JS files as well.
>>>
>>> 2. All analytics related JS files will be maintained inside [1] and
>>> analytics folks will have total control over them.
>>>
>>> 3. When building an analytics product, required analytics JS files will
>>> be copied to /portal/libs/analytics-wso2_1.0 folder (Can be instructed in
>>> p2.inf file of feature [1]).
>>>
>>> 4. Gadgets generated using wizard will refer JS files from above
>>> location so that change in one file will be reflected in every generated
>>> gadget.
>>> E.g /portal/libs/analytics-wso2_1.0/VizGrammar.min.js
>>>
>>> By this way, carbon-dashboards repo will no longer needing to maintain
>>> any analytics specific JS files.
>>>
>>> @DS Team, @Dakshika can we have your feedback on this please? Suggest a
>>> naming standard if possible.
>>>
>>> [1]
>>> https://github.com/wso2/carbon-analytics-common/tree/master/features/analytics-gadget-templates
>>>
>>> Regards,
>>>
>>> Dunith Dhanushka,
>>> Associate Technical Lead
>>> WSO2 Inc,
>>>
>>> Mobile - +94 71 8615744
>>> Blog - *https://medium.com/@dunithd <https://medium.com/@dunithd>*
>>> Twitter - @dunithd <http://twitter.com/dunithd>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Software Engineer
>> WSO2 Inc.; http://wso2.com
>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg>
>> lean.enterprise.middleware
>>
>> mobile: *+94728671315 <%2B94728671315>*
>>
>>
>
>
> --
>
> *Tharik Kanaka*
>
> WSO2, Inc |#20, Palm Grove, Colombo 03, Sri Lanka
>
> Email: tha...@wso2.com | Web: www.wso2.com
>



-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [ES] Workflow extensions support - Approval task pages or app ?

[Tanya Madurapperuma]

Hi,

*Overview*
We are currently working on initial design to support workflow extensions
in Enterprise Store as in APIM. Both global workflow extensions (Ex : Self
signup ) and asset level extensions (Ex : Application creation for an API
store ) will be supported.

*Concern*
Once the workflow support is enabled, there should be a place where
different types of tasks will be  listed for an admin user approval. In
APIM, a seperate admin-dashboard app is used for this
purpose.(admin-dashboard app in APIM serves some other tasks such as theme
uploading etc as well. )

Does it require to use a seperate app for this in ES as well? Isn't it
relevant to add these as pages in ES Publisher with appropriate
permissions.Because basically publisher app acts as a store-admin which is
used to perform store releated admin tasks such as publishing assets to
store, viewing statistics etc.

WDYT?

Thanks,
Tanya
-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [ES] Workfow Extension Model

[Tanya Madurapperuma]

Hi all,

As mentioned in a previous mail ( [ES] Workflow extensions support -
Approval task pages or app ? ), we are planning to develop a workflow
extension model for Enterprise strore. Following is the proposed
architecture.

Below diagram explains how the workflow structure fits in to the ES
extension model.


​

*Types of extensions*
As illustrated in the digram, there are two types of workflows.

   - Global worlfows which are common to all types of assets (in blue
   colour)
   - Asset level workflows which are asset specific (in yellow colour)

Both types of workflows can be overided using the ES extension model.
(shown in purple and orange respectively)

*Function Flow*
js file inside each workflow will implement two functions.

   - *execute*
  - contains the BPEL endpoint calling logic
   - *process*
  - handle callback from the endpoint
  - does the actual functionality upon admin approval

Within the actual function where we want to trigger a workflow (Ex : Inside
self sign up function ), a function with the following definition will be
called.

*workflow ( workflow_name, context, function(){*
*  // does the actual implementation (Ex: in self sign up, add the user
into relevant user store)*

* // this is called when workflows are not enabled.*

*})*


If workflows are enabled, inside the *workflow* function, perform the
validations of the workflow and call *execute* method of the relevant
workflow.
If workflows are not enabled, function passed into the *workflow* function
will be called.

*execute *function should return an object in the following (standard)
format so that page rendering that depends on workflow enabled/disabled can
be easily handled.

{
 metadata :
 data :
 status :
 message :
}


Appreciate any feedback regarding the above model.

Thanks,
Tanya


-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [ES] Workflow extensions support - Approval task pages or app ?

[Tanya Madurapperuma]

Thank you all for the suggestions.

On Thu, Oct 16, 2014 at 4:23 PM, Manoj Gunawardena  wrote:

> Hi All,
>
> +1 for Johan's opinion. My suggstion is develop as Jaggery web app and
> implement as carbon feature. Publisher ship with this feature and admin
> pages can navigate through publisher. But this new admin app will be
> available to integrate with any other app as feature.
>

AFAIK still there is no way to install a jaggery app as a carbon feature.
What happens is, new jaggery app will get copied under jaggeryapps. If
required we can provide navigation from publisher app to admin app checking
permissions. In that case we have to enable SSO between the 2 apps.

>
>
> Thanks
>
> On Thu, Oct 16, 2014 at 3:41 PM, Johann Nallathamby 
> wrote:
>
>>
>>
>> On Wed, Oct 15, 2014 at 1:19 PM, Manoj Gunawardena 
>> wrote:
>>
>>> Hi,
>>>
>>> +1 for develop as separate app and more clean and logical way . But I
>>> think user point of view, its more applicable to view and function with in
>>> publisher. Cant we implement as separate Jaggery app and included to
>>> publisher as a carbon feature.  Then this workflow support app is available
>>> as a feature to distribute with any other app.
>>>
>>>
>>> Thanks
>>>
>>> On Wed, Oct 15, 2014 at 9:47 AM, Nuwan Dias  wrote:
>>>
>>>> There can be workflows for both the Publisher and the Store. Therefore
>>>> having a single place to administer both sounds appropriate and easy to
>>>> manage.
>>>>
>>>> At least in the context of API Manager, having a page on the Publisher
>>>> to administer operations occurring on the Store doesn't seem right.
>>>>
>>>> IMO having an app for administrative purposes seems logical/clean and
>>>> more secure (you can take it off completely from public facing interfaces
>>>> and deploy internally if required). Even in the case of ES, you can use it
>>>> for workflow administration, theming, doing import/export asset kind of
>>>> stuff, etc.
>>>>
>>>> Thanks,
>>>> NuwanD.
>>>>
>>>> On Wed, Oct 15, 2014 at 9:28 AM, Tanya Madurapperuma 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> *Overview*
>>>>> We are currently working on initial design to support workflow
>>>>> extensions in Enterprise Store as in APIM. Both global workflow extensions
>>>>> (Ex : Self signup ) and asset level extensions (Ex : Application creation
>>>>> for an API store ) will be supported.
>>>>>
>>>>> *Concern*
>>>>> Once the workflow support is enabled, there should be a place where
>>>>> different types of tasks will be  listed for an admin user approval. In
>>>>> APIM, a seperate admin-dashboard app is used for this
>>>>> purpose.(admin-dashboard app in APIM serves some other tasks such as theme
>>>>> uploading etc as well. )
>>>>>
>>>>> Does it require to use a seperate app for this in ES as well? Isn't it
>>>>> relevant to add these as pages in ES Publisher with appropriate
>>>>> permissions.Because basically publisher app acts as a store-admin which is
>>>>> used to perform store releated admin tasks such as publishing assets to
>>>>> store, viewing statistics etc.
>>>>>
>>>>
>> Not in all cases can we say the publisher app is admin related. There can
>> be external facing publisher deployments where users will come and publish
>> their artifacts (e.g. external users with publisher role come and publish
>> APIs in API publisher). In that case having workflow integration in
>> publisher app doesn't seem correct.
>>
>> +1 for separate app if you don't have an existing admin related app.
>>
>>>
>>>>> WDYT?
>>>>>
>>>>> Thanks,
>>>>> Tanya
>>>>> --
>>>>> Tanya Madurapperuma
>>>>>
>>>>> Software Engineer,
>>>>> WSO2 Inc. : wso2.com
>>>>> Mobile : +94718184439
>>>>> Blog : http://tanyamadurapperuma.blogspot.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nuwan Dias
>>>>
>>>> Associate Tech Lead - WSO2, Inc. http://wso2.com
>>>> email : nuw...@wso2.com
>>>> Phone : +9

Re: [Architecture] RFC: Building a Generic Configurable UI Gadget for Analytics

[Tanya Madurapperuma]

Hi all,

With the current implementation of UES gadget gen tool we can support all
the features except the drill down feature. Please note that this is using
the flot charting library and if we are to go ahead with D3 we need to
model accordingly.
Please find my inline comments.

On Mon, Dec 8, 2014 at 12:12 PM, Srinath Perera  wrote:
>
> Currently to visualize the data, users have to write their own gadgets. If
> a advanced user this is OK, but not for all. Specially, things like drill
> downs need complicated planning.
>
> I believe it is possible to start with data in tabular form, and write a
> generic Gadget that let user configure and create his own data chart with
> filters and drill downs.
>
> Chart could look like following ( some of the controls can be hidden under
> configure button)
>
> ​
> Lets work though an example.
>
> 1) Key idea is that we load data to the Gadget as a table (always).
> Following can be a example data.
> *Country* *Year* *GDP* *Population* *LifeExpect*  Sri Lanka 2004 20
> 19435000 73  Sri Lanka 2005 24 19644000 73  Sri Lanka 2006 28 19858000 73  Sri
> Lanka 2007 32 20039000 73
> 2) When Gadget is loaded, it shows the data as a table. User can select
> and add a data type and fields.  Following are some example.
>
>1. Line - two Numerical  fields
>2. Bar - one numerical, one categorical field
>3. Scatter - two numerical fields
>4. Map - Location field + categorical or numerical field
>5. Graph - two categorical or string fields that provide links
>
> At the moment we can give an SQL query and choose columns from the
provided dataset depending on the chart type.

>
> 3) Let user add more information to the chart using other fields in the
> table
>
>1. Add  color (Categorical field) or shade (numerical field) to the
>plot (e.g. Use different color for each country)
>2. Point Size - Numerical field (e.g. Adjust the point size in the
>scatter plot according to the population)
>3. Label - any field
>
> If I take the same example that you have taken, all these filters will
work if you generate a multiple series bubble chart.
Multiple series - each country will be a different series on
the same chart.
Size of the bubble - will be the population.
User has to identify the suitable chart type for his visualization and can
generate accordingly.


> 4) Then he can add filters based on a variable. Then the chart will have
> sliders (for numerical data) and tick buttons (for categorical data). When
> those sliders are changed they will change the chart.
>

Categorical support over tick button is already there for different series.
Although slider feature doesn't come with the gadget gen tool, this can be
implemeted using pub-sub model where we can extend the gadget gen tool to
integrate with the model. We have done a similar one (not auto generated)
for App factory.

>
> 5) Final step is define drill downs. Drill downs are done using two
> columns in the table that has hierarchical relationships. (e.g. Country and
> State fields, Year and month fields) . We need users to select two of those
> fields and tell us about relationships and then we can code the support of
> drill downs.
>

At the moment we don't have this feature. +1 to add to the roadmap.

>
> When above steps are done, user save configs and save it in the DataViz
> store as a visualisation, so others can pull it and use it.
>
> This will not cover all cases, but IMO it will cover 80% and also a very
> good tool for demos etc.
>
> Please comment
>
> --Srinath
>
>
>
> --
> 
> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
> Site: http://people.apache.org/~hemapani/
> Photos: http://www.flickr.com/photos/hemapani/
> Phone: 0772360902
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>

-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] email server for test framework

[Tanya Madurapperuma]

We are already using Green mail in jaggery email host object test cases.
[1][2]. We also have discussed about this in a previous mail thread.

+1 to go with Green Mail.

[1]
https://github.com/wso2/jaggery/blob/4d539fd3aed71a601c4788bcda691de7f0b039e0/server/integration/src/test/java/org/wso2/jaggery/integration/tests/hostObjects/community/EmailHostObjectTestCase.java
[2]
https://github.com/wso2/jaggery/blob/master/server/integration/src/test/resources/email.jag

Thanks,
Tanya

On Tue, Dec 23, 2014 at 4:35 AM, Manuranga Perera  wrote:

> I have used https://nilhcem.github.io/FakeSMTP/ before for some testing,
> it works well.
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Generic workflow executor across the platform

[Tanya Madurapperuma]

Hi all,

We are in the process of implementing the workflow support for ES and came
across the $Subject.
Although many products have worflow support, seems there is no generic
component to achieve this.

The workflow executor for APIM [1] cannot be used platform wide since they
pass the ApiMgtDAO to execute method in their executor.

Similar issue is there with the IS workflow executor where they preserve
the workflow information in the identity database [2] (refer
addWorkflowEntry method)

IMO other products should be able to use their own workflow info
preservation mechanism.
Ex: To store in the registry
   To store in a database
Say in ES, we want to provide workflow support for asset creation. Storing
asset level info in Identity database doesn't make sense.

Appreciate your feedback.

[1]
https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/workflow/WorkflowExecutor.java
[2]
https://github.com/pulasthi7/carbon-identity/blob/feature/workflow-support/components/workflows/org.wso2.carbon.workflow.mgt/src/main/java/org/wso2/carbon/workflow/mgt/dao/WorkflowRequestDAO.java

Thanks,
Tanya

-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generic workflow executor across the platform

[Tanya Madurapperuma]

Hi Johann,

Thanks for the response.
IMO it is better if we can make the WorkflowRequestDAO more generic where
we can plug any storing mechanism. WDYT?

Thanks,
Tanya

On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby  wrote:

> Hi Tanya,
>
> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> We are in the process of implementing the workflow support for ES and
>> came across the $Subject.
>> Although many products have worflow support, seems there is no generic
>> component to achieve this.
>>
>> The workflow executor for APIM [1] cannot be used platform wide since
>> they pass the ApiMgtDAO to execute method in their executor.
>>
>> Similar issue is there with the IS workflow executor where they preserve
>> the workflow information in the identity database [2] (refer
>> addWorkflowEntry method)
>>
>
> The work flow component that was designed for IS was designed with the
> intension of extensibility. The workflow components are not coupled in
> anyway to identity components. If there is anything which is blocking you
> from achieving what you need then we will like to know about it so that we
> can fix our design.
>
>
>> IMO other products should be able to use their own workflow info
>> preservation mechanism.
>> Ex: To store in the registry
>>To store in a database
>> Say in ES, we want to provide workflow support for asset creation.
>> Storing asset level info in Identity database doesn't make sense.
>>
>
> Don't think of it as Identity database. Think of it as a database coming
> from another feature repository. It can be any product like IS. If the same
> workflow component was developed by APIM then it would be AM_ tables. Apart
> from the naming convention the functionality is generic and extensible. The
> table naming convention comes from which product team develops it, thats
> all.
>
> Using Identity database in ES is not wrong. If you are installing IS
> feature you have to install the database scripts also. I know previously
> APIM did the same mistake of copying the identity tables into apim scripts
> and not executing identity scripts. I know how much duplication it made and
> how much of problems we ran into. I am -1 on that.
>
> If you have a strong reason to move away from database, and use registry
> then we need to think about making the data access layer extensible, which
> is open for discussion.
>
> P.S. I know we haven't sent a mail to architecture regarding the workflow
> component design. Will do soon.
>
> Regards,
> Johann.
>
>>
>> Appreciate your feedback.
>>
>> [1]
>> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/workflow/WorkflowExecutor.java
>> [2]
>> https://github.com/pulasthi7/carbon-identity/blob/feature/workflow-support/components/workflows/org.wso2.carbon.workflow.mgt/src/main/java/org/wso2/carbon/workflow/mgt/dao/WorkflowRequestDAO.java
>>
>> Thanks,
>> Tanya
>>
>> --
>> Tanya Madurapperuma
>>
>> Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Associate Technical Lead & Product Lead of WSO2 Identity Server
> Integration Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>



-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generic workflow executor across the platform

[Tanya Madurapperuma]

Hi Johann and all,

As per the offline chat with Pulasthi, the executor serialize the workflow
info and save in the database before calling the bpel service. (see the
diagram below)


​So in our case if we are to use this component, we will have to do a
network call with all the information for the workflow request (might
include large files such as images and videos etc as admin needs to approve
them)
Also at the call back we have to resend the same info back.

We thought it would be more convienient and performance friendly, if we
persist those information at our end and provide an endpoint where the
admin can access all the information.

For an example, say asset creation process.
Once the user fills the asset creation form, we will persist that info in a
database with a flag so that it won't be visible in the store to the other
users. And when triggering the workflow we send an endpoint with a token
and admin can view the created asset info with that endpoint. Admin will be
redirected to store to display the newly created (pending) asset. With that
we don't need to worry about sending/rendering images at the workflow admin
application.

WDYT?

Thanks,
Tanya

On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma  wrote:

> Hi Johann,
>
> Thanks for the response.
> IMO it is better if we can make the WorkflowRequestDAO more generic where
> we can plug any storing mechanism. WDYT?
>
> Thanks,
> Tanya
>
> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby 
> wrote:
>
>> Hi Tanya,
>>
>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are in the process of implementing the workflow support for ES and
>>> came across the $Subject.
>>> Although many products have worflow support, seems there is no generic
>>> component to achieve this.
>>>
>>> The workflow executor for APIM [1] cannot be used platform wide since
>>> they pass the ApiMgtDAO to execute method in their executor.
>>>
>>> Similar issue is there with the IS workflow executor where they preserve
>>> the workflow information in the identity database [2] (refer
>>> addWorkflowEntry method)
>>>
>>
>> The work flow component that was designed for IS was designed with the
>> intension of extensibility. The workflow components are not coupled in
>> anyway to identity components. If there is anything which is blocking you
>> from achieving what you need then we will like to know about it so that we
>> can fix our design.
>>
>>
>>> IMO other products should be able to use their own workflow info
>>> preservation mechanism.
>>> Ex: To store in the registry
>>>To store in a database
>>> Say in ES, we want to provide workflow support for asset creation.
>>> Storing asset level info in Identity database doesn't make sense.
>>>
>>
>> Don't think of it as Identity database. Think of it as a database coming
>> from another feature repository. It can be any product like IS. If the same
>> workflow component was developed by APIM then it would be AM_ tables. Apart
>> from the naming convention the functionality is generic and extensible. The
>> table naming convention comes from which product team develops it, thats
>> all.
>>
>> Using Identity database in ES is not wrong. If you are installing IS
>> feature you have to install the database scripts also. I know previously
>> APIM did the same mistake of copying the identity tables into apim scripts
>> and not executing identity scripts. I know how much duplication it made and
>> how much of problems we ran into. I am -1 on that.
>>
>> If you have a strong reason to move away from database, and use registry
>> then we need to think about making the data access layer extensible, which
>> is open for discussion.
>>
>> P.S. I know we haven't sent a mail to architecture regarding the workflow
>> component design. Will do soon.
>>
>> Regards,
>> Johann.
>>
>>>
>>> Appreciate your feedback.
>>>
>>> [1]
>>> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/workflow/WorkflowExecutor.java
>>> [2]
>>> https://github.com/pulasthi7/carbon-identity/blob/feature/workflow-support/components/workflows/org.wso2.carbon.workflow.mgt/src/main/java/org/wso2/carbon/workflow/mgt/dao/WorkflowRequestDAO.java
>>>
>>> Thanks,
>>> Tanya
>>>
>>> --
>>> Tanya Madurapperuma
>>>
>>> Software Engineer,
>>> WS

[Architecture] [Notes] Meeting Notes of Enterprise Store M3 Review - 14 th Aug

[Tanya Madurapperuma]

Hi all,

Please find the Enterprise store M3 review meeting notes below.


Participants - Sanjiva, Samisa, Dimuthu (App fac),  NuwanD (API-M team),
Shan, Chan (Mobile team), and Store team


*General*

   1.

   RXT's will have a special field "type", which should be shown as
   categories in UI
   2.

   Use a database to store pdfs/ thumbnails/gadget XMLs and  etc


*Publisher*

   1.

   Provider field - browse the user-base and auto fill / can be either a
   role or a user
   2.

   Status field - progress through a (BPEL) workflow


   -

   Have 2 life cycles as human approval workflow (possibly with checklists)
   andautomated approval(non approval)
   -

   promote/demote from states


   1.

   Cross tenant publihing is not needed and have a public store and private
   stores


 *Store*

   1.

   search by tags needs to be implemented.
   2.

   UI for asset types should be more prominent.


   -

   It should be something like

   Apps → My apps → My devices (shows only the apps that can be installed
   for that particular device)
   -

   Instead of having all “My Assets” in one page, have individual pages for
   each asset type.




   1.

   Show some real gadgets than templates, and rename existing gadgets in to
   a new type.


   Please add if I have missed anything.

   Thanks,

   Tanya.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Dev] WSO2 Enterprise Store 1.0.0 Milestone-5 Released !

[Tanya Madurapperuma]

WSO2 Enterprise Store 1.0.0 Milestone-5 Released !

This is the fifth milestone of WSO2 Enterprise Store, which will create a
marketplace for your enterprise assets. You can download the milestone at
[1]. Milestone-5 specifically contains following bug fixes, improvements,
features and tasks.

*Bug*

   - [STORE-40 ] - Asset creation
   requires the user role to have permissions to write to an asset path
   - [STORE-43 ] - The Publisher
   Promote/Demote operations at edge cases will freeze asset in a specific
   state
   - [STORE-45 ] - Publisher items
   need to have correct thumbnail
   - [STORE-47 ] - Add new asset
   need to be "add new {gadget/site/book}" asset type sensitive


*Improvement*

   - [STORE-50 ] - Store search bar
   need to be fixed, the downward arrow is not aligned


*New Feature*

   - [STORE-44 ] - Add asset type
   :Book (Books store)


*Task*

   - [STORE-7 ] - Presentation of
   categories in the store
   - [STORE-18 ] - Manage/change
   life-cycle of an asset
   - [STORE-24 ] - SSO between
   admin/back-office/store-front
   - [STORE-41 ] - Search by tags
   needs to be implemented




The milestone-5 of WSO2 Enterprise Store is in its early stages, you will
encounter number of bugs and feature limitations, we are working on
improving these in future milestones.

Product road-map can be found at [4] and issues can be reported at [5].


[1] http://dist.wso2.org/milestone/es/1.0.0-M5/wso2store-1.0.0.zip
[2] Store Front URL : http://{host}:{9763}/store
[3] Store Back-office (Publisher) : http://{host}:{9763}/publisher
[4] Store Roadmap :
https://wso2.org/jira/browse/STORE#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
[5] https://wso2.org/jira/browse/STORE

Thank you.
-- 
*WSO2 Enterprise Store Team*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Meeting Notes] UES integration with BAM / CEP / APIM

[Tanya Madurapperuma]

Hi all,

Following is the meeting notes of the $Subject.

Participants : Anjana, Gokul, Mohan, Lasantha, SameeraP, Shiro, Lalaji,
Joe, Chan, Gillian (over the phone), UES team

BAM
=
1. Some tool simialar to Gadget gen tool will developed in UES side and
there will be a url from carbon console for the gadget gen tool
2. User can give the database query in the tool and get the data and then
pass it to the UES gadgets

CEP
=
1. Events are published to BAM ---> create datasources---> create
gadget---> publish to store ---> create dashboard
2. Reuse the suggested gadget gen tool

APIM
=
1. Required predefined dashboard for subscribers with same set of gadgets
therefore APIM does not have a requirment of creating customizable
dashboards.

Future items
==

1. Personalization of dashboards - allowing whether user's changes to be
overriden by admin's chnages?
2. multi-tenancy in ues

Please add if I have missed anything.

Thanks,
Tanya.

-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Meeting Notes] UES integration with BAM / CEP / APIM

[Tanya Madurapperuma]

On Tue, Nov 12, 2013 at 3:24 PM, Isabelle Mauny  wrote:

> For APIM, we need consumer dashboards as well.
>

Isabelle,
Consumer dashboards are static dashboards that we can ship with APIM. Right
? IS there a need for consumers to go ahead and create dashboards
themselves containing their preferred gadgets and layouts ? Dashboards that
we discussed here are of that nature which will be created by the user
himself.



> Isabelle.
> __
>
>
> *Isabelle Mauny*Director, Product Management; WSO2, Inc.;
> http://wso2.com/
>
> On Nov 12, 2013, at 10:52 AM, Tanya Madurapperuma  wrote:
>
> Hi all,
>
> Following is the meeting notes of the $Subject.
>
> Participants : Anjana, Gokul, Mohan, Lasantha, SameeraP, Shiro, Lalaji,
> Joe, Chan, Gillian (over the phone), UES team
>
> BAM
> =
> 1. Some tool simialar to Gadget gen tool will developed in UES side and
> there will be a url from carbon console for the gadget gen tool
> 2. User can give the database query in the tool and get the data and then
> pass it to the UES gadgets
>
> CEP
> =
> 1. Events are published to BAM ---> create datasources---> create
> gadget---> publish to store ---> create dashboard
> 2. Reuse the suggested gadget gen tool
>
> APIM
> =
> 1. Required predefined dashboard for subscribers with same set of gadgets
> therefore APIM does not have a requirment of creating customizable
> dashboards.
>
> Future items
> ==
>
> 1. Personalization of dashboards - allowing whether user's changes to be
> overriden by admin's chnages?
> 2. multi-tenancy in ues
>
> Please add if I have missed anything.
>
> Thanks,
> Tanya.
>
> --
> Tanya Madurapperuma
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94718184439
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Meeting Notes] UES integration with BAM / CEP / APIM

[Tanya Madurapperuma]

On Tue, Nov 12, 2013 at 3:50 PM, Isabelle Mauny  wrote:

> Sure - These are static dashboards. But a user must be able to create
> their own dashboards , on top on the ones we are delivering by default. In
> this case, they would create their own toolbox , leveraging the gadgetgen
> tool you discussed right?
>

 Yes. If users need to create their own dashboards, then APIM can reuse the
described gadget-gen tool.

>
> Thanks.
>
>
>
> --
> Isabelle Mauny
> Director, Product Management; WSO2, Inc.;  http://wso2.com/
> email: isabe...@wso2.com  - mobile: +34 616050684
>
>
> On Tue, Nov 12, 2013 at 11:10 AM, Tanya Madurapperuma wrote:
>
>>
>>
>>
>> On Tue, Nov 12, 2013 at 3:24 PM, Isabelle Mauny wrote:
>>
>>> For APIM, we need consumer dashboards as well.
>>>
>>
>> Isabelle,
>> Consumer dashboards are static dashboards that we can ship with APIM.
>> Right ? IS there a need for consumers to go ahead and create dashboards
>> themselves containing their preferred gadgets and layouts ? Dashboards that
>> we discussed here are of that nature which will be created by the user
>> himself.
>>
>>
>>
>>> Isabelle.
>>>  ______
>>>
>>>
>>> *Isabelle Mauny *Director, Product Management; WSO2, Inc.;
>>> http://wso2.com/
>>>
>>> On Nov 12, 2013, at 10:52 AM, Tanya Madurapperuma 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> Following is the meeting notes of the $Subject.
>>>
>>> Participants : Anjana, Gokul, Mohan, Lasantha, SameeraP, Shiro, Lalaji,
>>> Joe, Chan, Gillian (over the phone), UES team
>>>
>>> BAM
>>> =
>>> 1. Some tool simialar to Gadget gen tool will developed in UES side and
>>> there will be a url from carbon console for the gadget gen tool
>>> 2. User can give the database query in the tool and get the data and
>>> then pass it to the UES gadgets
>>>
>>> CEP
>>> =
>>> 1. Events are published to BAM ---> create datasources---> create
>>> gadget---> publish to store ---> create dashboard
>>> 2. Reuse the suggested gadget gen tool
>>>
>>> APIM
>>> =
>>> 1. Required predefined dashboard for subscribers with same set of
>>> gadgets therefore APIM does not have a requirment of creating customizable
>>> dashboards.
>>>
>>> Future items
>>> ==
>>>
>>> 1. Personalization of dashboards - allowing whether user's changes to be
>>> overriden by admin's chnages?
>>> 2. multi-tenancy in ues
>>>
>>> Please add if I have missed anything.
>>>
>>> Thanks,
>>> Tanya.
>>>
>>> --
>>> Tanya Madurapperuma
>>>
>>> Software Engineer,
>>> WSO2 Inc. : wso2.com
>>> Mobile : +94718184439
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Tanya Madurapperuma
>>
>> Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Meeting Notes] UES integration with BAM / CEP / APIM

[Tanya Madurapperuma]

On Tue, Nov 12, 2013 at 4:03 PM, Lasantha Fernando wrote:

> Hi Tanya,
>
>
> On 12 November 2013 15:50, Isabelle Mauny  wrote:
>
>> Sure - These are static dashboards. But a user must be able to create
>> their own dashboards , on top on the ones we are delivering by default. In
>> this case, they would create their own toolbox , leveraging the gadgetgen
>> tool you discussed right?
>>
>> Thanks.
>>
>>
>>
>> --
>> Isabelle Mauny
>> Director, Product Management; WSO2, Inc.;  http://wso2.com/
>> email: isabe...@wso2.com  - mobile: +34 616050684
>>
>>
>> On Tue, Nov 12, 2013 at 11:10 AM, Tanya Madurapperuma wrote:
>>
>>>
>>>
>>>
>>> On Tue, Nov 12, 2013 at 3:24 PM, Isabelle Mauny wrote:
>>>
>>>> For APIM, we need consumer dashboards as well.
>>>>
>>>
>>> Isabelle,
>>> Consumer dashboards are static dashboards that we can ship with APIM.
>>> Right ? IS there a need for consumers to go ahead and create dashboards
>>> themselves containing their preferred gadgets and layouts ? Dashboards that
>>> we discussed here are of that nature which will be created by the user
>>> himself.
>>>
>>>
>>>
>>>> Isabelle.
>>>>  __
>>>>
>>>>
>>>> *Isabelle Mauny *Director, Product Management; WSO2, Inc.;
>>>> http://wso2.com/
>>>>
>>>> On Nov 12, 2013, at 10:52 AM, Tanya Madurapperuma 
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Following is the meeting notes of the $Subject.
>>>>
>>>> Participants : Anjana, Gokul, Mohan, Lasantha, SameeraP, Shiro, Lalaji,
>>>> Joe, Chan, Gillian (over the phone), UES team
>>>>
>>>> BAM
>>>> =
>>>> 1. Some tool simialar to Gadget gen tool will developed in UES side and
>>>> there will be a url from carbon console for the gadget gen tool
>>>> 2. User can give the database query in the tool and get the data and
>>>> then pass it to the UES gadgets
>>>>
>>>> CEP
>>>> =
>>>> 1. Events are published to BAM ---> create datasources---> create
>>>> gadget---> publish to store ---> create dashboard
>>>> 2. Reuse the suggested gadget gen tool
>>>>
>>>> For CEP usecase, it would be something like
>
> Events are published to a datasource such as cassandra(or web socket or
> some subset of output adaptors supported by CEP) and a gadget will be
> genarated accordingly -> publish to store -> create dashboard.
>
> Guess that is what you meant above..?
>

Yes. Thanks for correcting it.

>
>>>> APIM
>>>> =
>>>> 1. Required predefined dashboard for subscribers with same set of
>>>> gadgets therefore APIM does not have a requirment of creating customizable
>>>> dashboards.
>>>>
>>>> Future items
>>>> ==
>>>>
>>>> 1. Personalization of dashboards - allowing whether user's changes to
>>>> be overriden by admin's chnages?
>>>> 2. multi-tenancy in ues
>>>>
>>>> Please add if I have missed anything.
>>>>
>>>> Thanks,
>>>> Tanya.
>>>>
>>>> Thanks,
> Lasantha
>
>>
>>>> --
>>>> Tanya Madurapperuma
>>>>
>>>> Software Engineer,
>>>> WSO2 Inc. : wso2.com
>>>> Mobile : +94718184439
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Tanya Madurapperuma
>>>
>>> Software Engineer,
>>> WSO2 Inc. : wso2.com
>>> Mobile : +94718184439
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Lasantha Fernando*
> Software Engineer - Data Technologies Team
> WSO2 Inc. http://wso2.com
>
> email: lasan...@wso2.com
> mobile: (+94) 71 5247551
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Meeting Notes] UES integration with BAM / CEP / APIM

[Tanya Madurapperuma]

On Wed, Nov 13, 2013 at 10:53 AM, Subash Chaturanga  wrote:

>
> On Tue, Nov 12, 2013 at 8:19 PM, Sriskandarajah Suhothayan 
> wrote:
>
>> Just a suggestion. I would like this gadget gen tool to take a template
>> gadget and a conf file as the input, ask to enter the UI options based on
>> the conf and generate the gadget based on the template gadget file.
>> Whereby we can support many types of gadgets.
>> This is impingement because in the current BAM gadget gen tool we are
>> only restricted to two gadget .
>>
> +1 . Even though we have the flexibility to write our own tbox,  even for
> BAM, it will be more like awesome if the gadgets have more flexibility. Not
> sure about the level of complexity that comes out when given a template
> gadget to configure. It will surely be better than writing our own jag ;-).
>

Hi Suho and Subash,
Do you suggest to ship some default gadget templates ( ex: for bar
chart, line chart and etc ) with the tool which user can select and then
ask the user to give a conf file and then generate the gadget? Or else does
the user himself provides the gadget template as well?

>
>
>
>> Regards
>> Suho
>> On Nov 12, 2013 2:46 AM, "Tanya Madurapperuma"  wrote:
>>
>>>
>>>
>>>
>>> On Tue, Nov 12, 2013 at 4:03 PM, Lasantha Fernando wrote:
>>>
>>>> Hi Tanya,
>>>>
>>>>
>>>> On 12 November 2013 15:50, Isabelle Mauny  wrote:
>>>>
>>>>> Sure - These are static dashboards. But a user must be able to create
>>>>> their own dashboards , on top on the ones we are delivering by default. In
>>>>> this case, they would create their own toolbox , leveraging the gadgetgen
>>>>> tool you discussed right?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Isabelle Mauny
>>>>> Director, Product Management; WSO2, Inc.;  http://wso2.com/
>>>>> email: isabe...@wso2.com  - mobile: +34 616050684
>>>>>
>>>>>
>>>>> On Tue, Nov 12, 2013 at 11:10 AM, Tanya Madurapperuma 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 12, 2013 at 3:24 PM, Isabelle Mauny wrote:
>>>>>>
>>>>>>> For APIM, we need consumer dashboards as well.
>>>>>>>
>>>>>>
>>>>>> Isabelle,
>>>>>> Consumer dashboards are static dashboards that we can ship with APIM.
>>>>>> Right ? IS there a need for consumers to go ahead and create dashboards
>>>>>> themselves containing their preferred gadgets and layouts ? Dashboards 
>>>>>> that
>>>>>> we discussed here are of that nature which will be created by the user
>>>>>> himself.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Isabelle.
>>>>>>>  __
>>>>>>>
>>>>>>>
>>>>>>> *Isabelle Mauny *Director, Product Management; WSO2, Inc.;
>>>>>>> http://wso2.com/
>>>>>>>
>>>>>>> On Nov 12, 2013, at 10:52 AM, Tanya Madurapperuma 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Following is the meeting notes of the $Subject.
>>>>>>>
>>>>>>> Participants : Anjana, Gokul, Mohan, Lasantha, SameeraP, Shiro,
>>>>>>> Lalaji, Joe, Chan, Gillian (over the phone), UES team
>>>>>>>
>>>>>>> BAM
>>>>>>> =
>>>>>>> 1. Some tool simialar to Gadget gen tool will developed in UES side
>>>>>>> and there will be a url from carbon console for the gadget gen tool
>>>>>>> 2. User can give the database query in the tool and get the data and
>>>>>>> then pass it to the UES gadgets
>>>>>>>
>>>>>>> CEP
>>>>>>> =
>>>>>>> 1. Events are published to BAM ---> create datasources---> create
>>>>>>> gadget---> publish to store ---> create dashboard
>>>>>>> 2. Reuse the suggested gadget gen tool
>>>>>>>
>>>>&

Re: [Architecture] [Appfactory] Improving the scalability of the dasboards

[Tanya Madurapperuma]

t;>>>>>> http://wso2.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 21, 2013 at 12:07 AM, Gayan Dhanushka 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Ramith,
>>>>>>>>
>>>>>>>> To march towards that is one thing. As I have mentioned that is one
>>>>>>>> of the things that we can do.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> GayanD
>>>>>>>>
>>>>>>>> Gayan Dhanuska
>>>>>>>> Software Engineer
>>>>>>>> http://wso2.com/
>>>>>>>> Lean Enterprise Middleware
>>>>>>>>
>>>>>>>> Mobile
>>>>>>>> 071 666 2327
>>>>>>>>
>>>>>>>> Office
>>>>>>>> Tel   : 94 11 214 5345
>>>>>>>>  Fax  : 94 11 214 5300
>>>>>>>>
>>>>>>>> Twitter : https://twitter.com/gayanlggd
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Nov 20, 2013 at 7:32 PM, Ramith Jayasinghe >>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> 1. Well can we cater to the usecase where CEO wants to see top
>>>>>>>>> applications while he wants to keep an eye on thus  this "up and 
>>>>>>>>> coming"
>>>>>>>>> special application(s) which doesnt make the "top" list?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wednesday, November 20, 2013, Gayan Dhanushka wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> There are a few ideas and concerns over providing scalable
>>>>>>>>>> dashbaords.
>>>>>>>>>>
>>>>>>>>>> 1) Either we can visualize all the data across all the
>>>>>>>>>> applications or provide a set of predefined data (e.g. top 10 
>>>>>>>>>> applications
>>>>>>>>>> having most number of users) or we can give the flexibility to the 
>>>>>>>>>> CXO to
>>>>>>>>>> choose the set of applications he is interested in to view data on 
>>>>>>>>>> the
>>>>>>>>>> dashboard via user prefs.
>>>>>>>>>>
>>>>>>>>>> 2) Either we can use the existing charts with user prefs or we
>>>>>>>>>> can go for an entirely different visualization mechanism (e.g 
>>>>>>>>>> heatmap,
>>>>>>>>>> treemap) since these capture all the data on a single view.
>>>>>>>>>>
>>>>>>>>>> What are your thoughts?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>> GayanD
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Gayan Dhanuska
>>>>>>>>>> Software Engineer
>>>>>>>>>> http://wso2.com/
>>>>>>>>>> Lean Enterprise Middleware
>>>>>>>>>>
>>>>>>>>>> Mobile
>>>>>>>>>> 071 666 2327
>>>>>>>>>>
>>>>>>>>>> Office
>>>>>>>>>> Tel   : 94 11 214 5345
>>>>>>>>>> Fax  : 94 11 214 5300
>>>>>>>>>>
>>>>>>>>>> Twitter : https://twitter.com/gayanlggd
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ramith Jayasinghe
>>>>>>>>> Technical Lead
>>>>>>>>> WSO2 Inc., http://wso2.com
>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>
>>>>>>>>> E: ram...@wso2.com
>>>>>>>>> P: +94 776715671
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ___
>>>>>>>> Architecture mailing list
>>>>>>>> Architecture@wso2.org
>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ___
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dimuthu Leelarathne
>>>>> Architect & Product Lead of App Factory
>>>>>
>>>>> WSO2, Inc. (http://wso2.com)
>>>>> email: dimut...@wso2.com
>>>>> Mobile : 0773661935
>>>>>
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Dimuthu Leelarathne
>>>> Architect & Product Lead of App Factory
>>>>
>>>> WSO2, Inc. (http://wso2.com)
>>>> email: dimut...@wso2.com
>>>> Mobile : 0773661935
>>>>
>>>> Lean . Enterprise . Middleware
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Pulasthi Supun
>>> Software Engineer; WSO2 Inc.; http://wso2.com,
>>> Email: pulas...@wso2.com
>>> Mobile: +94 (71) 9258281
>>> Blog : http://pulasthisupun.blogspot.com/
>>> Git hub profile: https://github.com/pulasthi
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Dimuthu Leelarathne
>> Architect & Product Lead of App Factory
>>
>> WSO2, Inc. (http://wso2.com)
>> email: dimut...@wso2.com
>> Mobile : 0773661935
>>
>> Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Appfactory] Improving the scalability of the dasboards

[Tanya Madurapperuma]

Hi all,

Once users start to use appfactory for sometime lot of data will be
accumulated and users will not be interested in viewing all those in the
dashboard. Instead they would prefer viewing a chosen set of data within a
particular period of time. (Ex: Lets say user wants to view the number of
fail - success builds per applications within March 2013 to Nov 2013 )

In order to achieve this we can provide a slider to select the time range
that they are interested in. But there are few ways that can be done.

   1. Place a global slider and update all the gadgets depending on the
   selection using pub-sub model. ( but some of the gadgets will not require a
   time period selection)
   2. Embed a slider in each of the gadget which needs time period
   selection. (might not be a good approach in the sense of usability)
   3. Place a slider in the gadget's place-holder and upon user selection
   render the graph over the slider and provide something like a back button
   to get back the slider.

IMO approach No 1 is the best approach out of the 3. Are there any better
approaches in achieving this?

WDYT?

Thanks,
Tanya


On Tue, Nov 26, 2013 at 1:33 PM, Tanya Madurapperuma  wrote:

> Hi all,
>
> As Gayan has mentioned I have extended the gadget to display only a chosen
> set of data (ex: say first 10 data points ) and make it possible to
> navigate to the rest of the points by scrolling back and forth. Also it is
> possible to zoom out and have a bird's eye of the graph.
>
> Thanks,
> Tanya.
>
>
> On Mon, Nov 25, 2013 at 2:07 PM, Gayan Dhanushka  wrote:
>
>> Hi all,
>>
>> We will be incorporating the zooming functionality as well as scrolling
>> functionality as well. As Dimuthu has mentioned picking up apps as user
>> prefs will be done in post 1.1.0.
>>
>> Thanks
>> GayanD
>>
>>
>>
>> Gayan Dhanuska
>>  Software Engineer
>> http://wso2.com/
>> Lean Enterprise Middleware
>>
>> Mobile
>> 071 666 2327
>>
>> Office
>> Tel   : 94 11 214 5345
>> Fax  : 94 11 214 5300
>>
>> Twitter : https://twitter.com/gayanlggd
>>
>>
>> On Mon, Nov 25, 2013 at 12:19 PM, Dimuthu Leelarathne 
>> wrote:
>>
>>> Hi all,
>>>
>>> Yes. We discussed this with Nuwan and UES team offline. Nuwan thinks
>>> picking up applications can be a post 1.1.0 task and as a solution to the
>>> current problem we are going to look at Zooming control. And if there are
>>> lot of apps we'll zoom and show.
>>>
>>> thanks,
>>> dimuthu
>>>
>>>
>>>
>>> On Mon, Nov 25, 2013 at 11:26 AM, Pulasthi Supun wrote:
>>>
>>>> Hi All,
>>>>
>>>> While picking a sub set of applications using user prefs or some
>>>> criteria seems to be the better option, i think there should be an option
>>>> to summarize all the data to make it complete. WDYT?
>>>>
>>>> Regards,
>>>> Pulasthi
>>>>
>>>>
>>>> On Thu, Nov 21, 2013 at 11:13 AM, Dimuthu Leelarathne <
>>>> dimut...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 21, 2013 at 11:12 AM, Dimuthu Leelarathne <
>>>>> dimut...@wso2.com> wrote:
>>>>>
>>>>>> Hi Gayan,
>>>>>>
>>>>>> I am +1 for picking applications by user prefs when the number of
>>>>>> applications are greater than a certain number - say 20. And if the user
>>>>>> has not set the applications in user prefs lets pick the 20 applications 
>>>>>> by
>>>>>> a certain criteria. As this criteria we can use apps with most number of
>>>>>> dev/qa/devops assigned.
>>>>>>
>>>>>>
>>>>> Or propose another most preferable criteria.
>>>>>
>>>>> thanks,
>>>>> dimuthu
>>>>>
>>>>>
>>>>>> thanks,
>>>>>> dimuthu
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 21, 2013 at 10:57 AM, Gayan Dhanushka wrote:
>>>>>>
>>>>>>> Hi Samisa,
>>>>>>>
>>>>>>> As of now we only have the CXO dashboard only. We have decided to go
>>>>>>> with the CXO dashboard only for Appfac 1.1 . It is because we needed to
>>>>>>> limit the scope and there are more refinements to be done to the CXO
>>>>>>> dashboard. We 

Re: [Architecture] Invitation: APIM Progress update @ Mon Jan 20 11:30pm - Tue Jan 21, 2014 12:30am (samee...@wso2.com)

[Tanya Madurapperuma]

Hi all,

Following is the meeting notes of $ Subject.

Participants : APIM team, Store team ( Ruchira, SameeraM, Tanya ), Rajeeva,
Venura

*UI related modifications*

   1. Modify the look and feel of "Asset details" page as of that of APIM


   - Fix the UI issues
 -  Expand the application name box in the UI to show it in full
 -  Display the label names of each text boxes
 -  Align text boxes vertically


*Implementations*

   1. As swagger css files conflicts with Enterprise Store css files, Embed
   the swagger client in an iframe
   2. Implement the hidden fields that can be enabled by user (which is
   currently there in the APIM) in the subscription widget
   3. Enterprise store needs to be multi tenanted to view the publicly
   visible tenant space stores via a url
   4. Asset related images need to be stored in registry
   5. Refactor the APIM to use "require" in the places where it is done
   with "jagg.module"
   6. Global extensions
  - Rebranding the store
 - Enterprise Store logos and themes need to be customizable
 - Top assets page
  7. Move APIM publisher to Enterprise Store publisher


   -  Issue regarding the difference of "Published" state in APIM and
  Enterprise Store will be fixed once done


*Bugs*

   1. Fix content based search in store
   2. Missing asset thumbnails in "My Subscription" page - Images will be
   returned with the subscribed methods api call (Check)


Please add if I have missed anything.

Thanks,
Tanya



On Mon, Jan 20, 2014 at 11:25 PM, Sameera Medagammaddegedara <
samee...@wso2.com> wrote:

> more details 
> »<https://www.google.com/calendar/event?action=VIEW&eid=cWttMWE0YTllMm5oZDRsbmdyMDZ2NmVjNjAgYXJjaGl0ZWN0dXJlQHdzbzIub3Jn&tok=MTcjc2FtZWVyYW1Ad3NvMi5jb20wN2QzZDM2NmE4MmE0NjZhZDQ1NzNlNDhjMTZjZjgxYzc1YmYyNzBm&ctz=Asia/Colombo&hl=en>
> APIM Progress update
> *When*
> Mon Jan 20 11:30pm – Tue Jan 21, 2014 12:30am Colombo
> *Where*
> Kernal Room, 3rd Floor 
> (map<http://maps.google.lk/maps?q=Kernal+Room,+3rd+Floor&hl=en>
> )
> *Calendar*
> samee...@wso2.com
> *Who*
> •
> Sameera Medagammaddegedara - organizer
> •
> Joseph Fonseka
> •
> Ruchira Wageesha
> •
> Lalaji Sureshika
> •
> architecture@wso2.org
> •
> Sumedha Rubasinghe
> •
> Dinusha Senanayaka
>
> Going?   *Yes
> <https://www.google.com/calendar/event?action=RESPOND&eid=cWttMWE0YTllMm5oZDRsbmdyMDZ2NmVjNjAgYXJjaGl0ZWN0dXJlQHdzbzIub3Jn&rst=1&tok=MTcjc2FtZWVyYW1Ad3NvMi5jb20wN2QzZDM2NmE4MmE0NjZhZDQ1NzNlNDhjMTZjZjgxYzc1YmYyNzBm&ctz=Asia/Colombo&hl=en>
> - Maybe
> <https://www.google.com/calendar/event?action=RESPOND&eid=cWttMWE0YTllMm5oZDRsbmdyMDZ2NmVjNjAgYXJjaGl0ZWN0dXJlQHdzbzIub3Jn&rst=3&tok=MTcjc2FtZWVyYW1Ad3NvMi5jb20wN2QzZDM2NmE4MmE0NjZhZDQ1NzNlNDhjMTZjZjgxYzc1YmYyNzBm&ctz=Asia/Colombo&hl=en>
> - No
> <https://www.google.com/calendar/event?action=RESPOND&eid=cWttMWE0YTllMm5oZDRsbmdyMDZ2NmVjNjAgYXJjaGl0ZWN0dXJlQHdzbzIub3Jn&rst=2&tok=MTcjc2FtZWVyYW1Ad3NvMi5jb20wN2QzZDM2NmE4MmE0NjZhZDQ1NzNlNDhjMTZjZjgxYzc1YmYyNzBm&ctz=Asia/Colombo&hl=en>*
> more options 
> »<https://www.google.com/calendar/event?action=VIEW&eid=cWttMWE0YTllMm5oZDRsbmdyMDZ2NmVjNjAgYXJjaGl0ZWN0dXJlQHdzbzIub3Jn&tok=MTcjc2FtZWVyYW1Ad3NvMi5jb20wN2QzZDM2NmE4MmE0NjZhZDQ1NzNlNDhjMTZjZjgxYzc1YmYyNzBm&ctz=Asia/Colombo&hl=en>
>
> Invitation from Google Calendar <https://www.google.com/calendar/>
>
> You are receiving this courtesy email at the account 
> architecture@wso2.orgbecause you are an attendee of this event.
>
> To stop receiving future notifications for this event, decline this event.
> Alternatively you can sign up for a Google account at
> https://www.google.com/calendar/ and control your notification settings
> for your entire calendar.
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 User Engagement Server 1.5.0 -Milestone-1 Released !

[Tanya Madurapperuma]

*WSO2 User Engagement Server 1.5.0 -Milestone-1 Released !*

The Milestone-1 of WSO2 User Engagement Server can be downloaded at
[1]<http://dist.wso2.org/milestone/ues/1.5.0-M1/wso2ues-1.5.0.zip>.
Milestone-1 mainly contains the initial implementation of UES Gadget-gen
Tool.

*How to test UES Gadget-gen Tool*

   1. Start UES and login to the portal.
   2. Click "Create" in the top left corner of the page and select
   "Dashboard'.
   3. Enter dashboard name, choose your preferred layout and click on
   "Create new app".
   4. You will be redirected to the designer window of the dashboard page.
   5. Click on "Add Gadget" button on any of the blocks.
   6. Follow the wizard.
   7. Wizard will be more or less similar to the BAM gadget gen tool wizard.
   8. At the data mapping window, user can can click on the + sign and add
   more series to a single chart.
   9. Data source jag and chart options( which can be used to customize the
   generated chart ) file will be auto-generated.


*Limitations*


   - Only supports connecting to RDBMS data source at the moment.
   - Line chart and Bar chart templates have been re-factored and rest of
   the charts will be done in future milestones.
   - Wizard UI will to be styled and polished in coming releases.
   - Error handling and validations are yet to be done.
   - Supporting text based x-axis ticks has been done and other special
   data types (ex : date/time) has not been done yet. Because by default flot
   (graphing library used for gadgets) supports only integer based x-axis
   ticks)


*IMPORTANT*

   - Gadget gen tool feature is in its very early stages, you will
   encounter number of bugs and feature limitations, we are working on
   improving these in future milestones.

*References*
[1] Product can be downloaded from :
http://dist.wso2.org/milestone/ues/1.5.0-M1/wso2ues-1.5.0.zip
[2] Portal is located at : http://{IP}:9763/portal/
[3] Store is located at : http://{IP}:9763/store/
[4] Issue Tracker: https://wso2.org/jira/browse/UES

Thanks,
~ UES team ~

-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 User Engagement Server 1.5.0 -Milestone-2 Released !

[Tanya Madurapperuma]

*WSO2 User Engagement Server 1.5.0 -Milestone-2 Released !*

The Milestone-2 of WSO2 User Engagement Server can be downloaded at
[1]<http://dist.wso2.org/milestone/ues/1.5.0-M2/wso2ues-1.5.0.zip>.
Milestone-2 specifically contains following bug fixes, improvements and
features done to the gadget generation tool.

*Bug*

   - [UES-489 <https://wso2.org/jira/browse/UES-489>] - Back buttons makes
   the filled content disappear in gadget-gen wizard
   - [UES-490 <https://wso2.org/jira/browse/UES-490>] - Back button in
   store window of the wizard needs to be properly positioned

Improvement

   - [UES-488 <https://wso2.org/jira/browse/UES-488>] - Style gadget gen
   wizard coming in personalize mode
   - [UES-491 <https://wso2.org/jira/browse/UES-491>] - Refactor bubble
   chart to work with the new model
   - [UES-493 <https://wso2.org/jira/browse/UES-493>] - Refactor horizontal
   bar chart to work with new model
   - [UES-495 <https://wso2.org/jira/browse/UES-495>] - Refactor Pie chart
   to support the new model
   - [UES-496 <https://wso2.org/jira/browse/UES-496>] - Refactor stacked
   chart to work the new model
   - [UES-497 <https://wso2.org/jira/browse/UES-497>] - Refactor
   line-plus-bar chart to work with new model

New Feature

   - [UES-475 <https://wso2.org/jira/browse/UES-475>] - Wizard/tool to
   generate data source *.jag file
   - [UES-492 <https://wso2.org/jira/browse/UES-492>] - Support ticks
   rotation in graphs




*How to test UES Gadget-gen Tool*

   1. Start UES and login to the portal.
   2. Click "Create" in the top left corner of the page and select
   "Dashboard'.
   3. Enter dashboard name, choose your preferred layout and click on
   "Create new app".
   4. You will be redirected to the designer window of the dashboard page.
   5. Click on "Add Gadget" button on any of the blocks.
   6. Follow the wizard.
   7. Wizard will be more or less similar to the BAM gadget gen tool wizard.
   8. At the data mapping window, user can can click on the + sign and add
   more series to a single chart.
   9. Data source jag and chart options( which can be used to customize the
   generated chart ) file will be auto-generated.

*Limitations*


   - Only supports connecting to RDBMS data source at the moment.
   - Error handling and validations are yet to be done.
   - Supporting text based x-axis ticks has been done and other special
   data types (ex : date/time) has not been done yet. Because by default flot
   (graphing library used for gadgets) supports only integer based x-axis
   ticks)


*IMPORTANT*

   - Gadget gen tool feature is in its very early stages, you will
   encounter number of bugs and feature limitations, we are working on
   improving these in future milestones.


*References*
[1] Product can be downloaded from :
*http://dist.wso2.org/milestone/ues/1.5.0-M2/wso2ues-1.5.0.zip
<http://dist.wso2.org/milestone/ues/1.5.0-M2/wso2ues-1.5.0.zip>*
[2] Portal is located at : http://{IP}:9763/portal/
[3] Store is located at : http://{IP}:9763/store/
[4] Issue Tracker: https://wso2.org/jira/browse/UES

Thanks,
~ UES team ~

-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Meeting Notes] Review of UES Gadget generation tool Milestone 2

[Tanya Madurapperuma]

Hi all,

Please find the meeting notes of the $ Subject.

*Participants* : Srinath, Anjana Suho, Sinthuja, Ruchira, Tanya

*Actions*:

   - Required fields should be marked with * in the wizard
   - Need to indicate that "Update interval" is in seconds
   - Toggling between series of a particular chart should be made possible
   without pausing
   - Preview the results of the user provided sql query in the same window
   and allow user to try out different queries before proceeding
   - At the "Data mapping" window show the selected chart type
   -  Assume tabular data format coming from any plug-able data source and
   insert an intermediate layer to format data required for specific chart type
  - X data source -->  data in tabular format -->   data processing
  layer for selected chart
  - Re-factor the generated jag file to call modules and get the work
  done for filtering and formatting data


*Other observations* :

   - Drill down feature for gadgets needs to be supported from the gadget
   template.
  - Let's say there's a pie chart with country vice data, when you
  click on a particular country in the chart, you will get a bar chart with
  provincial data of the selected country.
  - A customized pie chart template needs to be written to support the
  drill down functionality, but the existing bar chart template
can be reused
  to show provincial data.
   - Review the wizard UI for better user experience regarding preview of
   data results and etc
   - Filtering of data displayed on a gadget
  - Filtering can be within the same gadget
  - Filtering may be based on another gadget - pub sub model (Ex: based
  on a time slider gadget)
   - Copying of entire gadget template source upon adding of a gadget to
   the dashboard Vs sharing the gadget template

*Future items*

   - Ability to configure multiple data sources for a single chart.


Please add if I have missed anything.

Thanks,
Tanya

-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Meeting Notes] Review of UES Gadget generation tool Milestone 2

[Tanya Madurapperuma]

Noted. Will proceed and re-factor the tool + UES to work so.

Thanks,
Tanya.


On Wed, Feb 26, 2014 at 11:41 AM, Srinath Perera  wrote:

> I briefly chatted with Sanjiva about the model, and we thought it is best
> to copy all the related file about the gadget in to one folder, so that the
> user can edit that easily. Also we need to review the code it generate and
> generate something clean.
>
> Reason is
>
> Basically, truth is that most users would want to edit what we generate
> and most real graph's need tweeking. However, the demo power of the wizard
> is also great (so we need a wizard).
>
> So I think we should think of wizard as "create new servelt" thing in
> eclipse. We generate something, but user will edit that. So we need to put
> all related things in one place and generate something that easy to
> understand.
>
> --Srinath
>
>
> On Mon, Feb 24, 2014 at 6:09 AM, Tanya Madurapperuma wrote:
>
>> Hi all,
>>
>> Please find the meeting notes of the $ Subject.
>>
>> *Participants* : Srinath, Anjana Suho, Sinthuja, Ruchira, Tanya
>>
>> *Actions*:
>>
>>- Required fields should be marked with * in the wizard
>>- Need to indicate that "Update interval" is in seconds
>>- Toggling between series of a particular chart should be made
>>possible without pausing
>>- Preview the results of the user provided sql query in the same
>>window and allow user to try out different queries before proceeding
>>- At the "Data mapping" window show the selected chart type
>>-  Assume tabular data format coming from any plug-able data source
>>and insert an intermediate layer to format data required for specific 
>> chart
>>type
>>   - X data source -->  data in tabular format -->   data processing
>>   layer for selected chart
>>   - Re-factor the generated jag file to call modules and get the
>>   work done for filtering and formatting data
>>
>>
>> *Other observations* :
>>
>>- Drill down feature for gadgets needs to be supported from the
>>gadget template.
>>   - Let's say there's a pie chart with country vice data, when you
>>   click on a particular country in the chart, you will get a bar chart 
>> with
>>   provincial data of the selected country.
>>   - A customized pie chart template needs to be written to support
>>   the drill down functionality, but the existing bar chart template can 
>> be
>>   reused to show provincial data.
>>- Review the wizard UI for better user experience regarding preview
>>of data results and etc
>>- Filtering of data displayed on a gadget
>>   - Filtering can be within the same gadget
>>   - Filtering may be based on another gadget - pub sub model (Ex:
>>   based on a time slider gadget)
>>- Copying of entire gadget template source upon adding of a gadget to
>>the dashboard Vs sharing the gadget template
>>
>> *Future items*
>>
>>- Ability to configure multiple data sources for a single chart.
>>
>>
>> Please add if I have missed anything.
>>
>> Thanks,
>> Tanya
>>
>> --
>> Tanya Madurapperuma
>>
>> Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>
>
>
> --
> 
> Srinath Perera, Ph.D.
>   Director, Research, WSO2 Inc.
>   Visiting Faculty, University of Moratuwa
>   Member, Apache Software Foundation
>   Research Scientist, Lanka Software Foundation
>   Blog: http://srinathsview.blogspot.com/
>   Photos: http://www.flickr.com/photos/hemapani/
>Phone: 0772360902
>



-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 User Engagement Server 1.5.0 -Milestone-3 Released !

[Tanya Madurapperuma]

*WSO2 User Engagement Server 1.5.0 -Milestone-2 Released !*

The Milestone-3 of WSO2 User Engagement Server can be downloaded at
[1]<http://dist.wso2.org/milestone/ues/1.5.0-M3/wso2ues-1.5.0.zip>.
Milestone-3 specifically contains following bug fixes, improvements and
features done to the gadget generation tool.

*Improvement*

   - [UES-509 <https://wso2.org/jira/browse/UES-509>] - Preview of the
   gadget should be shown in the gadget-gen wizard itself


*Task*

   - [UES-504 <https://wso2.org/jira/browse/UES-504>] - Toggling between
   series of a particular chart should be made possible without pausing
   - [UES-505 <https://wso2.org/jira/browse/UES-505>] - Preview the results
   of the user provided sql query in the same window and allow user to try out
   different queries before proceeding
   - [UES-506 <https://wso2.org/jira/browse/UES-506>] - At the "Data
   mapping" window show the selected chart type
   - [UES-508 <https://wso2.org/jira/browse/UES-508>] - Set the chart title
   in the dashboard


*Bug*

   - [UES-501 <https://wso2.org/jira/browse/UES-501>] - Change text field
   for password in "create new connection" window to a password field
   - [UES-503 <https://wso2.org/jira/browse/UES-503>] - Need to indicate
   update interval in wizard is in seconds




*How to test UES Gadget-gen Tool*

   1. Start UES and login to the portal.
   2. Click "Create" in the top left corner of the page and select
   "Dashboard'.
   3. Enter dashboard name, choose your preferred layout and click on
   "Create new app".
   4. You will be redirected to the designer window of the dashboard page.
   5. Click on "Add Gadget" button on any of the blocks.
   6. Follow the wizard.
   7. Wizard will be more or less similar to the BAM gadget gen tool wizard.
   8. At the data mapping window, user can can click on the + sign and add
   more series to a single chart.
   9. Data source jag and chart options( which can be used to customize the
   generated chart ) file will be auto-generated.

*Limitations*


   - Only supports connecting to RDBMS data source at the moment.
   - Error handling and validations are yet to be done.
   - Supporting text based x-axis ticks has been done and other special
   data types (ex : date/time) has not been done yet. Because by default flot
   (graphing library used for gadgets) supports only integer based x-axis
   ticks)


*IMPORTANT*

   - Gadget gen tool feature is in its early stages, you will encounter
   number of bugs and feature limitations, you can report them at
[4].<https://wso2.org/jira/browse/UES>We are working on improving
these in future milestones.


*References*
[1] Product can be downloaded from :
*http://dist.wso2.org/milestone/ues/1.5.0-M3/wso2ues-1.5.0.zip
<http://dist.wso2.org/milestone/ues/1.5.0-M3/wso2ues-1.5.0.zip>*
[2] Portal is located at : http://{IP}:9763/portal/
[3] Store is located at : http://{IP}:9763/store/
[4] Issue Tracker: https://wso2.org/jira/browse/UES

Thanks,
~ UES team ~

-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Invitation: UES Gadget gen tool M3 review @ Wed Mar 12, 2014 3:30pm - 4:30pm (ta...@wso2.com)

[Tanya Madurapperuma]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20140312T10Z
DTEND:20140312T11Z
DTSTAMP:20140312T092649Z
ORGANIZER;CN=Tanya Madurapperuma:mailto:ta...@wso2.com
UID:rpclvfpvn9j4ifkq13462i6...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Srinath Perera;X-NUM-GUESTS=0:mailto:srin...@wso2.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
 UE;CN=LK 3rd Floor Meeting Room - Kernel;X-NUM-GUESTS=0:mailto:wso2.com_323
 4323338383134353...@resource.calendar.google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Ruchira Wageesha;X-NUM-GUESTS=0:mailto:ruch...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Tanya Madurapperuma;X-NUM-GUESTS=0:mailto:ta...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=architecture@wso2.org;X-NUM-GUESTS=0:mailto:architecture@wso2.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Sinthuja Ragendran;X-NUM-GUESTS=0:mailto:sinth...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Sriskandarajah Suhothayan;X-NUM-GUESTS=0:mailto:s...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Anjana Fernando;X-NUM-GUESTS=0:mailto:anj...@wso2.com
CREATED:20140312T092649Z
DESCRIPTION:To update on the progress and review the M3 of the UES gadget g
 eneration tool\nView your event at http://www.google.com/calendar/event?act
 ion=VIEW&eid=cnBjbHZmcHZuOWo0aWZrcTEzNDYyaTYyOHMgYXJjaGl0ZWN0dXJlQHdzbzIub3
 Jn&tok=MTQjdGFueWFAd3NvMi5jb21lMGMzZmFlMjdjMTMwY2MzZjYyODBjYTQzODdlMzQxNzIy
 ZmUyMTg0&ctz=Asia/Colombo&hl=en.
LAST-MODIFIED:20140312T092649Z
LOCATION:LK 3rd Floor Meeting Room - Kernel
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:UES Gadget gen tool M3 review 
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Meeting Notes] Discussion on UES on 21/03/2014

[Tanya Madurapperuma]

Hi all,

Please find the meeting notes of the $ Subject we had with the following
participants regarding the gadget generation tool of the UES.

*Participants :  *Isabelle, Srinath, Ruchira, Suho, Anjana, Tanya


*Actions  :*

   - Data-source window
  - Provide the facility to select from the existing data-sources that
  are configured in the master-datasources.xml
   - SQL query window
  - Depending on the selected data-source, show the available tables
  and their column headers so that user can write the SQL query easily.
   - Store modal window
  - Clean up the store model window.
 - Remove "Bookmarks" tab
 - Keep only the gadget templates and remove the rest ( Ex: WSO2
 jira gadget etc ) from the window
 - Remove "External" tab
  - Keep the search box and the tag support
  - Change "Select Gadget" to "Select Template"


*Other Observations :*

   - When a gadget is added to the dashboard, the files related to that
   particular dashboard is not accessible in the Jaggery Web IDE.
   - When configuring a new data-source by the wizard, passwords are saved
   as plain-text.
   - Encourage users to configure and use existing data-sources as
   configuring data-sources in the tool is not scalable. (Ex : show up a
   warning)


Thanks,
Tanya


-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Analytics Dashboards] Configuring the visibility of the widget title bar

[Tanya Madurapperuma]

Hi all,

We have a requirement of hiding the widget title bar in some use cases. For
example Date time picker widget doesn't need to have widget title displayed
on its container.

In order to implement this we can take two approaches.



   1.

   Provide a config to be added in the widgetConf.json file which indicates
   if we want to hide the title. By default (when there is no config added)
   title will be visible and only hidden when a config as below is added.

{

"name": "UserInfo",

"id": "UserInfo",

"thumbnailURL": "",

"configs": {

  "containerConfig": {

"header": {

  "show": false

}

  },

  "options": []

}

}

Drawbacks with this approach

   -

   If the widget is a custom widget, config change gets applied to all
   instances of the given widget globally. For example if we have 10 date
   picker widgets in different dashboards, title of all widgets will be
   hidden.
   -

   If the widget is a generated one, we have to do a database call to edit
   the widgetConf.json. ( When we provide a facility to edit generated widgets
   this issue will be gone)



   1.

   Introduce an options config in the widget. In this approach config
   should be added to all the widgets by default and designer can configure
   his preference after adding the widget to the dashboard.

{

"name": "UserInfo",

"id": "UserInfo",

"thumbnailURL": "",

"configs": {

  "options": [

{

  "id": "header",

  "title": "Header",

  "type": {

"name": "BOOLEAN",

"possibleValues": [

 true, false

]

  },

  "defaultValue": true

}

  ]

}

}

Logic that needs to be executed upon receiving of the option can be handed
over to the base widget so that each widget author needs not to worry about
that and will inherit.

Drawbacks with this approach

   -

   In the approach one, golden layout will take care of hiding the title
   header using its ItemConfig options [1]. So supporting other itemConfigs in
   future will be straightforward. But in this second approach we will have to
   implement logic in base widget for newer configs.


Considering the above options, it seems to me that second approach is more
appropriate. Appreciate your inputs on above approaches and any other
approaches.

[1] https://golden-layout.com/docs/ItemConfig.html


Thanks,

Tanya

-- 
Tanya Madurapperuma

Associate Technical Lead,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Analytics Dashboards] Configuring the visibility of the widget title bar

[Tanya Madurapperuma]

Thank you Nisala and Lasantha for your replies.
@ Lasantha : Please find the answers inline.

On Tue, Aug 28, 2018 at 1:01 PM, Lasantha Samarakoon 
wrote:

> +1 for the second approach with some changes.
>
> Since this is a common built-in option for all the widgets, do we really
> need the widget developer to explicitly mention the option in the
> widgetConf?
>
 Reason behind saying that needs to be mentioned in the widgetConf.json is
because we can reuse the Options feature [1][2] already available in the
dashboards. Because we need a piece of UI for configuring show/hide title
and if we use Options feature, it will generate the UI for us.
 In the generated widgets' case, since we have a default widgetConf.json
[3] file we can include the above config by default. Widget authors will
only need to add the above config only when they are writing custom
widgets. Or else we will have to maintain some magic list of configurations
which Options feature will generate UIs by default.
WDYT?

> I prefer showing that option for all the widgets even though it is not
> mentioned in the widgetConf. In the future, we might need to support many
> other similar options as well.
>

[1]
https://github.com/wso2/carbon-dashboards/blob/master/components/dashboards/org.wso2.carbon.dashboards.core/src/main/java/org/wso2/carbon/dashboards/core/bean/widget/Option.java

[2]
https://github.com/wso2/carbon-dashboards/blob/master/components/dashboards-web-component/src/designer/components/WidgetOptionsConfiguration.jsx
[3]
https://github.com/wso2/carbon-dashboards/blob/master/components/universal-widget/src/resources/widgetConf.json

>
> Thanks,
>
> On Tue, Aug 28, 2018 at 12:44 PM Nisala Nanayakkara 
> wrote:
>
>> Hi all,
>>
>> I am also +1 for the second approach.
>>
>> Drawbacks with this approach
>>>
>>>-
>>>
>>>In the approach one, golden layout will take care of hiding the
>>>title header using its ItemConfig options [1]. So supporting other
>>>itemConfigs in future will be straightforward. But in this second 
>>> approach
>>>we will have to implement logic in base widget for newer configs.
>>>
>>>
>> AFAIU there is no solid requirement of using other itemConfigs in widget
>> level up to now. Since we do not have widget editing capability for
>> generated widgets at the moment, if we follow the 1st approach, we have to
>> do a DB call in order to change the configs for generated widgets. I think
>> it is better to overcome the DB call drawback rather than overcoming the
>> itemConfigs issue. Because changing widgetConf related show/hide title is
>> more frequent use case compared to passing new itemConfigs.
>>
>> Thanks,
>> Nisala
>>
>> On Tue, Aug 28, 2018 at 12:21 PM Tanya Madurapperuma 
>> wrote:
>>
>>> Hi all,
>>>
>>> We have a requirement of hiding the widget title bar in some use cases.
>>> For example Date time picker widget doesn't need to have widget title
>>> displayed on its container.
>>>
>>> In order to implement this we can take two approaches.
>>>
>>>
>>>
>>>1.
>>>
>>>Provide a config to be added in the widgetConf.json file which
>>>indicates if we want to hide the title. By default (when there is no 
>>> config
>>>added) title will be visible and only hidden when a config as below is
>>>added.
>>>
>>> {
>>>
>>> "name": "UserInfo",
>>>
>>> "id": "UserInfo",
>>>
>>> "thumbnailURL": "",
>>>
>>> "configs": {
>>>
>>>   "containerConfig": {
>>>
>>> "header": {
>>>
>>>   "show": false
>>>
>>> }
>>>
>>>   },
>>>
>>>   "options": []
>>>
>>> }
>>>
>>> }
>>>
>>> Drawbacks with this approach
>>>
>>>-
>>>
>>>If the widget is a custom widget, config change gets applied to all
>>>instances of the given widget globally. For example if we have 10 date
>>>picker widgets in different dashboards, title of all widgets will be
>>>hidden.
>>>-
>>>
>>>If the widget is a generated one, we have to do a database call to
>>>edit the widgetConf.json. ( When we provide a facility to edit generated
>>>widgets this issue will be gone)
>>>
>>>
>>>

Re: [Architecture] [Dev] [VOTE] Release of WSO2 Stream Processor 4.3.0 RC3

[Tanya Madurapperuma]

Hi All,

I have tested following.

   1. Basic dashboard functionalities
  - Create dashboard
  - Drag and drop widgets
  - Create Pages in dashboard
  - Hide Pages
   2. Dashboard import / export feature
   3. Dashboard and widget report generation feature

No issues found.

[+] Stable go ahead and release

Thanks,
Tanya

On Mon, Sep 17, 2018 at 7:56 AM, Niveathika Rajendran 
wrote:

> Hi all,
>
> I have tested the following,
>1. Local IdPClient
>2. Login/Logout Rest API
>3. Authentication Interceptor
>4. HTTP Analytics Solution [worker/dashboard]
>5. Monitoring dashboard for a single node [Node view/App view]
>6. Editor sample:
>   - MongoDB
>   - Aggregate Data Incrementally
>
> [+] Stable go ahead and release
>
> Best Regards,
> *Niveathika Rajendran,*
> *Software Engineer.*
> *Mobile : +94 077 903 7536*
>
>
>
>
>
> On Mon, Sep 17, 2018 at 1:55 AM Sajith Perera  wrote:
>
>> Tested the following.
>>
>> Siddhi Stores Query API[editor/worker runtime]
>> Distributed Message Tracer[worker/dashboard runtime]
>> SP Distributed Deployment[2 Manger/ 5 Worker(including single receiver)
>> runtimes]
>> Editor Sample:
>>  - Store RDBMS MySQL/Oracle[editor]
>>  - Store Cassedra[editor]
>>
>> No blockers found.
>>
>> [+] Stable - go ahead and release
>>
>> Thanks,
>> SajithD
>>
>> On Sat, Sep 15, 2018 at 1:05 AM, Dilini Muthumala 
>> wrote:
>>
>>> Hi all,
>>>
>>>
>>> WSO2 Stream Processor team is pleased to announce the third
>>> release candidate of WSO2 Stream Processor 4.3.0.
>>>
>>>
>>> WSO2 Stream Processor is an open source embodiment of the WSO2 Analytics
>>> platform, of which the real-time, incremental & intelligent data processing
>>> capabilities let digital businesses create actionable business insights and
>>> data products.
>>>
>>>
>>> Please find the improvements and fixes related to this release:
>>>
>>> - siddhi
>>> <https://github.com/wso2/siddhi/issues?utf8=%E2%9C%93&q=is%3Aissue+closed%3A2018-06-20..2018-09-15>
>>>
>>> - carbon-analytics-common
>>> <https://github.com/wso2/carbon-analytics-common/issues?utf8=%E2%9C%93&q=is%3Aissue+closed%3A2018-06-20..2018-09-15>
>>>
>>> - carbon-analytics
>>> <https://github.com/wso2/carbon-analytics/issues?utf8=%E2%9C%93&q=is%3Aissue+closed%3A2018-06-20..2018-09-15>
>>>
>>> - carbon-dashboards
>>> <https://github.com/wso2/carbon-dashboards/issues?utf8=%E2%9C%93&q=is%3Aissue+closed%3A2018-06-20..2018-09-15>
>>>
>>> - analytics-solutions
>>> <https://github.com/wso2/analytics-solutions/issues?utf8=%E2%9C%93&q=is%3Aissue+closed%3A2018-06-20..2018-09-15>
>>>
>>> - product-sp
>>> <https://github.com/wso2/product-sp/issues?utf8=%E2%9C%93&q=is%3Aissue+closed%3A2018-06-20..2018-09-15>
>>>
>>>
>>> You can download the product distribution from: https://github.com/wso2/
>>> product-sp/releases/download/v4.3.0-rc3/wso2sp-4.3.0-rc3.zip
>>>
>>>
>>> The tag to be voted upon: 
>>> *https://github.com/wso2/product-sp/releases/tag/v4.3.0-rc3
>>> <https://github.com/wso2/product-sp/releases/tag/v4.3.0-rc3>*
>>>
>>>
>>> Please download, test the product and vote.
>>>
>>>
>>> [+] Stable - go ahead and release
>>>
>>> [-] Broken - do not release (explain why)
>>>
>>>
>>> Thanks,
>>>
>>> - WSO2 Stream Processor Team -
>>>
>>
>>
>>
>> --
>> <http://wso2.com/signature>
>> Sajith Dimal
>> Seniror Software Engineer
>> Email : saji...@wso2.com
>> Mobile : +94783101496
>> WSO2 Inc. | http://wso2.com
>> lean.enterprise.middleware
>>
>>
>> Disclaimer: This communication may contain privileged or other
>> confidential information and is intended exclusively for the addressee/s.
>> If you are not the intended recipient/s, or believe that you may have
>> received this communication in error, please reply to the sender indicating
>> that fact and delete the copy you received and in addition, you should not
>> print, copy, re-transmit, disseminate, or otherwise use the information
>> contained in this communication. Internet communications cannot be
>> guaranteed to be timely, secure, error or virus-free. The sender does not
>> accept liability for any errors or omissions.
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Tanya Madurapperuma* | Associate Technical Lead| WSO2 Inc.
(m) +94718184439 | (e) ta...@wso2.com

<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [carbon-dashboards][widget-generation-wizard]Create an autocomplete search using widget generation wizard

[Tanya Madurapperuma]

+1 for the second approach.

On Thu, Sep 20, 2018 at 5:33 PM, Ruwini Wijesiri  wrote:

> Hi All,
>
> The widget generation wizard enables user to create widgets by configuring
> a data source and publisher information.
>
> We have a requirement to enable user to create a autocomplete search bar
> using the widget generation wizard. The user will specify a column of the
> configured data source and the search bar will list down it's content. The
> value(s) selected using this widget will be published to its subscribers.
>
> There are 2 approaches to implement this;
>
> *1. Include the autocomplete in react-vizgrammar *
>
> *Drawbacks:*
>
>
>- All components available in react-vizgrammar are charts, since an
>  autocomplete isn't a chart, putting it in react-vizgrammar seems 
> like a
>  misfit.
>  - The autocomplete is implemented using material-ui 1.5.0 and
>  this requires react 16.3.0 or above. Currently, react-vizgrammar is 
> on
>  react 16.0.0, therefore react versions needs to be bumped. An 
> upgrade may
>  cause issues in the existing implementation.
>
> *2. Generalize the implementation universal-widget and introduce 2 new
> modules to handle each type.*
>
>
>
> *-parent-renderer*
>
>
> *-vizgrammar-renderer**-search-renderer*
>
>
> Current implementation of universal widget can be refactored as above,
> where the '*parent-renderer*' will contain the implementations common to
> all widgets such as publisher configuration creation, '
> *vizgrammar-renderer*' contain implementation specific to rendering
> vizgrammar charts and '*search-renderer*' contain implementation specific
> to rendering the search bar.
>
>
> *Drawbacks:*
>
>
>- Not backward compatible. The existing dashboards identifies the
>  widget generation wizard by the name universal widget. Renaming 
> universal
>  widget to '*parent-renderer' *will either require migration
>  scripts to replace term universal widget with '*vizgrammar-renderer'
>  or 'search-renderer' or this will need to be handled at dashboard 
> level.*
>
>
> I think its better to handle this at the dashboard level by making "
*UniversalWidget*" a reserved word and replacing it with
"*vizgrammar-renderer"
*in the Dashboard json before passing it to Golden Layout. So that
customers don't need to bother about any additional migration effort.

Thanks,
Tanya

> IMO i think the second approach would be better since;
>
>- Adding an autocomplete select along with charts seems a misfit
>- Scalable, can facilitate future introductions of other types of
>    widgets into the widget generation wizard.
>
>
> Any thoughts on these 2 approaches or any other approach is highly
> appreciated.
>
> Thanks,
> Regards,
> Ruwini
>
> Ruwini Wijesiri
> Software Engineer,
> WSO2 Inc.
>
> Mobile : +94716133480
>
> <http://wso2.com/signature>
>



-- 
*Tanya Madurapperuma* | Associate Technical Lead| WSO2 Inc.
(m) +94718184439 | (e) ta...@wso2.com

<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [carbon-dashboards][widget-generation-wizard]Create an autocomplete search using widget generation wizard

[Tanya Madurapperuma]

To add bit more to what Ruwini has explained..

Universal widget currently reads the provider configuration and fetches
data from the data source and render the vizgrammar chart using the fetched
data according to the chart configuration.
In the proposed approach we will still keep the provider configuration
reading and fetching data related logic in the Universal Widget as it is
and hand over the rendering to the specific rendering component based on
the visual element type (i.e vizgrammer or search)
And Universal widget + renderers will get packed as a single module instead
of multiple modules based on visual element renderer since it will avoid
the backward compatibility issue.

Thanks,
Tanya

On Fri, Sep 21, 2018 at 10:44 AM Ruwini Wijesiri  wrote:

> Hi,
>
> If we use the name 'UniversalWidget' instead of 'ParentRenderer' as shown
> below, it  will eliminate the backward compatibility issue.
>
>
> *-universal-widget*
>
> *-vizgrammar-renderer*
> *-search-renderer*
>
> Appreciate your thoughts on this approach.
>
> Thanks,
> Regards,
> Ruwini
>
> On Fri, Sep 21, 2018 at 9:50 AM Ruwini Wijesiri  wrote:
>
>> Hi Sajith,
>>
>> Thanks for the response.
>>
>> I'll proceed with this approach.
>>
>> Thanks,
>> Regards,
>> Ruwini
>>
>> On Fri, Sep 21, 2018 at 9:44 AM Sajith Ariyarathna 
>> wrote:
>>
>>> +1 for 2nd approach.
>>> +1 for suggested migration implementation.
>>>
>>> Thanks.
>>>
>>> On Fri, Sep 21, 2018 at 9:38 AM Ruwini Wijesiri  wrote:
>>>
>>>> Hi Tanya,
>>>>
>>>> Thank you for the response.
>>>>
>>>> I think its better to handle this at the dashboard level by making "
>>>>> *UniversalWidget*" a reserved word and replacing it with  "
>>>>> *vizgrammar-renderer" *in the Dashboard json before passing it to
>>>>> Golden Layout. So that customers don't need to bother about any additional
>>>>> migration effort.
>>>>>
>>>>
>>>> +1 for this.
>>>>
>>>> Thanks,
>>>> Regards,
>>>> Ruwini.
>>>>
>>>> On Fri, Sep 21, 2018 at 8:37 AM Tanya Madurapperuma 
>>>> wrote:
>>>>
>>>>> +1 for the second approach.
>>>>>
>>>>
>>>>
>>>> --
>>>> Ruwini Wijesiri
>>>> Software Engineer,
>>>> WSO2 Inc.
>>>>
>>>> Mobile : +94716133480
>>>>
>>>> <http://wso2.com/signature>
>>>>
>>>
>>>
>>> --
>>> Sajith Janaprasad Ariyarathna
>>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>>> <https://wso2.com/signature>
>>>
>>
>>
>> --
>> Ruwini Wijesiri
>> Software Engineer,
>> WSO2 Inc.
>>
>> Mobile : +94716133480
>>
>> <http://wso2.com/signature>
>>
>
>
> --
> Ruwini Wijesiri
> Software Engineer,
> WSO2 Inc.
>
> Mobile : +94716133480
>
> <http://wso2.com/signature>
>


-- 
*Tanya Madurapperuma* | Associate Technical Lead| WSO2 Inc.
(m) +94718184439 | (e) ta...@wso2.com

<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [SP-Dashboards] Internationalization of widgets

[Tanya Madurapperuma]

On Wed, Nov 21, 2018 at 7:05 PM Fazlan Nazeem  wrote:

> +1 for the second approach.
>
> On Wed, Nov 21, 2018 at 5:04 PM Ruwini Wijesiri  wrote:
>
>> Hi,
>>
>> We have a requirement to internationalize the text content of widgets. So
>> far we have identified 2 approaches to achieve this;
>>
>>1. Have a single locale.json file that contains the message id to
>>text mapping for all locales within the *'resource'* directory of the
>>widget. However. this will result in the the widget needing to be re-built
>>whenever a change is made to the locale.json file.
>>
>> Widget need not to be rebuilt in the first approach. You  can have the
locale file at the
HOME/wso2/dashboard/deployment/web-ui-apps/portal/extensions/widgets//locales/
 and replace only the locale file when needed.
But the issue I see with the first approach is, we need to support serving
the locale file in the above location by the carbon-ui-server also which is
not supported at the moment AFAIK. @SajithAR : Please correct me if I'm
wrong.

>
>>1.
>>2. Have the {locale}.json files in carbon-dashboards and load the
>>json files to the widget via an API call in the same manner it is done in
>>the SP portal. Currently, the SP portal locale files are located in
>>directory *'components/dashboards-web-component/public/locales/'*.
>>The widget specific locale files could be placed in directory
>>
>> *'components/dashboards-web-component/public/locales/widgets/{widget_name}/'.
>>  *
>>
>> +1 for the second approach as it already has carbon-ui- server support.

Thanks,
Tanya

> The second approach seems a better alternative as it will eliminates the
>> need to re-build widgets when new locales are added.
>>
>> Any ideas on these 2 approaches or any other approach is highly
>> appreciated.
>>
>> Thanks,
>> Regards,
>> Ruwini.
>> --
>> Ruwini Wijesiri
>> Software Engineer,
>> WSO2 Inc.
>>
>> Mobile : +94716133480
>>
>> <http://wso2.com/signature>
>>
>
>
> --
> Thanks & Regards,
>
> *Fazlan Nazeem*
> Senior Software Engineer
> WSO2 Inc
> Mobile : +94772338839
> fazl...@wso2.com
>


-- 
*Tanya Madurapperuma* | Associate Technical Lead| WSO2 Inc.
(m) +94718184439 | (e) ta...@wso2.com

<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM 3.0] Tenant Listing for Store

[Tanya Madurapperuma]

new/source/src/app/CustomRouter/BrowserRouter.jsx#L56
>> [3]:
>> https://github.com/dushansilva/carbon-apimgt/tree/560b774c10b74c2709c6bf5b9c6ac20ccca6/features/apimgt/org.wso2.carbon.apimgt.store.feature/src/main/resources/store-new/source/src/app/components/Base
>> [4]:
>> https://github.com/ReactTraining/react-router/blob/master/packages/react-router-dom/modules/BrowserRouter.js#L19-L25
>>
>> Thanks
>> ~KasunTe
>>
>> On Thu, Sep 5, 2019 at 3:29 PM Dushan Silva  wrote:
>>
>>> Hi all,
>>> I have been working on $Subject. While working on it we came across the
>>> following requirement.
>>>
>>> In the previous store implementation the tenant domain is passed on the
>>> url as a query param and when either the page is refresh or if the url is
>>> directly accessed with the query param tenant specific details are loaded.
>>> However in the current react based single page implementation all the
>>> routing is handle via react router. Here if we initially plan on keeping
>>> the tenant domain in the react context api as a global setting. Once the
>>> app is loaded routing can be handled easily by taking the tenant domain
>>> from the context api.
>>>
>>> The problem is when the app is refreshed or if a url is visited
>>> directly, at this occasion the context api is empty and the user will
>>> always be redirect to the tenant listing. To handle this issue after
>>> considering some input from the react community [1] , we came up with the
>>> solution of writing an interceptor for the react router. This would require
>>> us to extend the currently react router implementation and its history
>>> implementation to plugin our custom interceptor. An advantage of the
>>> interceptor approach is that this saves the developer the hassle handling
>>> both tenant and normal cases each and every route path already added and
>>> paths to be added in the future. The flow will be as follows.
>>>
>>> When the store is initially loaded react router should be initialized
>>> [2]. Rather than using the default Router component by react router we will
>>> be using our custom component BrowserRouter [3]. In this we place the
>>> interceptor to be invoked when we are navigating around (push or replace)
>>> [4]. The interceptor [5] will take the tenant domain from the context and
>>> append it to the path. So in each route (when the user navigates to
>>> different pages this will be appended as a query param.
>>>
>>> To retrieve the tenant specific data from the REST API , we will be
>>> getting the tenant domain from the query param and setting it to the
>>> x-wso2-tenant header [6].
>>>
>>> Any thoughts and feedback on this much appreciated.
>>>
>>>
>>> [1] -
>>> https://stackoverflow.com/questions/57757263/how-to-write-an-interceptor-for-react-router/57757921#57757921
>>> [2] -
>>> https://github.com/dushansilva/carbon-apimgt/blob/560b774c10b74c2709c6bf5b9c6ac20ccca6/features/apimgt/org.wso2.carbon.apimgt.store.feature/src/main/resources/store-new/source/src/App.jsx#L96
>>> [3] -
>>> https://github.com/dushansilva/carbon-apimgt/blob/560b774c10b74c2709c6bf5b9c6ac20ccca6/features/apimgt/org.wso2.carbon.apimgt.store.feature/src/main/resources/store-new/source/src/app/CustomRouter/BrowserRouter.jsx#L15
>>> [4] -
>>> https://github.com/dushansilva/carbon-apimgt/blob/560b774c10b74c2709c6bf5b9c6ac20ccca6/features/apimgt/org.wso2.carbon.apimgt.store.feature/src/main/resources/store-new/source/src/app/CustomRouter/BrowserRouter.jsx#L28
>>> [5] -
>>> https://github.com/dushansilva/carbon-apimgt/blob/560b774c10b74c2709c6bf5b9c6ac20ccca6/features/apimgt/org.wso2.carbon.apimgt.store.feature/src/main/resources/store-new/source/src/app/CustomRouter/BrowserRouter.jsx#L43
>>> [6] -
>>> https://github.com/dushansilva/carbon-apimgt/blob/560b774c10b74c2709c6bf5b9c6ac20ccca6/features/apimgt/org.wso2.carbon.apimgt.store.feature/src/main/resources/store-new/source/src/app/data/APIClient.jsx#L163
>>> --
>>> Best Regards
>>> Dushan Silva
>>> Software Engineer
>>>
>>> *WSO2, Inc. *
>>>
>>> lean . enterprise . middleware
>>> Mob: +94 774 979042
>>>
>>
>>
>> --
>> *Kasun Thennakoon* | Senior Software Engineer | WSO2 Inc.
>> (m) +94 711661919 | (w) +94 11 214 5345 | (e) kasu...@wso2.com
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> Best Regards
> Dushan Silva
> Software Engineer
>
> *WSO2, Inc. *
>
> lean . enterprise . middleware
> Mob: +94 774 979042
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Tanya Madurapperuma* | Technical Lead | WSO2 Inc.
(m) +94718184439 | (e) ta...@wso2.com

<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 API Manager 3.0.0 RC3

[Tanya Madurapperuma]

 Oct 25, 2019 at 11:28 AM Mushthaq Rumy 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Tested the following scenarios in both super tenant and tenant.
>>>>>>>>> - API Creation, Publishing, Subscribing and invocation of APIs
>>>>>>>>> - Tested Publisher Access Control
>>>>>>>>> - Tested Store Visibility
>>>>>>>>> - Identity management features such as self sign up, password
>>>>>>>>> reset, password policy, account locking.
>>>>>>>>>
>>>>>>>>> No blockers found. Hence, [+] Stable - go ahead and release.
>>>>>>>>>
>>>>>>>>> Thanks & Regards,
>>>>>>>>> Mushthaq
>>>>>>>>>
>>>>>>>>> On Fri, Oct 25, 2019 at 3:52 AM Samitha Chathuranga <
>>>>>>>>> sami...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> We are pleased to announce the second release candidate of WSO2
>>>>>>>>>> API Manager 3.0.0.
>>>>>>>>>>
>>>>>>>>>> This release fixes the following issues.
>>>>>>>>>>
>>>>>>>>>>- Fixes : product-apim
>>>>>>>>>>
>>>>>>>>>> <https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-24>
>>>>>>>>>>- Fixes : carbon-apimgt
>>>>>>>>>>
>>>>>>>>>> <https://github.com/wso2/carbon-apimgt/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-24+>
>>>>>>>>>>- Fixes : analytics-apim
>>>>>>>>>>
>>>>>>>>>> <https://github.com/wso2/analytics-apim/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+closed%3A2018-09-16..2019-10-24>
>>>>>>>>>>
>>>>>>>>>> Source and distribution,
>>>>>>>>>> Runtime :
>>>>>>>>>> https://github.com/wso2/product-apim/releases/tag/v3.0.0-rc3
>>>>>>>>>> Analytics :
>>>>>>>>>> https://github.com/wso2/analytics-apim/releases/tag/v3.0.0-rc3
>>>>>>>>>> APIM Tooling :
>>>>>>>>>> https://github.com/wso2/product-apim-tooling/releases/tag/v3.0.0-rc
>>>>>>>>>>
>>>>>>>>>> Please download, test the product and vote.
>>>>>>>>>>
>>>>>>>>>> [+] Stable - go ahead and release
>>>>>>>>>> [-] Broken - do not release (explain why)
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> WSO2 API Manager Team
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *Samitha Chathuranga*
>>>>>>>>>> *Senior Software Engineer*, *WSO2 Inc.*
>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>> Mobile: +94715123761
>>>>>>>>>>
>>>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Mushthaq Rumy
>>>>>>>>> *Senior Software Engineer*
>>>>>>>>> Mobile : +94 (0) 779 492140
>>>>>>>>> Email : musht...@wso2.com
>>>>>>>>> WSO2, Inc.; http://wso2.com/
>>>>>>>>> lean . enterprise . middleware.
>>>>>>>>>
>>>>>>>>> <http://wso2.com/signature>
>>>>>>>>> ___
>>>>>>>>> Architecture mailing list
>>>>>>>>> Architecture@wso2.org
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Chamin Dias
>>>>>>>> Mobile : 0716097455
>>>>>>>> Email : cham...@wso2.com
>>>>>>>> LinkedIn : https://www.linkedin.com/in/chamindias
>>>>>>>>
>>>>>>>> ___
>>>>>>>> Dev mailing list
>>>>>>>> d...@wso2.org
>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best Regards
>>>>>>> Dushan Silva
>>>>>>> Software Engineer
>>>>>>>
>>>>>>> *WSO2, Inc. *
>>>>>>>
>>>>>>> lean . enterprise . middleware
>>>>>>> Mob: +94 774 979042
>>>>>>> ___
>>>>>>> Architecture mailing list
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Hasunie Adikari*
>>>>>> Associate Technical Lead
>>>>>> WSO2 Inc.; http://wso2.com
>>>>>> lean.enterprise.middleware
>>>>>> blog http://hasuniea.blogspot.com | https://medium.com/@Hasunie/
>>>>>> Mobile:+94713095876
>>>>>>
>>>>>> ___
>>>>>> Dev mailing list
>>>>>> d...@wso2.org
>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Nalaka Senarathna*
>>>>> *Email : nala...@wso2.com *
>>>>> *Mobile : +94714118474*
>>>>> *web :  https://wso2.com <https://wso2.com>*
>>>>> <https://wso2.com/signature>
>>>>>
>>>>> ___
>>>>> Dev mailing list
>>>>> d...@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>
>>>>
>>>> --
>>>> *Arshardh Ifthikar*
>>>> Software Engineer | WSO2 Inc.
>>>>
>>>> Email: arsha...@wso2.com
>>>> Mobile: +94719806525
>>>> Web: http://wso2.com
>>>>
>>>> <http://wso2.com/signature>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>> *Lakshitha Gunasekara* | Software Engineer | WSO2 Inc.
>>> <http://wso2.com/>
>>> (M)+94 71 542 4498 | (E) lakshi...@wso2.com
>>> <https://wso2.com/signature>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Regards,
>> Chamila Adhikarinayake
>> Associate Technical Lead
>> WSO2, Inc.
>> Mobile - +94712346437
>> Email  - chami...@wso2.com
>> Blog  -  http://helpfromadhi.blogspot.com/
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> Shilmy Hasan
> Software Engineer | WSO2
>
> E-mail :si...@wso2.com
> Phone :0779188653
> web : http://www.wso2.com
>
> [image: https://wso2.com/signature] <https://wso2.com/signature>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
*Tanya Madurapperuma* | Technical Lead | WSO2 Inc.
(m) +94718184439 | (e) ta...@wso2.com

<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] PDF Report Generation for APIM Analytics

[Tanya Madurapperuma]

>>>>> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc
>>>>> Mobile : +94772338839 | fazl...@wso2.com
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> *Harsha Kumara*
>>>>
>>>> Technical Lead, WSO2 Inc.
>>>> Mobile: +94775505618
>>>> Email: hars...@wso2.coim
>>>> Blog: harshcreationz.blogspot.com
>>>>
>>>> GET INTEGRATION AGILE
>>>> Integration Agility for Digitally Driven Business
>>>>
>>>
>>>
>>> --
>>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc.
>>> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>>
>>
>>
>> --
>> *Kasun Thennakoon* | Associate Technical Lead | WSO2 Inc.
>> (m) +94 711661919 | (w) +94 11 214 5345 | (e) kasu...@wso2.com
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
>
> *Harsha Kumara*
>
> Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Email: hars...@wso2.coim
> Blog: harshcreationz.blogspot.com
>
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
>


-- 
*Tanya Madurapperuma* | Technical Lead | WSO2 Inc.
(m) +94718184439 | (e) ta...@wso2.com

<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dashboard] Message queuing mechanism to prevent losing messages in PubSub

[Tanya Madurapperuma]

Pahan : FYI

On Mon, Nov 27, 2017 at 7:57 AM Tanya Madurapperuma  wrote:

> +1 for the implementation.
> One main advantage with the above approach is publisher and subscriber
> widget authors don't need to worry about the load order as it is entirely
> handled by the parent widget component. They just have to write their
> publishing and subscribing logic thinking that subscriber widget will be
> always loaded before the publisher widget.
>
> Thanks,
> Tanya
>
> On Mon, Nov 27, 2017 at 12:34 AM, Nisala Nanayakkara 
> wrote:
>
>> Hi All,
>>
>> Purpose of this mail is to discuss the solution regarding the 'Message
>> queuing mechanism to prevent losing messages in PubSub"*. *Please find
>> the below information in order to get more context regarding the $subject
>> *.*
>>
>> *Problem & C4 solution*
>>
>> Let's consider a situation where there is a dashboard with publisher and
>> subscriber widgets. If the publisher widget is rendered before the
>> subscriber widget, the subscriber widget may miss the initial messages that
>> are published by the publisher. As a real-world example, we can consider a
>> scenario where date picker widget publishes initial date range and the
>> other widgets should be rendered according to that published date range. If
>> the date picker widget is rendered before the other widgets, these widgets
>> will not able to get the published date-range. In C4, we have implemented a
>> feature to control the load order of the widgets. So that we can control
>> the load order of widgets and resolve the above-mentioned problem.
>>
>> *Proposed Solution*
>>
>> In C5 dashboard component implementation, we have used Golden Layout to
>> handle the layouting and rendering of the dashboards. Please refer the mail
>> thread[1] for more information. Because of this reason, we do not have the
>> control over the widget load order in dashboards. So we have come up with
>> the following solution in order to resolve this issue.
>>
>>- Publisher widgets publish messages using its parent(base) widget.
>>Please refer mail thread[2] for more information about parent widget
>>component.
>>- If the dashboard is not initialized, messages will be queued at the
>>widget level and start listening to dashboard initialized event. Once the
>>dashboard is initialized, queued messages will be sent to the respective
>>channel. So that the subscriber widgets can get the published messages
>>without any issue.
>>
>> The above implementation will be available with the stream processor beta
>> version. If you have any concerns or issues. Please feel free to ask.
>>
>> [1] - Mail Subject - [Meeting Notes] Discussion on way forward with
>> Dashboards @ Wed Jun 14, 2017 10am - 11am (IST) (WSO2 Platform Team Group)
>>
>> [2] - Mail Subject - [Dashboard] Introducing a base widget component
>> Thanks,
>> Nisala
>>
>>
>> --
>> *Nisala Niroshana Nanayakkara,*
>> Software Engineer
>> Mobile | +94 717600022
>> WSO2 Inc | http://wso2.com/
>>
>
>
>
> --
> Tanya Madurapperuma
>
> Associate Technical Lead,
> WSO2 Inc. : wso2.com
> Mobile : +94718184439
> Blog : http://tanyamadurapperuma.blogspot.com
>


-- 
*Tanya Madurapperuma* | Technical Lead | WSO2 Inc.
(m) +94718184439 | (e) ta...@wso2.com

<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Renaming APIM Analytics dashboards

[Tanya Madurapperuma]

IMO we should keep the APIM Admin dashboard with the reporting widget and
rename the dashboard to a name like "Report Generation" because all the
other widgets in the Business Analytics dashboard are different from the
reporting widget where they display information while reporting widget
allows to perform an action on top of the widget and generate a report
instead of displaying any information in the widget itself.

Thanks,
Tanya


T

On Tue, Jun 30, 2020 at 10:51 AM Fazlan Nazeem  wrote:

> Hi Rukshan,
>
> If admin has access to the Business Analytics dashboard, shall we move the
> existing widget in *APIM Admin *to Business Analytics Dashboard? That
> would mean we will have 4 dashboards and I can think of the following names.
>
>- *API Analytics*
>- *Application Analytics*
>- *Business Analytics*
>- *Monitoring*
>
>
> On Tue, Jun 30, 2020 at 10:14 AM Rukshan Premathunga 
> wrote:
>
>> Hi All,
>>
>> APIM analytics 3.2.0 introduces a new dashboard to monitor the system.
>> Also, it separates existing 'APIM Publisher' dashboard to manager dashboard
>> and publisher dashboard. We noticed that some of the dashboard names are
>> not meaningful and better to rename them in order to represent its data.
>>
>> Existing Dsahbaord names:
>>
>>- APIM Admin
>>- Provide system report generating for admin users
>>- APIM Developer Portal
>>- Provide Application-level stats to app developers
>>- Manager Analytics
>>- Provide stat for manager persona. Visible all the APIs and Apps
>>   regardless of the access control in the current tenant.
>>- Monitoring
>>- Provide a short period of time analysis to monitor the system and
>>   take actions.
>>- Publisher Analytics
>>- Provide stat for publisher persona. Visible all the APIs and Apps
>>   applying access control.
>>
>> Suggestions based on previous reviews:
>>
>>- APIM Admin
>>- APIM Developer Portal
>>   - *Application Analytics*
>>- Manager Analytics
>>   - *Business Analytics*
>>- Monitoring
>>- Publisher Analytics
>>
>> Your thoughts and suggestions are highly appreciated.
>>
>> Thanks and Regards
>> --
>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc.
>> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> Thanks & Regards,
>
> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc
> Mobile : +94772338839 | fazl...@wso2.com
>
>
>

-- 
*Tanya Madurapperuma* | Technical Lead | WSO2 Inc.
(m) +94718184439 | (e) ta...@wso2.com

<http://wso2.com/signature>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture