dhis2-devs team mailing list archive

[Paulo Grácio <paulogracio@xxxxxxxxx>]

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 <morten@xxxxxxxxx> 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 <paulogracio@xxxxxxxxx>
> 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 <morten@xxxxxxxxx>
>> 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.pickering@xxxxxxxxx> 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 <morten@xxxxxxxxx>
>>>> 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 <paulogracio@xxxxxxxxx>
>>>>> 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 <morten@xxxxxxxxx>
>>>>>> 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 <paulogracio@xxxxxxxxx
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Great, getting a 204.
>>>>>>>>
>>>>>>>> On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen <
>>>>>>>> morten@xxxxxxxxx> 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 <
>>>>>>>>> paulogracio@xxxxxxxxx> 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.pickering@xxxxxxxxx> 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 <
>>>>>>>>>>> morten@xxxxxxxxx> 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.pickering@xxxxxxxxx> 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 <
>>>>>>>>>>>>> morten@xxxxxxxxx> 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 <
>>>>>>>>>>>>>> paulogracio@xxxxxxxxx> 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 <
>>>>>>>>>>>>>>> lars@xxxxxxxxx> 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 <
>>>>>>>>>>>>>>>> paulogracio@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> lars@xxxxxxxxx
>>>>>>>>>>>>>>>> http://www.dhis2.org <https://www.dhis2.org/>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>>>>>>>>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>>>>>>>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jason P. Pickering
>>>>>>>>>>>>> email: jason.p.pickering@xxxxxxxxx
>>>>>>>>>>>>> tel:+46764147049
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jason P. Pickering
>>>>>>>>>>> email: jason.p.pickering@xxxxxxxxx
>>>>>>>>>>> tel:+46764147049
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jason P. Pickering
>>>> email: jason.p.pickering@xxxxxxxxx
>>>> tel:+46764147049
>>>>
>>>
>>>
>

Attachment: server.log
Description: Binary data