Contract changes in User Controller.

Support - Assistance technique
1

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

2

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

···

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

3

Hi

This should now be working in rev 15615.

/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

···

–
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

4

Hello Morten,

Thank you for the quick fix!

We were trying the new api and it works. We also looked at the code a little bit, and we saw that if we don’t give any query params, we are defaulting it to “:all”. However this retrieves fields only at the first level and does not retrieve fields for the nested entities.

Ex: When we get user object using say /api/users/OYLGMiazHtW.json it just gets the user object and does not get all the fields of the userCredentials object.

This might break backwards compatibility of the api, as the older api was giving out all the fields by default including nested objects. Is this the expected behaviour?

···

Thanks,
Aravind

On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

This should now be working in rev 15615.

/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

–
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

5

Yes,

This is by design, :all merely means “give me all property on current level”. It will by default render idObjects with just idObject properties, and Collections of idObject as a collection of idObject properties.

I know this breaks things, but we were really not happy with the current use of viewClasses (@JsonView), I hope it won’t be too difficult to implement.

We do support recursive expansion of the fields properties, so you can do ?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes… this requires changes to your code (most of this is supported in 2.15, but you will to use include= instead)

···

–
Morten

On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan aravindm@thoughtworks.com wrote:

Hello Morten,

Thank you for the quick fix!

We were trying the new api and it works. We also looked at the code a little bit, and we saw that if we don’t give any query params, we are defaulting it to “:all”. However this retrieves fields only at the first level and does not retrieve fields for the nested entities.

Ex: When we get user object using say /api/users/OYLGMiazHtW.json it just gets the user object and does not get all the fields of the userCredentials object.

This might break backwards compatibility of the api, as the older api was giving out all the fields by default including nested objects. Is this the expected behaviour?

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thanks,
Aravind

On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

This should now be working in rev 15615.

/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

–
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

6

Is it possible to keep backward compatibility intact while making API changes?

We’re already seeing lot of issues on our side, and I’m sure others who’re using the API will also face these problems.

One more place where the API change is breaking our code is this, while querying the org hierarchy.

for eg: http://localhost:8080/api/organisationUnits/d06372e4302?includeDescendants=true

Would give the queried organization and all its descendents and its custom attributes etc.

with the new API, we’re trying to get


http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all]

the decendents of the org has been renamed to ‘children’, but the children does not have all the custom attributes set. We are using a custom attribute on the organization to figure the type of node in the hierarchy (eg. country, hospital, etc ) and some of our domain logic is based on this type.

Are we missing something in our query? Please let us know.

Thanks in advance,

Kiran.

···

On Wed, Jun 11, 2014 at 3:16 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yes,

This is by design, :all merely means “give me all property on current level”. It will by default render idObjects with just idObject properties, and Collections of idObject as a collection of idObject properties.

I know this breaks things, but we were really not happy with the current use of viewClasses (@JsonView), I hope it won’t be too difficult to implement.

We do support recursive expansion of the fields properties, so you can do ?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes… this requires changes to your code (most of this is supported in 2.15, but you will to use include= instead)

–
Morten

On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan aravindm@thoughtworks.com wrote:

Hello Morten,

Thank you for the quick fix!

We were trying the new api and it works. We also looked at the code a little bit, and we saw that if we don’t give any query params, we are defaulting it to “:all”. However this retrieves fields only at the first level and does not retrieve fields for the nested entities.

Ex: When we get user object using say /api/users/OYLGMiazHtW.json it just gets the user object and does not get all the fields of the userCredentials object.

This might break backwards compatibility of the api, as the older api was giving out all the fields by default including nested objects. Is this the expected behaviour?

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thanks,
Aravind

On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

This should now be working in rev 15615.

/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

–
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

7

Is it possible to keep backward compatibility intact while making API
changes?

Ideally yes, but these changes did require breaking the API in a few
places. Going forward there should be no major changes to the external API
(only additions).

One more place where the API change is breaking our code is this, while

querying the org hierarchy.

for eg:
http://localhost:8080/api/organisationUnits/d06372e4302?includeDescendants=true

Yes, this have been disabled for now, should be back very soon (today)
together with includeChildren.

···

