dhis2-devs team mailing list archive

[Morten Olav Hansen <morten@xxxxxxxxx>]

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