dhis2-devs team mailing list archive

[Morten Olav Hansen <morten@xxxxxxxxx>]

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
>>>>
>>>
>>