Re: [Dev] Multiple receiver urls not supported in EI-6.1.1 Event Sink configuration

[Manorama Perera]

Hi Nirodha,

This bug is already reported at [1], and fixed[2] in EI 6.2.0 M3.

[1] https://github.com/wso2/product-ei/issues/835
[2] https://github.com/wso2/carbon-mediation/pull/848

Thanks,
Manorama

On Wed, Aug 30, 2017 at 10:57 AM, Nirodha Gallage  wrote:

> Hi,
>
> When creating Event Sink config in ESB 4.9.0 and ESB 5.0.0 it supported
> giving comma separated multiple Receiver URLs within curly braces,
>
> Eg: {tcp://192.168.56.168:7611,tcp://192.168.56.159:7611}
>
> But this is not supported in EI 6.1.1, and does not allow to save the
> config with an error "Incomplete URL or Invalid protocol.."
>
> Isn't it a bug? And is there any workaround for this?
>
> Regards,
> Nirodha
>
> --
>
> *Nirodha Gallage*
> Associate Technical Lead
> WSO2 Inc.: http://wso2.com/
> Mobile: +94716429078 <+94%2071%20642%209078>
>



-- 
Manorama Perera
Software Engineer
WSO2, Inc.;  http://wso2.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Did we thought about APIM 3.0.0 Audit log?

[Rukshan Premathunga]

Hi all,

In c4 we had separate log file to audit API and application related stuff.
Is this already done in AM 3?

Thanks and Regards

-- 
Rukshan Chathuranga.
Software Engineer.
WSO2, Inc.
+94711822074
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Multiple receiver urls not supported in EI-6.1.1 Event Sink configuration

[Nirodha Gallage]

Hi,

When creating Event Sink config in ESB 4.9.0 and ESB 5.0.0 it supported
giving comma separated multiple Receiver URLs within curly braces,

Eg: {tcp://192.168.56.168:7611,tcp://192.168.56.159:7611}

But this is not supported in EI 6.1.1, and does not allow to save the
config with an error "Incomplete URL or Invalid protocol.."

Isn't it a bug? And is there any workaround for this?

Regards,
Nirodha

-- 

*Nirodha Gallage*
Associate Technical Lead
WSO2 Inc.: http://wso2.com/
Mobile: +94716429078
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Regarding auth_time claim in OIDC id_token

[Hasini Witharana]

Hi Asela,

We take the session updated time as the new auth_time.

Thank you.

On Tue, Aug 29, 2017 at 5:59 PM, Asela Pathberiya  wrote:

>
>
> On Tue, Aug 29, 2017 at 4:29 PM, Hasini Witharana 
> wrote:
>
>> Hi Asela,
>>
>> If SP sends a force auth request, we update the existing session.
>>
>
> So;  Are we generating new auth_time when session is updated ?
>
>
>>
>> Thanks,
>> Hasini
>>
>>
>>
>> On Wed, Aug 23, 2017 at 1:27 PM, Asela Pathberiya  wrote:
>>
>>>
>>>
>>> On Wed, Aug 23, 2017 at 12:46 PM, Hasini Witharana 
>>> wrote:
>>>
 Hi,

 In the OIDC specification auth_time is defined as below.[1]

 Time when the End-User authentication occurred. Its value is a JSON
 number representing the number of seconds from 1970-01-01T0:0:0Z as
 measured in UTC until the date/time. When a max_age request is made or
 when auth_time is requested as an Essential Claim, then this Claim is
 REQUIRED; otherwise, its inclusion is OPTIONAL.

 In the current implementation when the user is authenticated for the
 first time using user credentials, auth_time is considered as the session
 created time. After that when user is implicitly login in using a cookie
 without giving user credentials, auth_time is considered as session updated
 time.

>>>
>>> If SP sends a force authe request,  Are we creating a new session or
>>> update the existing session ?
>>>
>>> If max_age is expired,  Does SP need to send a force auth request or
>>> just an authentication request ?
>>>
>>> Thanks,
>>> Asela.
>>>

 As I think the auth_time should be the first time user authenticated
 using credentials.
 [2] is the fix made for this issue.

 Thank you.

 [1] - http://openid.net/specs/openid-connect-core-1_0.html
 [2] - https://github.com/wso2-extensions/identity-inbound-auth-oau
 th/pull/455

 --

 *Hasini Witharana*
 Software Engineering Intern | WSO2


 *Email : hasi...@wso2.com *

 *Mobile : +94713850143 <+94%2071%20385%200143>[image:
 http://wso2.com/signature] *

>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Asela
>>>
>>> ATL
>>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>>  +358 449 228 979
>>>
>>> http://soasecurity.org/
>>> http://xacmlinfo.org/
>>>
>>
>>
>>
>> --
>>
>> *Hasini Witharana*
>> Software Engineering Intern | WSO2
>>
>>
>> *Email : hasi...@wso2.com *
>>
>> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
>> http://wso2.com/signature] *
>>
>
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>



-- 

*Hasini Witharana*
Software Engineering Intern | WSO2


*Email : hasi...@wso2.com *

*Mobile : +94713850143[image: http://wso2.com/signature]
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] View the group (role) id through management console

[Gayan Gunawardana]

On Wed, Aug 30, 2017 at 12:46 AM, Nilasini Thirunavukkarasu <
nilas...@wso2.com> wrote:

> Hi,
>
> We have a way to view user id through management console. By enabling
> "supported by default" for user id claim we could able to view the user id.
> Likewise are we having any configurations to see the group id through
> management console?
>
No. Group id is not stored in user store. You can do a group name filter.

>
> Thanks,
> T.Nila.
>
> --
> Nilasini Thirunavukkarasu
> Software Engineer - WSO2
>
> Email : nilas...@wso2.com
> Mobile : +94775241823 <+94%2077%20524%201823>
> Web : http://wso2.com/
>
>
> 
>



-- 
Gayan Gunawardana
Senior Software Engineer; WSO2 Inc.; http://wso2.com/
Email: ga...@wso2.com
Mobile: +94 (71) 8020933
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Dashboard Component - Hierarchical Page Support

[Tanya Madurapperuma]

Hi Nisala,

First of all I think this mail should go to architecture@ :)

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",
>
> As we don't have versioning support for dashboards any reason for
maintaining version info?

>
>> "description": "Lorem ipsum dolor sit amet DAS",
>> "owner": "admin",
>> "lastUpdatedBy": "admin",
>> "createdTime": 150282009,
>> "lastUpdatedTime": 1502820091112,
>
> Could you also explain the usage of lastUpdatedBy, createdTime and
lastUpdateTime fields?

>
>> "isShared": false,
>
> I don't think we need isShared any more since we don't have a tenancy
concept now. We used this attribute earlier to indicate whether a
particular dashboard which is in super tenant is shared between other
tenants.

>
>> "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": {}
>> }
>> ]
>> }
>>
> I am -1 to have separate menu section since it duplicates certain
information and also we don't have lot of meta info to go for a separation.
Can't we have page level meta under the page resource url as below?


   - "content":[
  1. {
 - "page0":{
- "ishidden":false,
- "title":"Page 0",
- "content":[
   ]
 },
 - "page0/page1":{
- "ishidden":false,
- "title":"Page 1",
- "content":[
   ]
 }
  }
   ]