On Wed, Jun 11, 2014 at 12:03 PM, Kiran Prakash <kprakash@thoughtworks.com> wrote:

--
Morten

Would give the queried organization and all its descendents and its custom

attributes etc.

with the new API, we're trying to get

<http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all\]&gt;

http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all\]

the decendents of the org has been renamed to 'children', but the
children does not have all the custom attributes set. We are using a custom
attribute on the organization to figure the type of node in the hierarchy
(eg. country, hospital, etc ) and some of our domain logic is based on this
type.

Are we missing something in our query? Please let us know.

Thanks in advance,

Kiran.

On Wed, Jun 11, 2014 at 3:16 PM, Morten Olav Hansen <mortenoh@gmail.com> > wrote:

Yes,

This is by design, :all merely means "give me all property on current
level". It will by default render idObjects with just idObject properties,
and Collections of idObject as a collection of idObject properties.

I know this breaks things, but we were really not happy with the current
use of viewClasses (@JsonView), I hope it won't be too difficult to
implement.

We do support recursive expansion of the fields properties, so you can do
?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes.. this requires changes to
your code (most of this is supported in 2.15, but you will to use include=
instead)

--
Morten

On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan < >> aravindm@thoughtworks.com> wrote:

Hello Morten,

Thank you for the quick fix!

We were trying the new api and it works. We also looked at the code a
little bit, and we saw that if we don't give any query params, we are
defaulting it to ":all". However this retrieves fields only at the first
level and does not retrieve fields for the nested entities.

Ex: When we get user object using say */api/users/OYLGMiazHtW.json *it
just gets the user object and does not get all the fields of the
userCredentials object.

This might break backwards compatibility of the api, as the older api
was giving out all the fields by default including nested objects. Is this
the expected behaviour?

Thanks,
Aravind

On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen <mortenoh@gmail.com> >>> wrote:

Hi

This should now be working in rev 15615.
/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

--
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen <mortenoh@gmail.com >>>> > wrote:

Hi

All our endpoint have now been switched our to using the new field
filtering (similar to the old inclusion/exclusion), so the data you want is
probably there, but you have to tell the system you want to have it. I do
see that there is a bug in the UserCredentials class, I will fix that
tomorrow.

Please see the documentation here:
http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom
control over the output, we still use Jackson (ObjectMapper, but not
data-binding) in the backend, together with xml (StAX).

--
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya < >>>>> mahendrk@thoughtworks.com> wrote:

Hello Morten,

We're facing some issues due to some recent changes to UserController.

The serialized 'User' json has some issues.

The 'usercredentials' field is now being serialized as
'org.hisp.dhis.user.UserCredentials' and also some of the properties of
UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We
tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for
custom serialization instead of going for standard serializers like
Jackson? )

Regards

Mahendra/Kiran

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

8

includeChildren/includeDescendants should now be available in rev 15619.

···

–
Morten

On Wed, Jun 11, 2014 at 12:15 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

On Wed, Jun 11, 2014 at 12:03 PM, Kiran Prakash kprakash@thoughtworks.com wrote:

Is it possible to keep backward compatibility intact while making API changes?

Ideally yes, but these changes did require breaking the API in a few places. Going forward there should be no major changes to the external API (only additions).

One more place where the API change is breaking our code is this, while querying the org hierarchy.

for eg: http://localhost:8080/api/organisationUnits/d06372e4302?includeDescendants=true

Yes, this have been disabled for now, should be back very soon (today) together with includeChildren.

–

Morten

Would give the queried organization and all its descendents and its custom attributes etc.

with the new API, we’re trying to get


http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all]

the decendents of the org has been renamed to ‘children’, but the children does not have all the custom attributes set. We are using a custom attribute on the organization to figure the type of node in the hierarchy (eg. country, hospital, etc ) and some of our domain logic is based on this type.

Are we missing something in our query? Please let us know.

Thanks in advance,

Kiran.

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 11, 2014 at 3:16 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yes,

This is by design, :all merely means “give me all property on current level”. It will by default render idObjects with just idObject properties, and Collections of idObject as a collection of idObject properties.

I know this breaks things, but we were really not happy with the current use of viewClasses (@JsonView), I hope it won’t be too difficult to implement.

