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