WDYT?

Thanks,
Tanya

>
>> 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/
>



-- 
Tanya Madurapperuma

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

[Dev] View the group (role) id through management console

[Nilasini Thirunavukkarasu]

Hi,

We have a way to view user id through management console. By enabling
"supported by default" for user id claim we could able to view the user id.
Likewise are we having any configurations to see the group id through
management console?

Thanks,
T.Nila.

-- 
Nilasini Thirunavukkarasu
Software Engineer - WSO2

Email : nilas...@wso2.com
Mobile : +94775241823
Web : http://wso2.com/



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

Re: [Dev] [IS] Usage of "kid" JWT header parameter

[Prabath Siriwardena]

Hope we will fix this for IS 5.4.0..?

Thanks & regards,
-Prabath

On Tue, Aug 29, 2017 at 2:34 AM, Indunil Upeksha Rathnayake <
indu...@wso2.com> wrote:

> Hi,
>
> On Mon, Aug 28, 2017 at 12:07 PM, Gayan Gunawardana 
> wrote:
>
>>
>>
>> On Mon, Aug 28, 2017 at 11:48 AM, Indunil Upeksha Rathnayake <
>> indu...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> In IS, when signing the ID token, we are passing the "kid" header
>>> parameter in the response.
>>> https://github.com/wso2-extensions/identity-inbound-auth-oau
>>> th/blob/master/components/org.wso2.carbon.identity.oauth/
>>> src/main/java/org/wso2/carbon/identity/openidconnect/Default
>>> IDTokenBuilder.java#L122
>>>
>>> As per the specification (Refer [1]) :
>>>
 *The kid value is a key identifier used in identifying the key to be
 used to verify the signature.If the kid value is unknown to the RP, it
 needs to retrieve the contents of the OP's JWK Set again to obtain the OP's
 current set of keys. *