We do support recursive expansion of the fields properties, so you can do ?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes… this requires changes to your code (most of this is supported in 2.15, but you will to use include= instead)

–
Morten

On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan aravindm@thoughtworks.com wrote:

Hello Morten,

Thank you for the quick fix!

We were trying the new api and it works. We also looked at the code a little bit, and we saw that if we don’t give any query params, we are defaulting it to “:all”. However this retrieves fields only at the first level and does not retrieve fields for the nested entities.

Ex: When we get user object using say /api/users/OYLGMiazHtW.json it just gets the user object and does not get all the fields of the userCredentials object.

This might break backwards compatibility of the api, as the older api was giving out all the fields by default including nested objects. Is this the expected behaviour?

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thanks,
Aravind

On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

This should now be working in rev 15615.

/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

–
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

9

Hi Kiran,

it could be I get this wrong, however just a suggestion: When classifying the organisation units in DHIS it is useful to utilize an organisation unit group set (“Org unit type”) and organisation unit groups for each type. This makes is possible to later do data analysis broken down on org unit type, ie. org unit type will become a data dimension and appear in left side menu in pivot table / visualizer apps. It is also possible to get org units and group membership in lists now e.g. like this:

http://apps.dhis2.org/dev/api/organisationUnits.json?fields=id,name,organisationUnitGroups

cheers

Lars

···

On Wed, Jun 11, 2014 at 12:03 PM, Kiran Prakash kprakash@thoughtworks.com wrote:

Is it possible to keep backward compatibility intact while making API changes?

We’re already seeing lot of issues on our side, and I’m sure others who’re using the API will also face these problems.

One more place where the API change is breaking our code is this, while querying the org hierarchy.

for eg: http://localhost:8080/api/organisationUnits/d06372e4302?includeDescendants=true

Would give the queried organization and all its descendents and its custom attributes etc.

with the new API, we’re trying to get


http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all]

the decendents of the org has been renamed to ‘children’, but the children does not have all the custom attributes set. We are using a custom attribute on the organization to figure the type of node in the hierarchy (eg. country, hospital, etc ) and some of our domain logic is based on this type.

Are we missing something in our query? Please let us know.

Thanks in advance,

Kiran.

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 11, 2014 at 3:16 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yes,

This is by design, :all merely means “give me all property on current level”. It will by default render idObjects with just idObject properties, and Collections of idObject as a collection of idObject properties.

I know this breaks things, but we were really not happy with the current use of viewClasses (@JsonView), I hope it won’t be too difficult to implement.

We do support recursive expansion of the fields properties, so you can do ?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes… this requires changes to your code (most of this is supported in 2.15, but you will to use include= instead)

–
Morten

On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan aravindm@thoughtworks.com wrote:

Hello Morten,

Thank you for the quick fix!

We were trying the new api and it works. We also looked at the code a little bit, and we saw that if we don’t give any query params, we are defaulting it to “:all”. However this retrieves fields only at the first level and does not retrieve fields for the nested entities.

Ex: When we get user object using say /api/users/OYLGMiazHtW.json it just gets the user object and does not get all the fields of the userCredentials object.

This might break backwards compatibility of the api, as the older api was giving out all the fields by default including nested objects. Is this the expected behaviour?

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thanks,
Aravind

On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

This should now be working in rev 15615.

/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

–
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

10

oh ok. Thanks Lars, We will look into this.

Regards,

Kiran.

···

On Mon, Jun 16, 2014 at 5:22 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Kiran,

it could be I get this wrong, however just a suggestion: When classifying the organisation units in DHIS it is useful to utilize an organisation unit group set (“Org unit type”) and organisation unit groups for each type. This makes is possible to later do data analysis broken down on org unit type, ie. org unit type will become a data dimension and appear in left side menu in pivot table / visualizer apps. It is also possible to get org units and group membership in lists now e.g. like this:

http://apps.dhis2.org/dev/api/organisationUnits.json?fields=id,name,organisationUnitGroups

cheers

Lars

On Wed, Jun 11, 2014 at 12:03 PM, Kiran Prakash kprakash@thoughtworks.com wrote:

Is it possible to keep backward compatibility intact while making API changes?

