It will return same status as before (500) but now it will return a web message payload with info (from hibernate)
-- Morten Olav Hansen Senior Engineer, DHIS 2 University of Oslo http://www.dhis2.org On Thu, Jun 16, 2016 at 3:01 PM, Jason Pickering < jason.p.picker...@gmail.com> wrote: > I guess the scenario we need to test is for users which CANNOT be deleted > for whatever reason. This is a bit more difficult to test, but should be > able to be done with the "system" user .There are a whole slew of objects > which are attached with FK references to userinfo, so it should be pretty > easy to create a user, create a dependent object, and then attempt to > delete the user. I think your fix Morten would in this case return a > different error (or at least a different response) than when the user > actually could be deleted? > > > On Thu, Jun 16, 2016 at 9:56 AM, Morten Olav Hansen <mor...@dhis2.org> > wrote: > >> Right, so the user was deleted? 204 is expected for that. It's only for >> server errors I have changed >> >> -- >> Morten Olav Hansen >> Senior Engineer, DHIS 2 >> University of Oslo >> http://www.dhis2.org >> >> On Thu, Jun 16, 2016 at 2:26 PM, Paulo Grácio <paulogra...@gmail.com> >> wrote: >> >>> http://localhost:8085/api/users/URq9lLcM8ID >>> >>> 204 NO CONTENT >>> The server has successfully fulfilled the request and that there is no >>> additional content to send in the response payload body. >>> >>> On Thu, Jun 16, 2016 at 9:24 AM Morten Olav Hansen <mor...@dhis2.org> >>> wrote: >>> >>>> 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 >>>>>>>> >>>>>>> >>>>>> >>>> >> > > > -- > 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
