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