>>>
>>> We have hard coded this "kid" value in the implementation level. What
>>> happens if the signing key is a different one than the default one?
>>>
>>> Seems like this "kid" is like a hint to identify which specific key to
>>> be used to validate the signature, when there are multiple keys. Is it a
>>> valid use case in IS, since there cannot be multiple certs available in
>>> resident IDP? And also is it correct to use a hard coded value from
>>> back-end?
>>>
>> Having hard coded value is not correct. "kid" value should be generated
>> based on certificate "thumbprint". Hard coded value would work for super
>> tenant default keystore.
>>
>
> Thanks. I have created a public JIRA in [1] to handle this.
>
> [1] https://wso2.org/jira/browse/IDENTITY-6311
>
>
>>
>>>
>>>
>>>
>>> This is hard coded in JwksEndpoint as well.
>>> https://github.com/wso2-extensions/identity-inbound-auth-oau
>>> th/blob/master/components/org.wso2.carbon.identity.oauth.
>>> endpoint/src/main/java/org/wso2/carbon/identity/oauth/
>>> endpoint/jwks/JwksEndpoint.java#L54
>>>
>>> But in JWTTokenGenerator, we are not setting the "kid" parameter.
>>> https://github.com/wso2-extensions/identity-inbound-auth-oau
>>> th/blob/master/components/org.wso2.carbon.identity.oauth/
>>> src/main/java/org/wso2/carbon/identity/oauth2/authcontext/
>>> JWTTokenGenerator.java#L293
>>>
>>> In which scenarios, this "kid" header parameter should be sent and
>>> should not be sent? Recently we have implemented to sign the user info JWT
>>> response and need to verify whether "kid" parameter should be sent there as
>>> well.
>>>
>>>
>>>
>>> Appreciate your ideas on above concerns.
>>>
>>> [1] http://openid.net/specs/openid-connect-core-1_0.html
>>>
>>>
>>> Thanks and Regards
>>> --
>>> Indunil Upeksha Rathnayake
>>> Software Engineer | WSO2 Inc
>>> Emailindu...@wso2.com
>>> Mobile   0772182255 <077%20218%202255>
>>>
>>
>>
>>
>> --
>> Gayan Gunawardana
>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>
>
>
> --
> Indunil Upeksha Rathnayake
> Software Engineer | WSO2 Inc
> Emailindu...@wso2.com
> Mobile   0772182255 <077%20218%202255>
>



-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

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

Re: [Dev] Regarding auth_time claim in OIDC id_token

[Asela Pathberiya]

On Tue, Aug 29, 2017 at 4:29 PM, Hasini Witharana  wrote:

> Hi Asela,
>
> If SP sends a force auth request, we update the existing session.
>

So;  Are we generating new auth_time when session is updated ?


