Hi Morten, this test case expects a failure(500) when deleting the admin user. The problem is that something is being deleted, once the user is not allowed to authenticate again. Please see log attached. Basically I was expecting the transaction to rollback and keep database state.
BR, Paulo On Thu, Jun 16, 2016 at 7:30 PM Morten Olav Hansen <mor...@dhis2.org> wrote: > Paulo, > > I think what you expect is that the user is deleted. That will not happen, > maybe 2.27. > > Pleases make sure Jason is feeling you actual cases we can fix. > > -- > Morten Olav Hansen > Senior Engineer, DHIS 2 > University of Oslo > http://www.dhis2.org > > On Thu, Jun 16, 2016 at 11:44 PM, Paulo Grácio <paulogra...@gmail.com> > wrote: > >> I have created a test case that tries to delete the default admin user. I >> get back a 500 with the web message payload, but looks like something is >> being delete because after that I can't login into the application with >> that user and also http://localhost:8085/api/users?query=admin returns >> an empty list >> >> { >> "pager": { >> "page": 1, >> "pageCount": 1, >> "total": 0, >> "pageSize": 50 >> }, >> "users": [] >> } >> >> Do you protect all resources with authentication? For instance if I try >> to create a new user with admin/district I'm getting 409. Was expecting to >> get a 401 Unauthorized or 403 Forbidden >> >> { >> "httpStatus": "Conflict", >> "httpStatusCode": 409, >> "status": "ERROR", >> "message": "You must have permissions to create user, or ability to >> manage at least one user group for the user." >> } >> >> BR, >> Paulo >> >> On Thu, Jun 16, 2016 at 10:12 AM Morten Olav Hansen <mor...@dhis2.org> >> wrote: >> >>> 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 >>>> >>> >>> >
server.log
Description: Binary data
_______________________________________________ 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
