Yeah, it should have rolled back.. so it partially deleting something? I don't think our `deletion handlers` does everything in the same transaction.. so it won't do a proper rollback..
-- Morten Olav Hansen Senior Engineer, DHIS 2 University of Oslo http://www.dhis2.org On Fri, Jun 17, 2016 at 12:54 AM, Paulo Grácio <paulogra...@gmail.com> wrote: > 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 >>>>> >>>> >>>> >>
_______________________________________________ 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
