User Module - Error deleting user

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

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

lars@dhis2.org

http://www.dhis2.org

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

delete-user.log (3.48 KB)

···

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

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.

···

On Mon, Jun 13, 2016 at 11:32 PM, Paulo Grácio paulogracio@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 lars@dhis2.org 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


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

Morten Olav Hansen

Senior Engineer, DHIS 2

University of Oslo

http://www.dhis2.org

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

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


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

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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

···

On Tue, Jun 14, 2016 at 4:42 PM, Jason Pickering jason.p.pickering@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

Morten Olav Hansen

Senior Engineer, DHIS 2

University of Oslo

http://www.dhis2.org

On Tue, Jun 14, 2016 at 11:35 AM, Morten Olav Hansen morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

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@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.pickering@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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:07 PM, Morten Olav Hansen morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

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

···

On Tue, Jun 14, 2016 at 7:26 PM, Paulo Grácio paulogracio@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.pickering@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

Morten Olav Hansen

Senior Engineer, DHIS 2

University of Oslo

http://www.dhis2.org

On Tue, Jun 14, 2016 at 12:07 PM, Morten Olav Hansen morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

Great, getting a 204.

···

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@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

204? for which endpoint? that doesn’t sound right :slight_smile:

···

On Thu, Jun 16, 2016 at 2:22 PM, Paulo Grácio paulogracio@gmail.com wrote:

Great, getting a 204.

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

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@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

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.

···

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

Great, getting a 204.

On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen morten@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 paulogracio@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

Right, so the user was deleted? 204 is expected for that. It’s only for server errors I have changed

···

On Thu, Jun 16, 2016 at 2:26 PM, Paulo Grácio paulogracio@gmail.com 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@dhis2.org wrote:

204? for which endpoint? that doesn’t sound right :slight_smile:

Morten Olav Hansen

Senior Engineer, DHIS 2

University of Oslo

http://www.dhis2.org

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

Great, getting a 204.

On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen morten@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 paulogracio@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

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

204? for which endpoint? that doesn’t sound right :slight_smile:

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

Great, getting a 204.

On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen morten@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 paulogracio@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

It will return same status as before (500) but now it will return a web message payload with info (from hibernate)

···

On Thu, Jun 16, 2016 at 3:01 PM, Jason Pickering jason.p.pickering@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?

Morten Olav Hansen

Senior Engineer, DHIS 2

University of Oslo

http://www.dhis2.org

On Thu, Jun 16, 2016 at 9:56 AM, Morten Olav Hansen morten@dhis2.org wrote:

Right, so the user was deleted? 204 is expected for that. It’s only for server errors I have changed


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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

204? for which endpoint? that doesn’t sound right :slight_smile:

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

Great, getting a 204.

On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen morten@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 paulogracio@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

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

···

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@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 morten@dhis2.org wrote:

Right, so the user was deleted? 204 is expected for that. It’s only for server errors I have changed


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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

204? for which endpoint? that doesn’t sound right :slight_smile:

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

Great, getting a 204.

On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen morten@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 paulogracio@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

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.

···

On Thu, Jun 16, 2016 at 11:44 PM, Paulo Grácio paulogracio@gmail.com 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@dhis2.org 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

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@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 morten@dhis2.org wrote:

Right, so the user was deleted? 204 is expected for that. It’s only for server errors I have changed


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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

204? for which endpoint? that doesn’t sound right :slight_smile:

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

Great, getting a 204.

On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen morten@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 paulogracio@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

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 morten@dhis2.org 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 paulogracio@gmail.com 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@dhis2.org 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@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 morten@dhis2.org wrote:

Right, so the user was deleted? 204 is expected for that. It’s only for server errors I have changed


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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

204? for which endpoint? that doesn’t sound right :slight_smile:

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

Great, getting a 204.

On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen morten@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 paulogracio@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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

server.log (17.9 KB)

···

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@gmail.com 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@dhis2.org 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@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 morten@dhis2.org wrote:

Right, so the user was deleted? 204 is expected for that. It’s only for server errors I have changed


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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

204? for which endpoint? that doesn’t sound right :slight_smile:

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

Great, getting a 204.

On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen morten@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 paulogracio@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org

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…

···

On Fri, Jun 17, 2016 at 12:54 AM, Paulo Grácio paulogracio@gmail.com 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 morten@dhis2.org 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

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@gmail.com 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@dhis2.org 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@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 morten@dhis2.org wrote:

Right, so the user was deleted? 204 is expected for that. It’s only for server errors I have changed


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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

204? for which endpoint? that doesn’t sound right :slight_smile:

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

Great, getting a 204.

On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen morten@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 paulogracio@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.pickering@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 morten@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).


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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@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 morten@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.


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.pickering@gmail.com
tel:+46764147049

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@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 lars@dhis2.org 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


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

On Sat, Jun 11, 2016 at 6:54 PM, Paulo Grácio paulogracio@gmail.com 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

lars@dhis2.org

http://www.dhis2.org