dhis2-devs team mailing list archive

[Morten Olav Hansen <morten@xxxxxxxxx>]

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
>