dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxx>
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
>
>
>
>
>
> On Mon, Jun 16, 2014 at 10:36 PM, Lars Helge Øverland <larshelge@xxxxxxxxx
> > wrote:
>
>> Good.
>>
>>
>> On Mon, Jun 16, 2014 at 7:05 PM, Kiran Prakash <kprakash@xxxxxxxxxxxxxxxx
>> > 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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 <
>>>>> mortenoh@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>