204? for which endpoint? that doesn't sound right :) -- Morten Olav Hansen Senior Engineer, DHIS 2 University of Oslo http://www.dhis2.org
On Thu, Jun 16, 2016 at 2:22 PM, Paulo Grácio <paulogra...@gmail.com> wrote: > Great, getting a 204. > > On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen <mor...@dhis2.org> > wrote: > >> Hibernate exception should now be caught, and a web message sent back, >> please try it out. Also added a new default exception handler, which >> unwraps the message and sends back to the user (full stack trace is still >> available on the server). >> >> @Paulo: deletions -should- be allowed... but I don't think it will be >> fixed in time for 2.24, at least now our error message should be a bit more >> clear >> >> -- >> Morten Olav Hansen >> Senior Engineer, DHIS 2 >> University of Oslo >> http://www.dhis2.org >> >> On Tue, Jun 14, 2016 at 7:26 PM, Paulo Grácio <paulogra...@gmail.com> >> wrote: >> >>> Hi, >>> >>> maybe I'm missing something but, just one more question, is there any >>> situation where we can delete a user? >>> >>> If not maybe we can return 403 - Method Not Allowed, once DELETE is not >>> supported by User resource. >>> >>> /Paulo >>> >>> On Tue, Jun 14, 2016 at 12:56 PM Jason Pickering < >>> jason.p.picker...@gmail.com> wrote: >>> >>>> Hi Morten, >>>> >>>> We discussed by chat, but just for the benefit of others and to be sure >>>> that the test seems reasonable. The scenario is that when users which >>>> cannot be deleted for various reasons (like associated with this object or >>>> that object) cannot be deleted, the server returns something like >>>> >>>> 500: could not reassociate uninitialized transient collection >>>> >>>> or >>>> >>>> * ERROR 2016-06-14 12:45:35,311 Error while executing action >>>> (ExceptionInterceptor.java [http-bio-8080-exec-8]) >>>> org.springframework.dao.DataIntegrityViolationException: could not >>>> execute statement; SQL [n/a]; constraint [fk_document_userid]; nested >>>> exception is org.hibernate.exception.ConstraintViolationException: could >>>> not execute statement >>>> >>>> from the server side. >>>> >>>> What happens from the UI is you get a "Deleting..." message which >>>> spins forever. I think it might be better to catch the error and return >>>> this to the client and inform them that the user could not be deleted due >>>> to associations/constraints/ etc similar to when you attempt to delete an >>>> organisation unit or data element, which cannot be deleted. >>>> >>>> A 500 seems to be an unexpected error, but in this case, we should know >>>> that the user cannot be deleted due to constraints. Hope this makes sense. >>>> >>>> Regards, >>>> Jason >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Jun 14, 2016 at 12:07 PM, Morten Olav Hansen <mor...@dhis2.org> >>>> wrote: >>>> >>>>> Hm, a 403 (Forbidden) makes it seem like the user is trying to do >>>>> something he should not be allowed. I think 500 is fine in this case, as >>>>> it >>>>> signals an internal server error. >>>>> >>>>> Probably we should be better at catching these exception, and >>>>> returning some kind of message to the user (not just 500 internal error >>>>> which doesn't really mean anything to the end user). >>>>> >>>>> -- >>>>> Morten Olav Hansen >>>>> Senior Engineer, DHIS 2 >>>>> University of Oslo >>>>> http://www.dhis2.org >>>>> >>>>> On Tue, Jun 14, 2016 at 4:42 PM, Jason Pickering < >>>>> jason.p.picker...@gmail.com> wrote: >>>>> >>>>>> Hi Morten, >>>>>> >>>>>> As we continue with the development of the integration tetss, part of >>>>>> it will be to determine what is the expected response to certain >>>>>> operations. Maybe the fixes will not lead to a 500, or maybe that would >>>>>> be >>>>>> the expected response. Maybe a 403 or something would be better than a >>>>>> 500, >>>>>> if you are not allowed to delete a user for some reason? >>>>>> >>>>>> Regards, >>>>>> Jason >>>>>> >>>>>> >>>>>> On Tue, Jun 14, 2016 at 11:35 AM, Morten Olav Hansen < >>>>>> mor...@dhis2.org> wrote: >>>>>> >>>>>>> Hi Paulo >>>>>>> >>>>>>> I have made a few changes to trunk and 2.23 which might help you. >>>>>>> That said, there are still a few cases where deletion will not be >>>>>>> allowed. >>>>>>> >>>>>>> You could also try to simple disable the user, so they are not >>>>>>> allowed to login. >>>>>>> >>>>>>> -- >>>>>>> Morten Olav Hansen >>>>>>> Senior Engineer, DHIS 2 >>>>>>> University of Oslo >>>>>>> http://www.dhis2.org >>>>>>> >>>>>>> On Mon, Jun 13, 2016 at 11:32 PM, Paulo Grácio < >>>>>>> paulogra...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Lars, >>>>>>>> >>>>>>>> you can find the server.log in attach. The test case is also >>>>>>>> available here >>>>>>>> >>>>>>>> https://github.com/pgracio/dhis2-api-system-test/blob/master/modules/users.js >>>>>>>> >>>>>>>> BR, >>>>>>>> Paulo >>>>>>>> >>>>>>>> On Mon, Jun 13, 2016 at 10:01 AM Lars Helge Øverland < >>>>>>>> l...@dhis2.org> wrote: >>>>>>>> >>>>>>>>> Hi Paulo, >>>>>>>>> >>>>>>>>> can you check the tomcat log on the server side? >>>>>>>>> >>>>>>>>> What likely is going on here is the user being associated with >>>>>>>>> multiple objects through sharing (e.g. data elements), or as owner >>>>>>>>> (e.g. >>>>>>>>> favorites). The deletion handling of users is not fully in place, >>>>>>>>> simply >>>>>>>>> because almost all of our tables potentially can be linked to the user >>>>>>>>> table. >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> >>>>>>>>> Lars >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio < >>>>>>>>> paulogra...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> when trying to delete an user using API, DELETE - >>>>>>>>>> http://localhost:8085/api/users/zTsuPZnHqaO I'm getting a 500 - >>>>>>>>>> Internal Error with >>>>>>>>>> >>>>>>>>>> Request processing failed; nested exception is >>>>>>>>>> org.springframework.dao.DataIntegrityViolationException: could not >>>>>>>>>> execute >>>>>>>>>> statement; SQL [n/a]; constraint [fk6a68e08f19893da]; nested >>>>>>>>>> exception is >>>>>>>>>> org.hibernate.exception.ConstraintViolationException: could not >>>>>>>>>> execute >>>>>>>>>> statement >>>>>>>>>> >>>>>>>>>> is this expected? Should I make a different call before delete >>>>>>>>>> the User? It works fine when deleting in Web UI. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Paulo >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Lars Helge Øverland >>>>>>>>> Lead developer, DHIS 2 >>>>>>>>> University of Oslo >>>>>>>>> Skype: larshelgeoverland >>>>>>>>> l...@dhis2.org >>>>>>>>> http://www.dhis2.org <https://www.dhis2.org/> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jason P. Pickering >>>>>> email: jason.p.picker...@gmail.com >>>>>> tel:+46764147049 >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Jason P. Pickering >>>> email: jason.p.picker...@gmail.com >>>> tel:+46764147049 >>>> >>> >>
_______________________________________________ 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
