date:20170828

Re: [Dev] Dashboard Component - Hierarchical Page Support

2017-08-28 Thread Lasantha Samarakoon

IMHO it is better to keep the layout information along with the page
contents in the dashboard.json file. Separating those information into
another set of files will only complex the entire flow.

In order to reduce the bulkiness of the dashboard.json what we can do is
remove all the unnecessary GoldenLayout properties from the page
configuration section. We can add them at the code level on runtime. Only
the limited set of those properties which the users really need to
manipulate should goes along with the page content. 

*Lasantha Samarakoon* | Software Engineer
WSO2, Inc.
#20, Palm Grove, Colombo 03, Sri Lanka
Mobile: +94 (71) 214 1576
Email:  lasant...@wso2.com
Web:www.wso2.com

lean . enterprise . middleware

On Tue, Aug 29, 2017 at 11:55 AM, Nisala Nanayakkara 
wrote:

> Hi Nipuna,
>
> We do not keep layout information separately in dashboard JSON as in the
> previous version. Since layouting is handled by the GoldenLayout framework,
> we keep the dashboard content and layouting information in the "content"
> object of dashboard JSON. Since this is somewhat bound to the GoldenLayout
> framework, it is bit difficult to separate the layout information into a
> separate file.
>
> Thanks,
> Nisala
>
> On Tue, Aug 29, 2017 at 10:50 AM, Nipuna Chandradasa 
> wrote:
>
>> Hi Nisala,
>>
>> In previous dashboard.json we had a problem like we have bulky
>> information(ex:- layout) inside the same JSON. So i assume inside the
>> content attribute which holds the page contents we are going to keep these
>> information? if it Is there's a plan to move these information to a
>> separate file?
>>
>> Other than that i'm +1 for above mentioned JSON format.
>>
>> Thank you,
>>
>> On Tue, Aug 29, 2017 at 9:44 AM, Nisala Nanayakkara 
>> wrote:
>>
>>> Hi Udara,
>>>
>>> Please find my comments inline.
>>>
>>> Assume we have a page2, which is going to be listed under page0>page1.
>>> So are we going to have a object like "page0/page1/page2" : {}
>>>  ? This bit is not clear in the above.
>>>
>>> Yes. we are going to keep an object as mentioned above.
>>>
>>> Also better if you can explain what is a *page resource URL* so others
>>> can understand.
>>>
>>> It simply means the resource path of the page URL.  Ex:-
>>> "page0/page1/page2"
>>>
>>> {
>>> "id": "1",
>>> "url": "sampledashboard",
>>> "name": "Sample Dashboard",
>>> "version": "2.0.0",
>>> "description": "Lorem ipsum dolor sit amet DAS",
>>> "owner": "admin",
>>> "lastUpdatedBy": "admin",
>>> "createdTime": 150282009,
>>> "lastUpdatedTime": 1502820091112,
>>> "isShared": false,
>>> "parentId": "1",
>>>
>>> Yes. We are going to have a dashboard to dashboard relationship. As an
>>> example, if someone personalizes a dashboard and save it, we are going
>>> maintain its original dashboard id as the parentId.
>>>
>>> Thanks,
>>> Nisala
>>>
>>>
>>> On Tue, Aug 29, 2017 at 8:37 AM, Udara Rathnayake 
>>> wrote:
>>>
 Hi Nisala,

 Assume we have a page2, which is going to be listed under page0>page1.
 So are we going to have a object like "page0/page1/page2" : {}
  ? This bit is not clear in the above.

 Also better if you can explain what is a *page resource URL* so
 others can understand.


 On Mon, Aug 28, 2017 at 11:26 PM, Nisala Nanayakkara 
 wrote:

> Hi all,
>
> We are in the process of re-writing dashboard component using React.
> Currently we have dashboard view component with following features,
>
>- Dashboard listing (will retrieve the dashboard from the DB and
>list down)
>- Backend API support for dashboard CRUD activities.
>- Dashboard view support (This will retrieve the selected
>dashboard from DB and render using Golden Layout)
>- Multiple pages support for dashboards (This will introduce
>multiple pages at the same level, We need to support hierarchical page
>support )
>- Internal routing between dashboard listing and dashboard view
>
> Since we are using the golden layout for layouting, we keep the
> content of the each page with respect to page resource url. When we are
> going to implement the hierarchical pages support, we are going to process
> these page urls and display the hierarchical menu according these page
> urls. Please find the sample dashboard json given below,
>
>> {
>> "id": "1",
>> "url": "sampledashboard",
>> "name": "Sample Dashboard",
>> "version": "2.0.0",
>> "description": "Lorem ipsum dolor sit amet DAS",
>> "owner": "admin",
>> "lastUpdatedBy": "admin",
>> "createdTime": 150282009,
>> "lastUpdatedTime": 1502820091112,
>> "isShared": false,
>> "parentId": "1",
>>
> Also what is the use of parentId here?

>>>

Re: [Dev] Dashboard Component - Hierarchical Page Support

2017-08-28 Thread Nisala Nanayakkara

Hi Nipuna,

We do not keep layout information separately in dashboard JSON as in the
previous version. Since layouting is handled by the GoldenLayout framework,
we keep the dashboard content and layouting information in the "content"
object of dashboard JSON. Since this is somewhat bound to the GoldenLayout
framework, it is bit difficult to separate the layout information into a
separate file.

Thanks,
Nisala

On Tue, Aug 29, 2017 at 10:50 AM, Nipuna Chandradasa 
wrote:

> Hi Nisala,
>
> In previous dashboard.json we had a problem like we have bulky
> information(ex:- layout) inside the same JSON. So i assume inside the
> content attribute which holds the page contents we are going to keep these
> information? if it Is there's a plan to move these information to a
> separate file?
>
> Other than that i'm +1 for above mentioned JSON format.
>
> Thank you,
>
> On Tue, Aug 29, 2017 at 9:44 AM, Nisala Nanayakkara 
> wrote:
>
>> Hi Udara,
>>
>> Please find my comments inline.
>>
>> Assume we have a page2, which is going to be listed under page0>page1. So
>> are we going to have a object like "page0/page1/page2" : {}
>>  ? This bit is not clear in the above.
>>
>> Yes. we are going to keep an object as mentioned above.
>>
>> Also better if you can explain what is a *page resource URL* so others
>> can understand.
>>
>> It simply means the resource path of the page URL.  Ex:-
>> "page0/page1/page2"
>>
>> {
>> "id": "1",
>> "url": "sampledashboard",
>> "name": "Sample Dashboard",
>> "version": "2.0.0",
>> "description": "Lorem ipsum dolor sit amet DAS",
>> "owner": "admin",
>> "lastUpdatedBy": "admin",
>> "createdTime": 150282009,
>> "lastUpdatedTime": 1502820091112,
>> "isShared": false,
>> "parentId": "1",
>>
>> Yes. We are going to have a dashboard to dashboard relationship. As an
>> example, if someone personalizes a dashboard and save it, we are going
>> maintain its original dashboard id as the parentId.
>>
>> Thanks,
>> Nisala
>>
>>
>> On Tue, Aug 29, 2017 at 8:37 AM, Udara Rathnayake 
>> wrote:
>>
>>> Hi Nisala,
>>>
>>> Assume we have a page2, which is going to be listed under page0>page1.
>>> So are we going to have a object like "page0/page1/page2" : {}
>>>  ? This bit is not clear in the above.
>>>
>>> Also better if you can explain what is a *page resource URL* so others
>>> can understand.
>>>
>>>
>>> On Mon, Aug 28, 2017 at 11:26 PM, Nisala Nanayakkara 
>>> wrote:
>>>
 Hi all,

 We are in the process of re-writing dashboard component using React.
 Currently we have dashboard view component with following features,

- Dashboard listing (will retrieve the dashboard from the DB and
list down)
- Backend API support for dashboard CRUD activities.
- Dashboard view support (This will retrieve the selected dashboard
from DB and render using Golden Layout)
- Multiple pages support for dashboards (This will introduce
multiple pages at the same level, We need to support hierarchical page
support )
- Internal routing between dashboard listing and dashboard view

 Since we are using the golden layout for layouting, we keep the content
 of the each page with respect to page resource url. When we are going to
 implement the hierarchical pages support, we are going to process these
 page urls and display the hierarchical menu according these page urls.
 Please find the sample dashboard json given below,

> {
> "id": "1",
> "url": "sampledashboard",
> "name": "Sample Dashboard",
> "version": "2.0.0",
> "description": "Lorem ipsum dolor sit amet DAS",
> "owner": "admin",
> "lastUpdatedBy": "admin",
> "createdTime": 150282009,
> "lastUpdatedTime": 1502820091112,
> "isShared": false,
> "parentId": "1",
>
 Also what is the use of parentId here?
>>>
>>> Are we going to have any dashboard to dashboard relationship? 
>>>
 "content": [
> {
> "page0": {
> *content of page0*
> },
> "page1": {
> *content of page1*
> }
> }
> ]
> }

 So we do not keep any mapping between pages and its hierarchy as in the
 previous versions of the dashboard component. But we may need to maintain
 some additional attributes such as Page title, isHidden and etc wrt page
 URL. In that case, I think it is better to maintain a separate mapping
 between these attributes and page URLs as in the previous dashboard
 component. Please find the sample dashboard json given below.

> {
> "id": "1",
> "url": "sampledashboard",
> "name": "

Re: [Dev] Dashboard Component - Hierarchical Page Support

2017-08-28 Thread Nisala Nanayakkara

Hi Udara,

Ok. above sample doesn't explain this :) both id and parentId are same

Yes. This sample dashboard json is not personalized. So we keep the
parentId as same as its id :)

Thanks,
Nisala

On Tue, Aug 29, 2017 at 11:36 AM, Udara Rathnayake  wrote:

>
>
> On Tue, Aug 29, 2017 at 9:44 AM, Nisala Nanayakkara 
> wrote:
>
>> Hi Udara,
>>
>> Please find my comments inline.
>>
>> Assume we have a page2, which is going to be listed under page0>page1. So
>> are we going to have a object like "page0/page1/page2" : {}
>>  ? This bit is not clear in the above.
>>
>> Yes. we are going to keep an object as mentioned above.
>>
>> Also better if you can explain what is a *page resource URL* so others
>> can understand.
>>
>> It simply means the resource path of the page URL.  Ex:-
>> "page0/page1/page2"
>>
>> {
>> "id": "1",
>> "url": "sampledashboard",
>> "name": "Sample Dashboard",
>> "version": "2.0.0",
>> "description": "Lorem ipsum dolor sit amet DAS",
>> "owner": "admin",
>> "lastUpdatedBy": "admin",
>> "createdTime": 150282009,
>> "lastUpdatedTime": 1502820091112,
>> "isShared": false,
>> "parentId": "1",
>>
>> Yes. We are going to have a dashboard to dashboard relationship. As an
>> example, if someone personalizes a dashboard and save it, we are going
>> maintain its original dashboard id as the parentId.
>>
> Ok. above sample doesn't explain this :) both id and parentId are same
>
>
>>
>> Thanks,
>> Nisala
>>
>>
>> On Tue, Aug 29, 2017 at 8:37 AM, Udara Rathnayake 
>> wrote:
>>
>>> Hi Nisala,
>>>
>>> Assume we have a page2, which is going to be listed under page0>page1.
>>> So are we going to have a object like "page0/page1/page2" : {}
>>>  ? This bit is not clear in the above.
>>>
>>> Also better if you can explain what is a *page resource URL* so others
>>> can understand.
>>>
>>>
>>> On Mon, Aug 28, 2017 at 11:26 PM, Nisala Nanayakkara 
>>> wrote:
>>>
 Hi all,

 We are in the process of re-writing dashboard component using React.
 Currently we have dashboard view component with following features,

- Dashboard listing (will retrieve the dashboard from the DB and
list down)
- Backend API support for dashboard CRUD activities.
- Dashboard view support (This will retrieve the selected dashboard
from DB and render using Golden Layout)
- Multiple pages support for dashboards (This will introduce
multiple pages at the same level, We need to support hierarchical page
support )
- Internal routing between dashboard listing and dashboard view

 Since we are using the golden layout for layouting, we keep the content
 of the each page with respect to page resource url. When we are going to
 implement the hierarchical pages support, we are going to process these
 page urls and display the hierarchical menu according these page urls.
 Please find the sample dashboard json given below,

> {
> "id": "1",
> "url": "sampledashboard",
> "name": "Sample Dashboard",
> "version": "2.0.0",
> "description": "Lorem ipsum dolor sit amet DAS",
> "owner": "admin",
> "lastUpdatedBy": "admin",
> "createdTime": 150282009,
> "lastUpdatedTime": 1502820091112,
> "isShared": false,
> "parentId": "1",
>
 Also what is the use of parentId here?
>>>
>>> Are we going to have any dashboard to dashboard relationship? 
>>>
 "content": [
> {
> "page0": {
> *content of page0*
> },
> "page1": {
> *content of page1*
> }
> }
> ]
> }



 So we do not keep any mapping between pages and its hierarchy as in the
 previous versions of the dashboard component. But we may need to maintain
 some additional attributes such as Page title, isHidden and etc wrt page
 URL. In that case, I think it is better to maintain a separate mapping
 between these attributes and page URLs as in the previous dashboard
 component. Please find the sample dashboard json given below.

> {
> "id": "1",
> "url": "sampledashboard",
> "name": "Sample Dashboard",
> "version": "2.0.0",
> "description": "Lorem ipsum dolor sit amet DAS",
> "owner": "admin",
> "lastUpdatedBy": "admin",
> "createdTime": 150282009,
> "lastUpdatedTime": 1502820091112,
> "isShared": false,
> "parentId": "1",
>
>
>
>
>
>
>
>
>
> *"menu": {"page0": {"ishidden": false,
> "title": "Page 0"},"page1": {"ishidden":
> false

Re: [Dev] Dashboard Component - Hierarchical Page Support

2017-08-28 Thread Udara Rathnayake

On Tue, Aug 29, 2017 at 9:44 AM, Nisala Nanayakkara  wrote:

> Hi Udara,
>
> Please find my comments inline.
>
> Assume we have a page2, which is going to be listed under page0>page1. So
> are we going to have a object like "page0/page1/page2" : {}
>  ? This bit is not clear in the above.
>
> Yes. we are going to keep an object as mentioned above.
>
> Also better if you can explain what is a *page resource URL* so others
> can understand.
>
> It simply means the resource path of the page URL.  Ex:-
> "page0/page1/page2"
>
> {
> "id": "1",
> "url": "sampledashboard",
> "name": "Sample Dashboard",
> "version": "2.0.0",
> "description": "Lorem ipsum dolor sit amet DAS",
> "owner": "admin",
> "lastUpdatedBy": "admin",
> "createdTime": 150282009,
> "lastUpdatedTime": 1502820091112,
> "isShared": false,
> "parentId": "1",
>
> Yes. We are going to have a dashboard to dashboard relationship. As an
> example, if someone personalizes a dashboard and save it, we are going
> maintain its original dashboard id as the parentId.
>
Ok. above sample doesn't explain this :) both id and parentId are same


>
> Thanks,
> Nisala
>
>
> On Tue, Aug 29, 2017 at 8:37 AM, Udara Rathnayake  wrote:
>
>> Hi Nisala,
>>
>> Assume we have a page2, which is going to be listed under page0>page1. So
>> are we going to have a object like "page0/page1/page2" : {}
>>  ? This bit is not clear in the above.
>>
>> Also better if you can explain what is a *page resource URL* so others
>> can understand.
>>
>>
>> On Mon, Aug 28, 2017 at 11:26 PM, Nisala Nanayakkara 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are in the process of re-writing dashboard component using React.
>>> Currently we have dashboard view component with following features,
>>>
>>>- Dashboard listing (will retrieve the dashboard from the DB and
>>>list down)
>>>- Backend API support for dashboard CRUD activities.
>>>- Dashboard view support (This will retrieve the selected dashboard
>>>from DB and render using Golden Layout)
>>>- Multiple pages support for dashboards (This will introduce
>>>multiple pages at the same level, We need to support hierarchical page
>>>support )
>>>- Internal routing between dashboard listing and dashboard view
>>>
>>> Since we are using the golden layout for layouting, we keep the content
>>> of the each page with respect to page resource url. When we are going to
>>> implement the hierarchical pages support, we are going to process these
>>> page urls and display the hierarchical menu according these page urls.
>>> Please find the sample dashboard json given below,
>>>
 {
 "id": "1",
 "url": "sampledashboard",
 "name": "Sample Dashboard",
 "version": "2.0.0",
 "description": "Lorem ipsum dolor sit amet DAS",
 "owner": "admin",
 "lastUpdatedBy": "admin",
 "createdTime": 150282009,
 "lastUpdatedTime": 1502820091112,
 "isShared": false,
 "parentId": "1",

>>> Also what is the use of parentId here?
>>
>> Are we going to have any dashboard to dashboard relationship? 
>>
>>> "content": [
 {
 "page0": {
 *content of page0*
 },
 "page1": {
 *content of page1*
 }
 }
 ]
 }
>>>
>>>
>>>
>>> So we do not keep any mapping between pages and its hierarchy as in the
>>> previous versions of the dashboard component. But we may need to maintain
>>> some additional attributes such as Page title, isHidden and etc wrt page
>>> URL. In that case, I think it is better to maintain a separate mapping
>>> between these attributes and page URLs as in the previous dashboard
>>> component. Please find the sample dashboard json given below.
>>>
 {
 "id": "1",
 "url": "sampledashboard",
 "name": "Sample Dashboard",
 "version": "2.0.0",
 "description": "Lorem ipsum dolor sit amet DAS",
 "owner": "admin",
 "lastUpdatedBy": "admin",
 "createdTime": 150282009,
 "lastUpdatedTime": 1502820091112,
 "isShared": false,
 "parentId": "1",









 *"menu": {"page0": {"ishidden": false,
 "title": "Page 0"},"page1": {"ishidden":
 false,"title": "Page 1"}}*,
 "content": [
 {
 "page0": {},
 "page1": {}
 }
 ]
 }

>>> Because It will give a clear separation between dashboard content and
>>> the pages’ menu attributes. WDYT?
>>>
>>> Thanks,
>>> Nisala
>>>
>>> --
>>> *Nisala Niroshana Nanayakkara,*
>>> Software Engineer
>>> Mobile | +94 7176

Re: [Dev] Dashboard Component - Hierarchical Page Support

2017-08-28 Thread Nipuna Chandradasa

Hi Nisala,

In previous dashboard.json we had a problem like we have bulky
information(ex:- layout) inside the same JSON. So i assume inside the
content attribute which holds the page contents we are going to keep these
information? if it Is there's a plan to move these information to a
separate file?

Other than that i'm +1 for above mentioned JSON format.

Thank you,

On Tue, Aug 29, 2017 at 9:44 AM, Nisala Nanayakkara  wrote:

> Hi Udara,
>
> Please find my comments inline.
>
> Assume we have a page2, which is going to be listed under page0>page1. So
> are we going to have a object like "page0/page1/page2" : {}
>  ? This bit is not clear in the above.
>
> Yes. we are going to keep an object as mentioned above.
>
> Also better if you can explain what is a *page resource URL* so others
> can understand.
>
> It simply means the resource path of the page URL.  Ex:-
> "page0/page1/page2"
>
> {
> "id": "1",
> "url": "sampledashboard",
> "name": "Sample Dashboard",
> "version": "2.0.0",
> "description": "Lorem ipsum dolor sit amet DAS",
> "owner": "admin",
> "lastUpdatedBy": "admin",
> "createdTime": 150282009,
> "lastUpdatedTime": 1502820091112,
> "isShared": false,
> "parentId": "1",
>
> Yes. We are going to have a dashboard to dashboard relationship. As an
> example, if someone personalizes a dashboard and save it, we are going
> maintain its original dashboard id as the parentId.
>
> Thanks,
> Nisala
>
>
> On Tue, Aug 29, 2017 at 8:37 AM, Udara Rathnayake  wrote:
>
>> Hi Nisala,
>>
>> Assume we have a page2, which is going to be listed under page0>page1. So
>> are we going to have a object like "page0/page1/page2" : {}
>>  ? This bit is not clear in the above.
>>
>> Also better if you can explain what is a *page resource URL* so others
>> can understand.
>>
>>
>> On Mon, Aug 28, 2017 at 11:26 PM, Nisala Nanayakkara 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are in the process of re-writing dashboard component using React.
>>> Currently we have dashboard view component with following features,
>>>
>>>- Dashboard listing (will retrieve the dashboard from the DB and
>>>list down)
>>>- Backend API support for dashboard CRUD activities.
>>>- Dashboard view support (This will retrieve the selected dashboard
>>>from DB and render using Golden Layout)
>>>- Multiple pages support for dashboards (This will introduce
>>>multiple pages at the same level, We need to support hierarchical page
>>>support )
>>>- Internal routing between dashboard listing and dashboard view
>>>
>>> Since we are using the golden layout for layouting, we keep the content
>>> of the each page with respect to page resource url. When we are going to
>>> implement the hierarchical pages support, we are going to process these
>>> page urls and display the hierarchical menu according these page urls.
>>> Please find the sample dashboard json given below,
>>>
 {
 "id": "1",
 "url": "sampledashboard",
 "name": "Sample Dashboard",
 "version": "2.0.0",
 "description": "Lorem ipsum dolor sit amet DAS",
 "owner": "admin",
 "lastUpdatedBy": "admin",
 "createdTime": 150282009,
 "lastUpdatedTime": 1502820091112,
 "isShared": false,
 "parentId": "1",

>>> Also what is the use of parentId here?
>>
>> Are we going to have any dashboard to dashboard relationship? 
>>
>>> "content": [
 {
 "page0": {
 *content of page0*
 },
 "page1": {
 *content of page1*
 }
 }
 ]
 }
>>>
>>>
>>>
>>> So we do not keep any mapping between pages and its hierarchy as in the
>>> previous versions of the dashboard component. But we may need to maintain
>>> some additional attributes such as Page title, isHidden and etc wrt page
>>> URL. In that case, I think it is better to maintain a separate mapping
>>> between these attributes and page URLs as in the previous dashboard
>>> component. Please find the sample dashboard json given below.
>>>
 {
 "id": "1",
 "url": "sampledashboard",
 "name": "Sample Dashboard",
 "version": "2.0.0",
 "description": "Lorem ipsum dolor sit amet DAS",
 "owner": "admin",
 "lastUpdatedBy": "admin",
 "createdTime": 150282009,
 "lastUpdatedTime": 1502820091112,
 "isShared": false,
 "parentId": "1",









 *"menu": {"page0": {"ishidden": false,
 "title": "Page 0"},"page1": {"ishidden":
 false,"title": "Page 1"}}*,
 "content": [
 {
 "page0": {},

Re: [Dev] Dashboard Component - Hierarchical Page Support

2017-08-28 Thread Nisala Nanayakkara

Hi Udara,

Please find my comments inline.

Assume we have a page2, which is going to be listed under page0>page1. So
are we going to have a object like "page0/page1/page2" : {}
 ? This bit is not clear in the above.

Yes. we are going to keep an object as mentioned above.

Also better if you can explain what is a *page resource URL* so others can
understand.

It simply means the resource path of the page URL.  Ex:- "page0/page1/page2"

{
"id": "1",
"url": "sampledashboard",
"name": "Sample Dashboard",
"version": "2.0.0",
"description": "Lorem ipsum dolor sit amet DAS",
"owner": "admin",
"lastUpdatedBy": "admin",
"createdTime": 150282009,
"lastUpdatedTime": 1502820091112,
"isShared": false,
"parentId": "1",

Yes. We are going to have a dashboard to dashboard relationship. As an
example, if someone personalizes a dashboard and save it, we are going
maintain its original dashboard id as the parentId.

Thanks,
Nisala


On Tue, Aug 29, 2017 at 8:37 AM, Udara Rathnayake  wrote:

> Hi Nisala,
>
> Assume we have a page2, which is going to be listed under page0>page1. So
> are we going to have a object like "page0/page1/page2" : {}
>  ? This bit is not clear in the above.
>
> Also better if you can explain what is a *page resource URL* so others
> can understand.
>
>
> On Mon, Aug 28, 2017 at 11:26 PM, Nisala Nanayakkara 
> wrote:
>
>> Hi all,
>>
>> We are in the process of re-writing dashboard component using React.
>> Currently we have dashboard view component with following features,
>>
>>- Dashboard listing (will retrieve the dashboard from the DB and list
>>down)
>>- Backend API support for dashboard CRUD activities.
>>- Dashboard view support (This will retrieve the selected dashboard
>>from DB and render using Golden Layout)
>>- Multiple pages support for dashboards (This will introduce multiple
>>pages at the same level, We need to support hierarchical page support )
>>- Internal routing between dashboard listing and dashboard view
>>
>> Since we are using the golden layout for layouting, we keep the content
>> of the each page with respect to page resource url. When we are going to
>> implement the hierarchical pages support, we are going to process these
>> page urls and display the hierarchical menu according these page urls.
>> Please find the sample dashboard json given below,
>>
>>> {
>>> "id": "1",
>>> "url": "sampledashboard",
>>> "name": "Sample Dashboard",
>>> "version": "2.0.0",
>>> "description": "Lorem ipsum dolor sit amet DAS",
>>> "owner": "admin",
>>> "lastUpdatedBy": "admin",
>>> "createdTime": 150282009,
>>> "lastUpdatedTime": 1502820091112,
>>> "isShared": false,
>>> "parentId": "1",
>>>
>> Also what is the use of parentId here?
>
> Are we going to have any dashboard to dashboard relationship? 
>
>> "content": [
>>> {
>>> "page0": {
>>> *content of page0*
>>> },
>>> "page1": {
>>> *content of page1*
>>> }
>>> }
>>> ]
>>> }
>>
>>
>>
>> So we do not keep any mapping between pages and its hierarchy as in the
>> previous versions of the dashboard component. But we may need to maintain
>> some additional attributes such as Page title, isHidden and etc wrt page
>> URL. In that case, I think it is better to maintain a separate mapping
>> between these attributes and page URLs as in the previous dashboard
>> component. Please find the sample dashboard json given below.
>>
>>> {
>>> "id": "1",
>>> "url": "sampledashboard",
>>> "name": "Sample Dashboard",
>>> "version": "2.0.0",
>>> "description": "Lorem ipsum dolor sit amet DAS",
>>> "owner": "admin",
>>> "lastUpdatedBy": "admin",
>>> "createdTime": 150282009,
>>> "lastUpdatedTime": 1502820091112,
>>> "isShared": false,
>>> "parentId": "1",
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *"menu": {"page0": {"ishidden": false,
>>> "title": "Page 0"},"page1": {"ishidden":
>>> false,"title": "Page 1"}}*,
>>> "content": [
>>> {
>>> "page0": {},
>>> "page1": {}
>>> }
>>> ]
>>> }
>>>
>> Because It will give a clear separation between dashboard content and the
>> pages’ menu attributes. WDYT?
>>
>> Thanks,
>> Nisala
>>
>> --
>> *Nisala Niroshana Nanayakkara,*
>> Software Engineer
>> Mobile | +94 717600022
>> WSO2 Inc | http://wso2.com/
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Regards,
> UdaraR 
>



-- 
*Nisala Niroshana Nanayakkara,*
Software Engineer
Mobile | +94 717600022
WSO2 Inc

Re: [Dev] Dashboard Component - Hierarchical Page Support

2017-08-28 Thread Udara Rathnayake

Hi Nisala,

Assume we have a page2, which is going to be listed under page0>page1. So
are we going to have a object like "page0/page1/page2" : {}
 ? This bit is not clear in the above.

Also better if you can explain what is a *page resource URL* so others can
understand.


On Mon, Aug 28, 2017 at 11:26 PM, Nisala Nanayakkara 
wrote:

> Hi all,
>
> We are in the process of re-writing dashboard component using React.
> Currently we have dashboard view component with following features,
>
>- Dashboard listing (will retrieve the dashboard from the DB and list
>down)
>- Backend API support for dashboard CRUD activities.
>- Dashboard view support (This will retrieve the selected dashboard
>from DB and render using Golden Layout)
>- Multiple pages support for dashboards (This will introduce multiple
>pages at the same level, We need to support hierarchical page support )
>- Internal routing between dashboard listing and dashboard view
>
> Since we are using the golden layout for layouting, we keep the content of
> the each page with respect to page resource url. When we are going to
> implement the hierarchical pages support, we are going to process these
> page urls and display the hierarchical menu according these page urls.
> Please find the sample dashboard json given below,
>
>> {
>> "id": "1",
>> "url": "sampledashboard",
>> "name": "Sample Dashboard",
>> "version": "2.0.0",
>> "description": "Lorem ipsum dolor sit amet DAS",
>> "owner": "admin",
>> "lastUpdatedBy": "admin",
>> "createdTime": 150282009,
>> "lastUpdatedTime": 1502820091112,
>> "isShared": false,
>> "parentId": "1",
>>
> Also what is the use of parentId here?

Are we going to have any dashboard to dashboard relationship? 

> "content": [
>> {
>> "page0": {
>> *content of page0*
>> },
>> "page1": {
>> *content of page1*
>> }
>> }
>> ]
>> }
>
>
>
> So we do not keep any mapping between pages and its hierarchy as in the
> previous versions of the dashboard component. But we may need to maintain
> some additional attributes such as Page title, isHidden and etc wrt page
> URL. In that case, I think it is better to maintain a separate mapping
> between these attributes and page URLs as in the previous dashboard
> component. Please find the sample dashboard json given below.
>
>> {
>> "id": "1",
>> "url": "sampledashboard",
>> "name": "Sample Dashboard",
>> "version": "2.0.0",
>> "description": "Lorem ipsum dolor sit amet DAS",
>> "owner": "admin",
>> "lastUpdatedBy": "admin",
>> "createdTime": 150282009,
>> "lastUpdatedTime": 1502820091112,
>> "isShared": false,
>> "parentId": "1",
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *"menu": {"page0": {"ishidden": false,
>> "title": "Page 0"},"page1": {"ishidden":
>> false,"title": "Page 1"}}*,
>> "content": [
>> {
>> "page0": {},
>> "page1": {}
>> }
>> ]
>> }
>>
> Because It will give a clear separation between dashboard content and the
> pages’ menu attributes. WDYT?
>
> Thanks,
> Nisala
>
> --
> *Nisala Niroshana Nanayakkara,*
> Software Engineer
> Mobile | +94 717600022
> WSO2 Inc | http://wso2.com/
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,
UdaraR 
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Help required

2017-08-28 Thread Malaka Silva

Hi Amit,

Please find my comments inline.

On Mon, Aug 28, 2017 at 9:17 PM, Amit Rajvanshi 
wrote:

> Hi Malaka,
>
> I am trying to copy a file without processing.
>
You can use file connector copy operation for this [1]


> Output file which I recieve on another location using vfs contains envelop
> and body and actual content inside the body tag.
>
Reading a file can be done with read operation [2]

> I hope it clear your doubt.
>
> Regards,
> Amit Rajvanshi
>
>
>
[1]
https://docs.wso2.com/display/ESBCONNECTORS/Working+with+the+File+Connector+Version+2#WorkingwiththeFileConnectorVersion2-copy
[2]
https://docs.wso2.com/display/ESBCONNECTORS/Working+with+the+File+Connector+Version+2#WorkingwiththeFileConnectorVersion2-read
[3]
https://store.wso2.com/store/assets/esbconnector/details/48bab332-c6a6-4f5a-9b79-17e29c7ad4c6


>  Original message 
> From: Malaka Silva 
> Date: 28/08/17 21:05 (GMT+05:30)
> To: Amit Rajvanshi 
> Cc: WSO2 Developers' List 
> Subject: Re: Help required
>
> Sorry your question is not clear for me. Are you simply trying to copy a
> file without processing? What do you mean by adding content to output.xml?
>
> On Mon, Aug 28, 2017 at 6:16 PM, Amit Rajvanshi 
> wrote:
>
>> Hi Malaka,
>>
>>
>>
>> I am trying implement pure messaging solution like copy one xml file from
>> one sftp location and transfer it to another sftp location without any
>> change.
>>
>> However in the output xml message envelop and body is being added to the
>> message.
>>
>> For example:
>>
>>
>>
>> http://schemas.
>> xmlsoap.org/soap/envelope/">
>>
>> 
>>
>> Original content
>>
>> 
>>
>> 
>>
>>
>>
>> Inbound endpoint I have set content type as application/xml
>>
>> application/*xml*> parameter>
>>
>>
>>
>> I need to keep it application/xml because xml validation is required
>> before processing.
>>
>> Could you please help me if it is possible to send the file without body
>> and envelop.
>>
>>
>>
>> Best regards,
>> *Amit Rajvanshi*
>>
>> *Technical Consultant*
>> *Office:  *+91-120-4737401 <+91%20120%20473%207401>
>>
>> *Mobile*: +91 9871001235 <+91%2098710%2001235>
>>
>> *Email*:arajvan...@salmon.com
>>
>> [image: cid:image003.png@01D2CA89.60AB8730] 
>>
>>
>>
>> *[image: cid:image004.jpg@01D2CA89.60AB8730]*
>>  *[image:
>> cid:image005.jpg@01D2CA89.60AB8730]*
>>  *[image:
>> cid:image006.jpg@01D2CA89.60AB8730]*
>>  *[image:
>> cid:image007.jpg@01D2CA89.60AB8730]*
>>  *[image:
>> cid:image008.jpg@01D2CA89.60AB8730]*
>>  *[image:
>> cid:image009.jpg@01D2CA89.60AB8730]*
>>  *[image:
>> cid:image010.jpg@01D2CA89.60AB8730]*
>> 
>>
>>
>>
>> Information contained in this e-mail and any attachments is confidential
>> and intended for the use of the addressee only. Dissemination,
>> distribution, copying or use of this communication without prior permission
>> of the addressee is strictly prohibited. If you have received this
>> transmission in error, please advise the originator by reply e-mail and
>> delete it. Thank you. Salmon India’s Registered Address is: B-13, Sector
>> 57, Noida (U.P.) 201301. Registered in India U72200DL2003PTC120356.
>>
>>
>> Information contained in this e-mail and any attachments is confidential
>> and intended for the use of the addressee only. Dissemination,
>> distribution, copying or use of this communication without prior permission
>> of the addressee is strictly prohibited. If you have received this
>> transmission in error, please advise the originator by reply e-mail and
>> delete it. Thank you. Salmon India’s Registered Address is: B-13, Sector
>> 57, Noida (U.P.) 201301. Registered in India U72200DL2003PTC120356.
>>
>
>
>
> --
>
> Best Regards,
>
> Malaka Silva
> Associate Director / Architect
> M: +94 777 219 791 <077%20721%209791>
> Tel : 94 11 214 5345
> Fax :94 11 2145300 <011%202%20145300>
> Skype : malaka.sampath.silva
> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
> Blog : http://mrmalakasilva.blogspot.com/
>
> WSO2, Inc.
> lean . enterprise . middleware
> https://wso2.com/signature
> http://www.wso2.com/about/team/malaka-silva/
> 
> https://store.wso2.com/store/
>
> Don't make Trees rare, we should keep them with care
> Information contained in this e-mail and any attachments is confidential
> and intended for the use of the addressee only. Dissemination,
> distribution, copying or use of this communication without prior permission
> of the addressee is strictly prohibited. If you have received this
> transmission in error, please advise the originator by reply e-mail and
> delete it. Thank you. Salmon India’s Registered Address is: B-13, Sector
> 57, Noida (U.P.) 201301

[Dev] Dashboard Component - Hierarchical Page Support

2017-08-28 Thread Nisala Nanayakkara

Hi all,

We are in the process of re-writing dashboard component using React.
Currently we have dashboard view component with following features,

   - Dashboard listing (will retrieve the dashboard from the DB and list
   down)
   - Backend API support for dashboard CRUD activities.
   - Dashboard view support (This will retrieve the selected dashboard from
   DB and render using Golden Layout)
   - Multiple pages support for dashboards (This will introduce multiple
   pages at the same level, We need to support hierarchical page support )
   - Internal routing between dashboard listing and dashboard view

Since we are using the golden layout for layouting, we keep the content of
the each page with respect to page resource url. When we are going to
implement the hierarchical pages support, we are going to process these
page urls and display the hierarchical menu according these page urls.
Please find the sample dashboard json given below,

> {
> "id": "1",
> "url": "sampledashboard",
> "name": "Sample Dashboard",
> "version": "2.0.0",
> "description": "Lorem ipsum dolor sit amet DAS",
> "owner": "admin",
> "lastUpdatedBy": "admin",
> "createdTime": 150282009,
> "lastUpdatedTime": 1502820091112,
> "isShared": false,
> "parentId": "1",
> "content": [
> {
> "page0": {
> *content of page0*
> },
> "page1": {
> *content of page1*
> }
> }
> ]
> }



So we do not keep any mapping between pages and its hierarchy as in the
previous versions of the dashboard component. But we may need to maintain
some additional attributes such as Page title, isHidden and etc wrt page
URL. In that case, I think it is better to maintain a separate mapping
between these attributes and page URLs as in the previous dashboard
component. Please find the sample dashboard json given below.

> {
> "id": "1",
> "url": "sampledashboard",
> "name": "Sample Dashboard",
> "version": "2.0.0",
> "description": "Lorem ipsum dolor sit amet DAS",
> "owner": "admin",
> "lastUpdatedBy": "admin",
> "createdTime": 150282009,
> "lastUpdatedTime": 1502820091112,
> "isShared": false,
> "parentId": "1",
>
>
>
>
>
>
>
>
>
> *"menu": {"page0": {"ishidden": false,
> "title": "Page 0"},"page1": {"ishidden":
> false,"title": "Page 1"}}*,
> "content": [
> {
> "page0": {},
> "page1": {}
> }
> ]
> }
>
Because It will give a clear separation between dashboard content and the
pages’ menu attributes. WDYT?

Thanks,
Nisala

-- 
*Nisala Niroshana Nanayakkara,*
Software Engineer
Mobile | +94 717600022
WSO2 Inc | http://wso2.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Help required

2017-08-28 Thread Malaka Silva

Sorry your question is not clear for me. Are you simply trying to copy a
file without processing? What do you mean by adding content to output.xml?

On Mon, Aug 28, 2017 at 6:16 PM, Amit Rajvanshi 
wrote:

> Hi Malaka,
>
>
>
> I am trying implement pure messaging solution like copy one xml file from
> one sftp location and transfer it to another sftp location without any
> change.
>
> However in the output xml message envelop and body is being added to the
> message.
>
> For example:
>
>
>
> http://schemas.xmlsoap.org/soap/envelope/
> ">
>
> 
>
> Original content
>
> 
>
> 
>
>
>
> Inbound endpoint I have set content type as application/xml
>
> application/*xml* >
>
>
>
> I need to keep it application/xml because xml validation is required
> before processing.
>
> Could you please help me if it is possible to send the file without body
> and envelop.
>
>
>
> Best regards,
> *Amit Rajvanshi*
>
> *Technical Consultant*
> *Office:  *+91-120-4737401 <+91%20120%20473%207401>
>
> *Mobile*: +91 9871001235 <+91%2098710%2001235>
>
> *Email*:arajvan...@salmon.com
>
> [image: cid:image003.png@01D2CA89.60AB8730] 
>
>
>
> *[image: cid:image004.jpg@01D2CA89.60AB8730]*
>  *[image:
> cid:image005.jpg@01D2CA89.60AB8730]*
>  *[image:
> cid:image006.jpg@01D2CA89.60AB8730]*
>  *[image:
> cid:image007.jpg@01D2CA89.60AB8730]*
>  *[image:
> cid:image008.jpg@01D2CA89.60AB8730]* 
>  *[image: cid:image009.jpg@01D2CA89.60AB8730]*
>  *[image:
> cid:image010.jpg@01D2CA89.60AB8730]* 
>
>
>
> Information contained in this e-mail and any attachments is confidential
> and intended for the use of the addressee only. Dissemination,
> distribution, copying or use of this communication without prior permission
> of the addressee is strictly prohibited. If you have received this
> transmission in error, please advise the originator by reply e-mail and
> delete it. Thank you. Salmon India’s Registered Address is: B-13, Sector
> 57, Noida (U.P.) 201301. Registered in India U72200DL2003PTC120356.
>
>
> Information contained in this e-mail and any attachments is confidential
> and intended for the use of the addressee only. Dissemination,
> distribution, copying or use of this communication without prior permission
> of the addressee is strictly prohibited. If you have received this
> transmission in error, please advise the originator by reply e-mail and
> delete it. Thank you. Salmon India’s Registered Address is: B-13, Sector
> 57, Noida (U.P.) 201301. Registered in India U72200DL2003PTC120356.
>



-- 

Best Regards,

Malaka Silva
Associate Director / Architect
M: +94 777 219 791
Tel : 94 11 214 5345
Fax :94 11 2145300
Skype : malaka.sampath.silva
LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
Blog : http://mrmalakasilva.blogspot.com/

WSO2, Inc.
lean . enterprise . middleware
https://wso2.com/signature
http://www.wso2.com/about/team/malaka-silva/

https://store.wso2.com/store/

Don't make Trees rare, we should keep them with care
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IAM] Reusing Utilities

2017-08-28 Thread Nuwandi Wickramasinghe

Sorry above link [1] is broken. Check [1] and [2] given below.

[1] https://github.com/wso2/carbon-identity-framework/pull/1012
[2] https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/457

On Mon, Aug 28, 2017 at 3:28 PM, Nuwandi Wickramasinghe 
wrote:

> Fixed with [1] and [2]
>
> [1] https://github.com/wso2/carbon-identity-framework/pull/1012
> 
> [2] https://github.com/wso2-extensions/identity-inbound-
> auth-oauth/pull/457
>
> On Mon, Aug 28, 2017 at 12:25 PM, Nuwandi Wickramasinghe <
> nuwan...@wso2.com> wrote:
>
>>
>>
>> On Sat, Aug 26, 2017 at 12:32 PM, Johann Nallathamby 
>> wrote:
>>
>>> In fix [1], we've introduced a new Util class for URI validation. We
>>> already have a rich set of validations in [2].
>>>
>>> Won't this help here? I think we do have URL pattern define here
>>> already. If we don't have a pattern defined we need to improve this utility
>>> and reuse everywhere.
>>>
>> Looks like we can remove the new Util class and use the validation
>> utility from the identity-core. Will have to introduce new regex pattern
>> for oauth callback URIs since we cannot add URI fragments in them.
>>
>>>
>>> I already sent a previous mail on reusing JS validation utilities in UI
>>> layer also [3].
>>>
>>> [1] https://github.com/wso2-extensions/identity-inbound-auth-oau
>>> th/commit/0db19e8602d3831d596e04c3ec68d8a35b9c840b#diff-0887
>>> 37b86ff1f8e078854ea4bf1e350eR31
>>> 
>>> [2] https://github.com/wso2/carbon-identity-framework/blob/m
>>> aster/components/identity-core/org.wso2.carbon.identity.base
>>> /src/main/java/org/wso2/carbon/identity/base/IdentityValidationUtil.java
>>> [3] [IAM] Can't we do the same fix by adding fragment component as a
>>> blacklisted pattern to our JS util method?
>>>
>>> --
>>> Thanks & Regards,
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - *+9476950*
>>> Blog - *http://nallaa.wordpress.com *
>>>
>>
>>
>>
>> --
>>
>> Best Regards,
>>
>> Nuwandi Wickramasinghe
>>
>> Software Engineer
>>
>> WSO2 Inc.
>>
>> Web : http://wso2.com
>>
>> Mobile : 0719214873
>>
>
>
>
> --
>
> Best Regards,
>
> Nuwandi Wickramasinghe
>
> Software Engineer
>
> WSO2 Inc.
>
> Web : http://wso2.com
>
> Mobile : 0719214873
>



-- 

Best Regards,

Nuwandi Wickramasinghe

Software Engineer

WSO2 Inc.

Web : http://wso2.com

Mobile : 0719214873
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IAM] Reusing Utilities

2017-08-28 Thread Nuwandi Wickramasinghe

Fixed with [1] and [2]

[1] https://github.com/wso2/carbon-identity-framework/pull/1012

[2] https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/457

On Mon, Aug 28, 2017 at 12:25 PM, Nuwandi Wickramasinghe 
wrote:

>
>
> On Sat, Aug 26, 2017 at 12:32 PM, Johann Nallathamby 
> wrote:
>
>> In fix [1], we've introduced a new Util class for URI validation. We
>> already have a rich set of validations in [2].
>>
>> Won't this help here? I think we do have URL pattern define here already.
>> If we don't have a pattern defined we need to improve this utility and
>> reuse everywhere.
>>
> Looks like we can remove the new Util class and use the validation utility
> from the identity-core. Will have to introduce new regex pattern for oauth
> callback URIs since we cannot add URI fragments in them.
>
>>
>> I already sent a previous mail on reusing JS validation utilities in UI
>> layer also [3].
>>
>> [1] https://github.com/wso2-extensions/identity-inbound-auth-
>> oauth/commit/0db19e8602d3831d596e04c3ec68d8a35b9c840b#diff-0
>> 88737b86ff1f8e078854ea4bf1e350eR31
>> 
>> [2] https://github.com/wso2/carbon-identity-framework/blob/
>> master/components/identity-core/org.wso2.carbon.identity.
>> base/src/main/java/org/wso2/carbon/identity/base/IdentityV
>> alidationUtil.java
>> [3] [IAM] Can't we do the same fix by adding fragment component as a
>> blacklisted pattern to our JS util method?
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com *
>>
>
>
>
> --
>
> Best Regards,
>
> Nuwandi Wickramasinghe
>
> Software Engineer
>
> WSO2 Inc.
>
> Web : http://wso2.com
>
> Mobile : 0719214873
>



-- 

Best Regards,

Nuwandi Wickramasinghe

Software Engineer

WSO2 Inc.

Web : http://wso2.com

Mobile : 0719214873
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [GSoC] SCIM 2.0 Compliance Test Suite

2017-08-28 Thread Vindula Jayawardana

Hi All,

I submitted the completed project and thanks a lot for reviewing and
merging the PR [1]. Please find below the final related links for the SCIM
2.0 Compliance Test Suite.

   - Github repo: scim2-compliance-test-suite [2]
   - Blog on the project: SCIM 2.0 Compliance Test Suite — GSoC 2017 with
   WSO2 [3]
   - Screencast of the test suite: SCIM 2.0 Compliance Test Suite Demo [4]
   - Project readme [5]

[1]: https://github.com/wso2-incubator/scim2-compliance-test-suite/pull/1
[2]: https://github.com/wso2-incubator/scim2-compliance-test-suite
[3]:
https://medium.com/@vindulajayawardana/scim-2-0-compliance-test-suite-737fd4ace3cc
[4]: https://www.youtube.com/watch?v=XJ53x_8oAWg&feature=youtu.be
[5]:
https://github.com/wso2-incubator/scim2-compliance-test-suite/blob/master/README.md

Please let me know if there is anything that needs to be done by my end.

Thank you,
*Vindula Jayawardana*
Computer Science and Engineering Dept.
University of Moratuwa
mobile : +713462554
Email : vindula...@cse.mrt.ac.lk






*“Respect is how to treat everyone, not just those you want to impress. "*


*-Richard Branson-*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Dashboard Component - Hierarchical Page Support

Re: [Dev] Dashboard Component - Hierarchical Page Support

Re: [Dev] Dashboard Component - Hierarchical Page Support

Re: [Dev] Dashboard Component - Hierarchical Page Support

Re: [Dev] Dashboard Component - Hierarchical Page Support

Re: [Dev] Dashboard Component - Hierarchical Page Support

Re: [Dev] Dashboard Component - Hierarchical Page Support

Re: [Dev] Help required

[Dev] Dashboard Component - Hierarchical Page Support

Re: [Dev] Help required

Re: [Dev] [IAM] Reusing Utilities

Re: [Dev] [IAM] Reusing Utilities

[Dev] [GSoC] SCIM 2.0 Compliance Test Suite

13 matches

Site Navigation

Mail list logo

Footer information