We’re already seeing lot of issues on our side, and I’m sure others who’re using the API will also face these problems.

One more place where the API change is breaking our code is this, while querying the org hierarchy.

for eg: http://localhost:8080/api/organisationUnits/d06372e4302?includeDescendants=true

Would give the queried organization and all its descendents and its custom attributes etc.

with the new API, we’re trying to get


http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all]

the decendents of the org has been renamed to ‘children’, but the children does not have all the custom attributes set. We are using a custom attribute on the organization to figure the type of node in the hierarchy (eg. country, hospital, etc ) and some of our domain logic is based on this type.

Are we missing something in our query? Please let us know.

Thanks in advance,

Kiran.

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 11, 2014 at 3:16 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yes,

This is by design, :all merely means “give me all property on current level”. It will by default render idObjects with just idObject properties, and Collections of idObject as a collection of idObject properties.

I know this breaks things, but we were really not happy with the current use of viewClasses (@JsonView), I hope it won’t be too difficult to implement.

We do support recursive expansion of the fields properties, so you can do ?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes… this requires changes to your code (most of this is supported in 2.15, but you will to use include= instead)

–
Morten

On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan aravindm@thoughtworks.com wrote:

Hello Morten,

Thank you for the quick fix!

We were trying the new api and it works. We also looked at the code a little bit, and we saw that if we don’t give any query params, we are defaulting it to “:all”. However this retrieves fields only at the first level and does not retrieve fields for the nested entities.

Ex: When we get user object using say /api/users/OYLGMiazHtW.json it just gets the user object and does not get all the fields of the userCredentials object.

This might break backwards compatibility of the api, as the older api was giving out all the fields by default including nested objects. Is this the expected behaviour?

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thanks,
Aravind

On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

This should now be working in rev 15615.

/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

–
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

11

Good.

···

On Mon, Jun 16, 2014 at 7:05 PM, Kiran Prakash kprakash@thoughtworks.com wrote:

oh ok. Thanks Lars, We will look into this.

Regards,

Kiran.

On Mon, Jun 16, 2014 at 5:22 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Kiran,

it could be I get this wrong, however just a suggestion: When classifying the organisation units in DHIS it is useful to utilize an organisation unit group set (“Org unit type”) and organisation unit groups for each type. This makes is possible to later do data analysis broken down on org unit type, ie. org unit type will become a data dimension and appear in left side menu in pivot table / visualizer apps. It is also possible to get org units and group membership in lists now e.g. like this:

http://apps.dhis2.org/dev/api/organisationUnits.json?fields=id,name,organisationUnitGroups

cheers

Lars

On Wed, Jun 11, 2014 at 12:03 PM, Kiran Prakash kprakash@thoughtworks.com wrote:

Is it possible to keep backward compatibility intact while making API changes?

We’re already seeing lot of issues on our side, and I’m sure others who’re using the API will also face these problems.

One more place where the API change is breaking our code is this, while querying the org hierarchy.

for eg: http://localhost:8080/api/organisationUnits/d06372e4302?includeDescendants=true

Would give the queried organization and all its descendents and its custom attributes etc.

with the new API, we’re trying to get


http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all]

the decendents of the org has been renamed to ‘children’, but the children does not have all the custom attributes set. We are using a custom attribute on the organization to figure the type of node in the hierarchy (eg. country, hospital, etc ) and some of our domain logic is based on this type.

Are we missing something in our query? Please let us know.

Thanks in advance,

Kiran.

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 11, 2014 at 3:16 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yes,

This is by design, :all merely means “give me all property on current level”. It will by default render idObjects with just idObject properties, and Collections of idObject as a collection of idObject properties.

I know this breaks things, but we were really not happy with the current use of viewClasses (@JsonView), I hope it won’t be too difficult to implement.

We do support recursive expansion of the fields properties, so you can do ?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes… this requires changes to your code (most of this is supported in 2.15, but you will to use include= instead)

–
Morten

On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan aravindm@thoughtworks.com wrote:

Hello Morten,

Thank you for the quick fix!

We were trying the new api and it works. We also looked at the code a little bit, and we saw that if we don’t give any query params, we are defaulting it to “:all”. However this retrieves fields only at the first level and does not retrieve fields for the nested entities.

