dhis2-devs team mailing list archive

[Lorill Crees <lcrees@xxxxxxxxxx>]

Hi Morten,

At long last I am revisiting using the enhancement you made for including
the displayName in the Error reports documented here, with the
importReportMode import parameter:

https://dhis2.github.io/dhis2-docs/master/en/developer/html/webapi_metadata_import.html

However in our case this doesn't end up reducing the amount of data that we
need to pass around. Basically, the only time we need to have the
displayName included in the response is if it is associated with an Error
that we need to pass back to the user. With the three options "ERRORS",
"FULL", and "DEBUG", we can only get the displayName with the option
"DEBUG", which also returns a separate object report for every object we
posted, regardless of whether or not it was an error.

Is it possible to augment this functionality with a fourth option, which is
"ERRORS" only, but with the displayName included? We don't want to have the
"FULL" functionality that is included in "DEBUG" as the point of us using
this functionality was to reduce the amount of data being passed around in
order to get at the displayName property of an error. In versions prior to
2.23, we got this information returned by default.

Please let me know what you think, and if a fourth option could be added.
It would be basically "ERRORS_DEBUG".

Thanks,

Lorill


On Sun, Oct 23, 2016 at 7:40 PM, Morten Olav Hansen <morten@xxxxxxxxx>
wrote:

>
> On Tue, Oct 18, 2016 at 11:51 PM, Lorill Crees <lcrees@xxxxxxxxxx> wrote:
>

>>>>>    1. The /api/23/metadata response with "errorReports" within
>>>>>    "objectReports" appears to have replaced the /api/metadata
>>>>>    "importConflicts". In /api/metadata, the "importConflicts" "object" field
>>>>>    contains the actual name of the object that has the error (eg: the Program
>>>>>    short name in our case). However, in /api/23/metadata there is only the
>>>>>    index which makes it more work to debug. Is it possible to also include the
>>>>>    name of the object in the error report like the prior API version does?
>>>>>
>>>>> Hm, right. I understand that it's useful, but that can easily add up
>>>> to a lot of data returned. Maybe we should add some kind of "debug" mode
>>>> where more output is provided.
>>>>
>>>
>>> Although I understand that this might add more data to the payload, it
>>> would decrease the amount of data that we need to pass around in our app,
>>> and also potentially decrease the number of API calls we need to do. Not
>>> having this information in the response now means we need to pass around
>>> our original post data (which can be quite large, and which we aren't
>>> currently doing) and do a lookup by ID to send any kind of useful
>>> information back to the user. Additionally, we may have even posted these
>>> objects by ID only, which means we will now need to do another API call to
>>> look up the object to get useful information to send back to the user. Keep
>>> in mind that in our app, the user doesn't actually even have a knowledge of
>>> IDs - we are doing those lookups for them by name or code.
>>> Would it be possible to add a flag to the api call where we can request
>>> the name or shortname or code to be returned in addition to just the ID?
>>> Perhaps similar to the metadata field filter?  Where we could say supply
>>> importConflictsFields=:identifiable?
>>>
>>
>> Yes, let me see what I can do for 225 at least (I might be able to
>> backport to 224 if it doesn't disrupt things too much)
>>
>> https://blueprints.launchpad.net/dhis2/+spec/importer-parame
>> ter-to-adjust-importreport-output
>>
>
> Thanks Morten, that's great!
>

>> I see this blueprint was completed in 2.25 - great! Was this backported
>> to 2.24? Is there documentation for this?
>>
>
> Yes, this is also in 224, docs are here:
>
> https://dhis2.github.io/dhis2-docs/master/en/developer/html/
> webapi_metadata_import.html
>
> --
> Morten Olav Hansen
> Senior Engineer, DHIS 2
> University of Oslo
> http://www.dhis2.org
>



-- 
Lorill Crees
Project Leader / Senior Developer
2Paths Solutions Ltd. <http://www.2paths.com>

lcrees@xxxxxxxxxx
skype: lorill2paths
(604) 689-4123 x 15