dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

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