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
