dhis2-devs team mailing list archive

[Paulo Grácio <paulogracio@xxxxxxxxx>]

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