Ex: When we get user object using say /api/users/OYLGMiazHtW.json it just gets the user object and does not get all the fields of the userCredentials object.

This might break backwards compatibility of the api, as the older api was giving out all the fields by default including nested objects. Is this the expected behaviour?

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thanks,
Aravind

On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

This should now be working in rev 15615.

/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

–
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

12

Hi Lars,

The organization structure we are setting up has one special case - a particular org unit type could be either at level 5 or 6. We associate data sets and capture data against org units of this particular type. Also, organization units get added from our client application and the client application needs to be aware of the org unit type. Would it be possible to use organization unit groups and group sets in this case where the organization units are not a fixed/static list?

Regards,
Shantala

···

On Mon, Jun 16, 2014 at 10:36 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Good.

On Mon, Jun 16, 2014 at 7:05 PM, Kiran Prakash kprakash@thoughtworks.com wrote:

oh ok. Thanks Lars, We will look into this.

Regards,

Kiran.

On Mon, Jun 16, 2014 at 5:22 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Kiran,

it could be I get this wrong, however just a suggestion: When classifying the organisation units in DHIS it is useful to utilize an organisation unit group set (“Org unit type”) and organisation unit groups for each type. This makes is possible to later do data analysis broken down on org unit type, ie. org unit type will become a data dimension and appear in left side menu in pivot table / visualizer apps. It is also possible to get org units and group membership in lists now e.g. like this:

http://apps.dhis2.org/dev/api/organisationUnits.json?fields=id,name,organisationUnitGroups

cheers

Lars

On Wed, Jun 11, 2014 at 12:03 PM, Kiran Prakash kprakash@thoughtworks.com wrote:

Is it possible to keep backward compatibility intact while making API changes?

We’re already seeing lot of issues on our side, and I’m sure others who’re using the API will also face these problems.

One more place where the API change is breaking our code is this, while querying the org hierarchy.

for eg: http://localhost:8080/api/organisationUnits/d06372e4302?includeDescendants=true

Would give the queried organization and all its descendents and its custom attributes etc.

with the new API, we’re trying to get


http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all]

the decendents of the org has been renamed to ‘children’, but the children does not have all the custom attributes set. We are using a custom attribute on the organization to figure the type of node in the hierarchy (eg. country, hospital, etc ) and some of our domain logic is based on this type.

Are we missing something in our query? Please let us know.

Thanks in advance,

Kiran.

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 11, 2014 at 3:16 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yes,

This is by design, :all merely means “give me all property on current level”. It will by default render idObjects with just idObject properties, and Collections of idObject as a collection of idObject properties.

I know this breaks things, but we were really not happy with the current use of viewClasses (@JsonView), I hope it won’t be too difficult to implement.

We do support recursive expansion of the fields properties, so you can do ?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes… this requires changes to your code (most of this is supported in 2.15, but you will to use include= instead)

–
Morten

On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan aravindm@thoughtworks.com wrote:

Hello Morten,

Thank you for the quick fix!

We were trying the new api and it works. We also looked at the code a little bit, and we saw that if we don’t give any query params, we are defaulting it to “:all”. However this retrieves fields only at the first level and does not retrieve fields for the nested entities.

Ex: When we get user object using say /api/users/OYLGMiazHtW.json it just gets the user object and does not get all the fields of the userCredentials object.

This might break backwards compatibility of the api, as the older api was giving out all the fields by default including nested objects. Is this the expected behaviour?

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thanks,
Aravind

On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

This should now be working in rev 15615.

/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

–
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran

13

Hi Shantala,

yes it should not be a problem that org units are located at different levels. For all kinds of classifications of org units we recommend using groups, as it becomes available for data analysis later. For arbitrary details about org units, like contact info, you can use attributes.

regards,

Lars

···

On Tue, Jun 17, 2014 at 7:06 PM, Shantala Raman sraman@thoughtworks.com wrote:

Hi Lars,

The organization structure we are setting up has one special case - a particular org unit type could be either at level 5 or 6. We associate data sets and capture data against org units of this particular type. Also, organization units get added from our client application and the client application needs to be aware of the org unit type. Would it be possible to use organization unit groups and group sets in this case where the organization units are not a fixed/static list?

