Re: [Dhis2-devs] User Module - Error deleting user

[Morten Olav Hansen]

Yeah, it should have rolled back.. so it partially deleting something? I
don't think our `deletion handlers` does everything in the same
transaction.. so it won't do a proper rollback..

-- 
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org

On Fri, Jun 17, 2016 at 12:54 AM, Paulo Grácio 
wrote:

> Hi Morten,
>
> this test case expects a failure(500) when deleting the admin user. The
> problem is that something is being deleted, once the user is not allowed to
> authenticate again. Please see log attached. Basically I was expecting the
> transaction to rollback and keep database state.
>
> BR,
> Paulo
>
>
>
> On Thu, Jun 16, 2016 at 7:30 PM Morten Olav Hansen 
> wrote:
>
>> 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 
>> 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 
>>> 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.picker...@gmail.com> 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 
> 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 
>> 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 
>>> 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 <
 paulogra...@gmail.com> wrote:

> Great, getting a 204.
>
> On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen <
> mor...@dhis2.org> 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

Re: [Dhis2-devs] User Module - Error deleting user

[Paulo Grácio]

Hi Morten,

this test case expects a failure(500) when deleting the admin user. The
problem is that something is being deleted, once the user is not allowed to
authenticate again. Please see log attached. Basically I was expecting the
transaction to rollback and keep database state.

BR,
Paulo



On Thu, Jun 16, 2016 at 7:30 PM Morten Olav Hansen  wrote:

> 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 
> 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 
>> 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.picker...@gmail.com> 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 
 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 
> 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 
>> 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 >> > wrote:
>>>
 Great, getting a 204.

 On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen <
 mor...@dhis2.org> 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 <
> paulogra...@gmail.com> 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 <

Re: [Dhis2-devs] User Module - Error deleting user

[Jason Pickering]

Hi Paulo and Morten,
Please see my earlier mail from today where I did a similar case with a
user, but via the UI.

https://lists.launchpad.net/dhis2-devs/msg45471.html

which I think basically does the same thing. Not sure. Maybe you can point
us to the exact test Paulo?

Morten, this is a quite common use case really. Just deleting a user.

Regards,
Jason


On Thu, Jun 16, 2016 at 7:29 PM, Morten Olav Hansen 
wrote:

> 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 
> 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 
>> 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.picker...@gmail.com> 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 
 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 
> 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 
>> 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 >> > wrote:
>>>
 Great, getting a 204.

 On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen <
 mor...@dhis2.org> 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 <
> paulogra...@gmail.com> 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
>>

Re: [Dhis2-devs] User Module - Error deleting user

[Morten Olav Hansen]

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 
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 
> 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.picker...@gmail.com> 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 
>>> 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 
 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 
> 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 
>> wrote:
>>
>>> Great, getting a 204.
>>>
>>> On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen 
>>> 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 <
 paulogra...@gmail.com> 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.picker...@gmail.com> 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

Re: [Dhis2-devs] User Module - Error deleting user

[Paulo Grácio]

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 
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.picker...@gmail.com> 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 
>> 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 
>>> 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 
 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 
> wrote:
>
>> Great, getting a 204.
>>
>> On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen 
>> 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 >> > 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.picker...@gmail.com> 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.
>

Re: [Dhis2-devs] User Module - Error deleting user

[Morten Olav Hansen]

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.picker...@gmail.com> 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 
> 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 
>> 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 
>>> 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 
 wrote:

> Great, getting a 204.
>
> On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen 
> 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 
>> 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.picker...@gmail.com> 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 <
 mor...@dhis2.org> 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.
>

Re: [Dhis2-devs] User Module - Error deleting user

[Paulo Grácio]

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  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 
> wrote:
>
>> Great, getting a 204.
>>
>> On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen 
>> 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 
>>> 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.picker...@gmail.com> 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  > 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.picker...@gmail.com> 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 <
>>> mor...@dhis2.org> 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 <
 paulogra...@gmail.com> wrote:

> Hi 

