dhis2-devs team mailing list archive

[Morten Olav Hansen <mortenoh@xxxxxxxxx>]

Hi

In which endpoints do you see this? I have fixed it in the data element
operand endpoint, but there could be others also

--
Morten

On Thu, Jul 9, 2015 at 12:23 AM, Alan Hill <ahill@xxxxxxxxxx> wrote:

> Hi Morten
>
> Thanks for the information.
>
> Regarding the filtering bug, do you know which version/build this was
> fixed in?  I am still seeing the issue in 2.20-SNAPSHOT build #19473
>
> Kind regards
>
> Alan
>
>
>
> On Tue, Jul 7, 2015 at 9:35 PM, Morten Olav Hansen <mortenoh@xxxxxxxxx>
> wrote:
>
>> Hi
>>
>> Most of this should now be fixed, please note that also our import
>> summary(ies) are now wrapped in a WebMessage (check responseType to know
>> which payload was sent)
>>
>> Regarding the filtering bug, that was fixed a while back.
>>
>> We know about the difference in paging parameters, but we will not change
>> it right now. I think you should be ok if you follow this simple rule 1) if
>> its metadata use paging=true/false 2) if its data use skipPaging=true/false
>>
>> Thanks for reporting the issues.
>>
>> --
>> Morten
>>
>> On Fri, Jun 19, 2015 at 3:56 AM, Alan Hill <ahill@xxxxxxxxxx> wrote:
>>
>>> Hi
>>>
>>> I have a couple of additions:
>>>
>>> - Filtering results does not always retrieve the record you're after
>>> unless you specify paging=false (or it's on the first page)
>>> - Some entties use paging=false, others use skipPaging=true
>>>
>>> Thanks
>>>
>>> Alan
>>>
>>>
>>> On Thu, Jun 18, 2015 at 1:07 PM, Lorill Crees <lcrees@xxxxxxxxxx> wrote:
>>>
>>>> Hi Morten,
>>>>
>>>> These are the places where we're seeing inconsistencies:
>>>>
>>>>    - /api/sqlViews/<id>/execute POST: returns String - "SQL view
>>>>    created"
>>>>    - /api/sqlViews/<id>/data GET: exception in tomcat logs returns
>>>>    HTML error page (eg: if view has not been executed)
>>>>    -
>>>>    - /api/events POST: returns importSummaries in JSON (inconsistent
>>>>    with other api calls where importCount, importConflicts, conflicts etc are
>>>>    at root level)
>>>>    - /api/events PUT: returns String - "Event updated...."
>>>>    - /api/trackedEntityIntances POST: returns 'reference', not
>>>>    'lastImported' in JSON
>>>>    - /api/trackedEntityInstances POST: exception in tomcat logs
>>>>    returns HTML error page
>>>>    - There are also many api calls for assignments i.e.
>>>>       - /api/<entity>/<id>/<entity>/<id>
>>>>       That return 204 (no body).  Is this intentional/expected
>>>>       behaviour?
>>>>
>>>> Thanks,
>>>>
>>>> Lorill
>>>>
>>>> On Wed, Jun 17, 2015 at 6:34 PM, Morten Olav Hansen <mortenoh@xxxxxxxxx
>>>> > wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> We have started changing some of endpoints already, if you e.g. try to
>>>>> get a invalid data-element /api/dataElements/abc123 you will see the new
>>>>> output format (xml and json supported, json is default). I have not started
>>>>> changing the import conflict format yet, and it probably will not be
>>>>> changed for 2.20, I'm hoping to start a rewrite of the importer in 2.21,
>>>>> and the change of response format would then end up being in that release.
>>>>>
>>>>> Besides the import conflicts, if you are still seeing plain text error
>>>>> messages anywhere, please report back to me and I will replace them with a
>>>>> proper message.
>>>>>
>>>>> --
>>>>> Morten
>>>>>
>>>>> On Wed, Jun 17, 2015 at 11:48 PM, Lorill Crees <lcrees@xxxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>> Thanks Morten.
>>>>>>
>>>>>> On a related note, have you defined how you will be changing the
>>>>>> response messages yet? We've written a rudimentary response message parser
>>>>>> as part of our app because we get quite inconsistent results from the
>>>>>> various web api calls. EG: some responses return "conflicts" whereas others
>>>>>> return "importConflicts". Also we consistently ask for the response in JSON
>>>>>> yet some responses return HTML regardless which makes parsing the responses
>>>>>> difficult.
>>>>>>
>>>>>> Knowing the changes you have planned will be helpful as it could
>>>>>> potentially break the way we're currently parsing the results.
>>>>>>
>>>>>> By the way, we're working off 2.20 snapshot.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Lorill
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 16, 2015 at 7:39 PM, Morten Olav Hansen <
>>>>>> mortenoh@xxxxxxxxx> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> No, this is not currently supported. We might support it in a future
>>>>>>> release, as we are changing our responses messages a bit in 2.20/2.21.
>>>>>>>
>>>>>>> --
>>>>>>> Morten
>>>>>>>
>>>>>>> On Wed, Jun 17, 2015 at 5:58 AM, Lorill Crees <lcrees@xxxxxxxxxx>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Is it possible to receive messages back from the web api in other
>>>>>>>> languages? Specifically if there are import conflicts we would like to give
>>>>>>>> these messages back to the user in their preferred language.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Lorill
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>
>>>>
>>>
>>
>