>
> Thanks,
> Hasini
>
>
>
> On Wed, Aug 23, 2017 at 1:27 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Wed, Aug 23, 2017 at 12:46 PM, Hasini Witharana 
>> wrote:
>>
>>> Hi,
>>>
>>> In the OIDC specification auth_time is defined as below.[1]
>>>
>>> Time when the End-User authentication occurred. Its value is a JSON
>>> number representing the number of seconds from 1970-01-01T0:0:0Z as
>>> measured in UTC until the date/time. When a max_age request is made or
>>> when auth_time is requested as an Essential Claim, then this Claim is
>>> REQUIRED; otherwise, its inclusion is OPTIONAL.
>>>
>>> In the current implementation when the user is authenticated for the
>>> first time using user credentials, auth_time is considered as the session
>>> created time. After that when user is implicitly login in using a cookie
>>> without giving user credentials, auth_time is considered as session updated
>>> time.
>>>
>>
>> If SP sends a force authe request,  Are we creating a new session or
>> update the existing session ?
>>
>> If max_age is expired,  Does SP need to send a force auth request or just
>> an authentication request ?
>>
>> Thanks,
>> Asela.
>>
>>>
>>> As I think the auth_time should be the first time user authenticated
>>> using credentials.
>>> [2] is the fix made for this issue.
>>>
>>> Thank you.
>>>
>>> [1] - http://openid.net/specs/openid-connect-core-1_0.html
>>> [2] - https://github.com/wso2-extensions/identity-inbound-auth-oau
>>> th/pull/455
>>>
>>> --
>>>
>>> *Hasini Witharana*
>>> Software Engineering Intern | WSO2
>>>
>>>
>>> *Email : hasi...@wso2.com *
>>>
>>> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
>>> http://wso2.com/signature] *
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>  +358 449 228 979
>>
>> http://soasecurity.org/
>> http://xacmlinfo.org/
>>
>
>
>
> --
>
> *Hasini Witharana*
> Software Engineering Intern | WSO2
>
>
> *Email : hasi...@wso2.com *
>
> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
> http://wso2.com/signature] *
>



-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Dev] Regarding auth_time claim in OIDC id_token

[Hasini Witharana]

Hi Asela,

If SP sends a force auth request, we update the existing session.

Thanks,
Hasini



On Wed, Aug 23, 2017 at 1:27 PM, Asela Pathberiya  wrote:

>
>
> On Wed, Aug 23, 2017 at 12:46 PM, Hasini Witharana 
> wrote:
>
>> Hi,
>>
>> In the OIDC specification auth_time is defined as below.[1]
>>
>> Time when the End-User authentication occurred. Its value is a JSON
>> number representing the number of seconds from 1970-01-01T0:0:0Z as
>> measured in UTC until the date/time. When a max_age request is made or
>> when auth_time is requested as an Essential Claim, then this Claim is
>> REQUIRED; otherwise, its inclusion is OPTIONAL.
>>
>> In the current implementation when the user is authenticated for the
>> first time using user credentials, auth_time is considered as the session
>> created time. After that when user is implicitly login in using a cookie
>> without giving user credentials, auth_time is considered as session updated
>> time.
>>
>
> If SP sends a force authe request,  Are we creating a new session or
> update the existing session ?
>
> If max_age is expired,  Does SP need to send a force auth request or just
> an authentication request ?
>
> Thanks,
> Asela.
>
>>
>> As I think the auth_time should be the first time user authenticated
>> using credentials.
>> [2] is the fix made for this issue.
>>
>> Thank you.
>>
>> [1] - http://openid.net/specs/openid-connect-core-1_0.html
>> [2] - https://github.com/wso2-extensions/identity-inbound-auth-
>> oauth/pull/455
>>
>> --
>>
>> *Hasini Witharana*
>> Software Engineering Intern | WSO2
>>
>>
>> *Email : hasi...@wso2.com *
>>
>> *Mobile : +94713850143 <+94%2071%20385%200143>[image:
>> http://wso2.com/signature] *
>>
>
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>



-- 

*Hasini Witharana*
Software Engineering Intern | WSO2


*Email : hasi...@wso2.com *

*Mobile : +94713850143[image: http://wso2.com/signature]
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [IS] Usage of "kid" JWT header parameter

[Indunil Upeksha Rathnayake]

Hi,

On Mon, Aug 28, 2017 at 12:07 PM, Gayan Gunawardana  wrote:

>
>
> On Mon, Aug 28, 2017 at 11:48 AM, Indunil Upeksha Rathnayake <
> indu...@wso2.com> wrote:
>
>> Hi,
>>
>> In IS, when signing the ID token, we are passing the "kid" header
>> parameter in the response.
>> https://github.com/wso2-extensions/identity-inbound-auth-
>> oauth/blob/master/components/org.wso2.carbon.identity.
>> oauth/src/main/java/org/wso2/carbon/identity/openidconnect/
>> DefaultIDTokenBuilder.java#L122
>>
>> As per the specification (Refer [1]) :
>>
>>> *The kid value is a key identifier used in identifying the key to be
>>> used to verify the signature.If the kid value is unknown to the RP, it
>>> needs to retrieve the contents of the OP's JWK Set again to obtain the OP's
>>> current set of keys. *
>>>
>>
>> We have hard coded this "kid" value in the implementation level. What
>> happens if the signing key is a different one than the default one?
>>
>> Seems like this "kid" is like a hint to identify which specific key to be
>> used to validate the signature, when there are multiple keys. Is it a valid
>> use case in IS, since there cannot be multiple certs available in resident
>> IDP? And also is it correct to use a hard coded value from back-end?
>>
> Having hard coded value is not correct. "kid" value should be generated
> based on certificate "thumbprint". Hard coded value would work for super
> tenant default keystore.
>

Thanks. I have created a public JIRA in [1] to handle this.

[1] https://wso2.org/jira/browse/IDENTITY-6311


>
>>
>>
>>
>> This is hard coded in JwksEndpoint as well.
>> https://github.com/wso2-extensions/identity-inbound-auth-
>> oauth/blob/master/components/org.wso2.carbon.identity.
>> oauth.endpoint/src/main/java/org/wso2/carbon/identity/
>> oauth/endpoint/jwks/JwksEndpoint.java#L54
>>
>> But in JWTTokenGenerator, we are not setting the "kid" parameter.
>> https://github.com/wso2-extensions/identity-inbound-auth-
>> oauth/blob/master/components/org.wso2.carbon.identity.
>> oauth/src/main/java/org/wso2/carbon/identity/oauth2/
>> authcontext/JWTTokenGenerator.java#L293
>>
>> In which scenarios, this "kid" header parameter should be sent and should
>> not be sent? Recently we have implemented to sign the user info JWT
>> response and need to verify whether "kid" parameter should be sent there as
>> well.
>>
>>
>>
>> Appreciate your ideas on above concerns.
>>
>> [1] http://openid.net/specs/openid-connect-core-1_0.html
>>
>>
>> Thanks and Regards
>> --
>> Indunil Upeksha Rathnayake
>> Software Engineer | WSO2 Inc
>> Emailindu...@wso2.com
>> Mobile   0772182255
>>
>
>
>
> --
> Gayan Gunawardana
> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>



-- 
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Emailindu...@wso2.com
Mobile   0772182255
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Dashboard Component - Hierarchical Page Support

[Nipuna Chandradasa]

@nisala - what if we keep the parentId undefined if it is not a
personalized dashboard? then it'll be just one
check[if(dashboard.parentId)] and i think it is more faster. This is just a
suggestion so we don't have to duplicate IDs. Keeping the both IDs are okay
too.  WDYT?



On Tue, Aug 29, 2017 at 1:22 PM, Nipuna Chandradasa 
wrote:

> Yeah +1 for the lasantha's idea. That will make it easy to read the json
> also.
> What are the golden layout level functionality that we are using now?  (
> tabs and containers?)
>
> On Tue, Aug 29, 2017 at 12:06 PM, Lasantha Samarakoon 
> wrote:
>
>> ​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 <+94%2071%20214%201576>
>> 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 

Re: [Dev] Dashboard Component - Hierarchical Page Support

[Nipuna Chandradasa]

Yeah +1 for the lasantha's idea. That will make it easy to read the json
also.
What are the golden layout level functionality that we are using now?  (
tabs and containers?)

On Tue, Aug 29, 2017 at 12:06 PM, Lasantha Samarakoon 
wrote:

> ​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 <+94%2071%20214%201576>
> 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,

Re: [Dev] Dashboard Component - Hierarchical Page Support

[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,
>>  

Re: [Dev] Dashboard Component - Hierarchical Page Support

[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.

> {
>  

Re: [Dev] Dashboard Component - Hierarchical Page Support

[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": 

Re: [Dev] Dashboard Component - Hierarchical Page Support

[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