Re: [Dhis2-devs] User Module - Error deleting user

[Jason Pickering]

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 
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 
> 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 
>> 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 
>>> wrote:
>>>
 Great, getting a 204.

 On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen 
 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 
> 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.picker...@gmail.com> 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 <
>>> mor...@dhis2.org> 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.picker...@gmail.com> 

Re: [Dhis2-devs] User Module - Error deleting user

[Morten Olav Hansen]

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  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 
> 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 
>> wrote:
>>
>>> Great, getting a 204.
>>>
>>> On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen 
>>> 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 
 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.picker...@gmail.com> 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 <
>> mor...@dhis2.org> 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.picker...@gmail.com> 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 <
 mor...@dhis2.org> wrote:

> Hi Paulo
>
> I have made a few changes to trunk and 2.23 which might help you.
> That said, there are still a 

Re: [Dhis2-devs] User Module - Error deleting user

[Morten Olav Hansen]

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

> Great, getting a 204.
>
> On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen 
> 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 
>> 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.picker...@gmail.com> 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 
 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.picker...@gmail.com> 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 <
>> mor...@dhis2.org> 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 <
>>> paulogra...@gmail.com> 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 <
 l...@dhis2.org> wrote:

> Hi Paulo,
>
> can you check the tomcat log 

Re: [Dhis2-devs] User Module - Error deleting user

[Paulo Grácio]

Great, getting a 204.

On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen  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 
> 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.picker...@gmail.com> 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 
>>> 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.picker...@gmail.com> 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  > 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 > > 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 
>>> 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.

Re: [Dhis2-devs] User Module - Error deleting user

[Morten Olav Hansen]

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  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.picker...@gmail.com> 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 
>> 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.picker...@gmail.com> 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 
 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 
> 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 
>> 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 >> > wrote:
>>>
 Hi all,

 when trying to delete an user using API, DELETE -
 

Re: [Dhis2-devs] User Module - Error deleting user

[Paulo Grácio]

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.picker...@gmail.com> 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 
> 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.picker...@gmail.com> 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 
>>> 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 
 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 
> 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 
>> 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: 

Re: [Dhis2-devs] User Module - Error deleting user

[Jason Pickering]

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 
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.picker...@gmail.com> 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 
>> 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 
>>> 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 
 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 
> 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@lists.launchpad.net
>> 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
> l...@dhis2.org
> http://www.dhis2.org 
>
>
 ___
 Mailing list: 

Re: [Dhis2-devs] User Module - Error deleting user

[Morten Olav Hansen]

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.picker...@gmail.com> 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 
> 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 
>> 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 
>>> 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 
 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@lists.launchpad.net
> 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
 l...@dhis2.org
 http://www.dhis2.org 


>>> ___
>>> Mailing list: https://launchpad.net/~dhis2-devs
>>> Post to : dhis2-devs@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Jason P. Pickering
> email: jason.p.picker...@gmail.com
> tel:+46764147049
>
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] User Module - Error deleting user

[Jason Pickering]

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 
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 
> 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 
>> 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 
>>> 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@lists.launchpad.net
 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
>>> l...@dhis2.org
>>> http://www.dhis2.org 
>>>
>>>
>> ___
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Jason P. Pickering
email: jason.p.picker...@gmail.com
tel:+46764147049
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] User Module - Error deleting user

[Morten Olav Hansen]

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 
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 
> 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 
>> 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@lists.launchpad.net
>>> 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
>> l...@dhis2.org
>> http://www.dhis2.org 
>>
>>
> ___
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] User Module - Error deleting user

[Paulo Grácio]

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  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 
> 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@lists.launchpad.net
>> 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
> l...@dhis2.org
> http://www.dhis2.org 
>
>


delete-user.log
Description: Binary data
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Dhis2-devs] User Module - Error deleting user

[Lars Helge Øverland]

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  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@lists.launchpad.net
> 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
l...@dhis2.org
http://www.dhis2.org 
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

[Dhis2-devs] User Module - Error deleting user

[Paulo Grácio]

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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp