Hi Morten....apologies for the delay in replying.
I am still seeing this with
/api/trackedEntityAttributes
2.20-SNAPSHOT
Build revision: 19647
I will let you know if I encounter any others.
Regards
Alan
On Wed, Jul 8, 2015 at 11:06 PM, Morten Olav Hansen <morte...@gmail.com>
wrote:
> 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 <ah...@2paths.com> 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 <morte...@gmail.com>
>> 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 <ah...@2paths.com> 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 <lcr...@2paths.com>
>>>> 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 <
>>>>> morte...@gmail.com> 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 <lcr...@2paths.com>
>>>>>> 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 <
>>>>>>> morte...@gmail.com> 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 <lcr...@2paths.com>
>>>>>>>> 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@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