Regards,
Shantala

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Mon, Jun 16, 2014 at 10:36 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Good.

On Mon, Jun 16, 2014 at 7:05 PM, Kiran Prakash kprakash@thoughtworks.com wrote:

oh ok. Thanks Lars, We will look into this.

Regards,

Kiran.

On Mon, Jun 16, 2014 at 5:22 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Kiran,

it could be I get this wrong, however just a suggestion: When classifying the organisation units in DHIS it is useful to utilize an organisation unit group set (“Org unit type”) and organisation unit groups for each type. This makes is possible to later do data analysis broken down on org unit type, ie. org unit type will become a data dimension and appear in left side menu in pivot table / visualizer apps. It is also possible to get org units and group membership in lists now e.g. like this:

http://apps.dhis2.org/dev/api/organisationUnits.json?fields=id,name,organisationUnitGroups

cheers

Lars

On Wed, Jun 11, 2014 at 12:03 PM, Kiran Prakash kprakash@thoughtworks.com wrote:

Is it possible to keep backward compatibility intact while making API changes?

We’re already seeing lot of issues on our side, and I’m sure others who’re using the API will also face these problems.

One more place where the API change is breaking our code is this, while querying the org hierarchy.

for eg: http://localhost:8080/api/organisationUnits/d06372e4302?includeDescendants=true

Would give the queried organization and all its descendents and its custom attributes etc.

with the new API, we’re trying to get


http://localhost:8080/api/organisationUnits/d06372e4302?fields=:all,children[:all]

the decendents of the org has been renamed to ‘children’, but the children does not have all the custom attributes set. We are using a custom attribute on the organization to figure the type of node in the hierarchy (eg. country, hospital, etc ) and some of our domain logic is based on this type.

Are we missing something in our query? Please let us know.

Thanks in advance,

Kiran.

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Wed, Jun 11, 2014 at 3:16 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yes,

This is by design, :all merely means “give me all property on current level”. It will by default render idObjects with just idObject properties, and Collections of idObject as a collection of idObject properties.

I know this breaks things, but we were really not happy with the current use of viewClasses (@JsonView), I hope it won’t be too difficult to implement.

We do support recursive expansion of the fields properties, so you can do ?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes… this requires changes to your code (most of this is supported in 2.15, but you will to use include= instead)

–
Morten

On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan aravindm@thoughtworks.com wrote:

Hello Morten,

Thank you for the quick fix!

We were trying the new api and it works. We also looked at the code a little bit, and we saw that if we don’t give any query params, we are defaulting it to “:all”. However this retrieves fields only at the first level and does not retrieve fields for the nested entities.

Ex: When we get user object using say /api/users/OYLGMiazHtW.json it just gets the user object and does not get all the fields of the userCredentials object.

This might break backwards compatibility of the api, as the older api was giving out all the fields by default including nested objects. Is this the expected behaviour?

Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Thanks,
Aravind

On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

This should now be working in rev 15615.

/api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]

Please try it out and report any issues back

–
Morten

On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

All our endpoint have now been switched our to using the new field filtering (similar to the old inclusion/exclusion), so the data you want is probably there, but you have to tell the system you want to have it. I do see that there is a bug in the UserCredentials class, I will fix that tomorrow.

Please see the documentation here:

http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html

Regarding the the custom serializers, we needed a bit more custom control over the output, we still use Jackson (ObjectMapper, but not data-binding) in the backend, together with xml (StAX).

–
Morten

On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya mahendrk@thoughtworks.com wrote:

Hello Morten,

We’re facing some issues due to some recent changes to UserController.

The serialized ‘User’ json has some issues.

The ‘usercredentials’ field is now being serialized as ‘org.hisp.dhis.user.UserCredentials’ and also some of the properties of UserCredentials (like userAuthorityGroup ) is not being serialized.

One of our application is breaking due to these contract changes. We tried fixing it, but soon got lost in the custom serialization code.

Can you please have a look at this.

( Also on a side note, is there any specific reason we are going for custom serialization instead of going for standard serializers like Jackson? )

Regards

Mahendra/Kiran