Good.
On Mon, Jun 16, 2014 at 7:05 PM, Kiran Prakash <kprak...@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 <larshe...@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 < >> kprak...@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]> >>> >>> 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 <morte...@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 < >>>> aravi...@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 < >>>>> morte...@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 < >>>>>> morte...@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 < >>>>>>> mahen...@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: 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 >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> 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 >>> >>> >> >
_______________________________________________ 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