Yeah, it should have rolled back.. so it partially deleting something? I
don't think our `deletion handlers` does everything in the same
transaction.. so it won't do a proper rollback..
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Fri, Jun 17, 2016 at
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
O
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 c
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
wr
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
It will return same status as before (500) but now it will return a web
message payload with info (from hibernate)
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Thu, Jun 16, 2016 at 3:01 PM, Jason Pickering <
jason.p.picker...@gmail.com> wrote:
> I gue
http://localhost:8085/api/users/URq9lLcM8ID
204 NO CONTENT
The server has successfully fulfilled the request and that there is no
additional content to send in the response payload body.
On Thu, Jun 16, 2016 at 9:24 AM Morten Olav Hansen wrote:
> 204? for which endpoint? that doesn't sound righ
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
Right, so the user was deleted? 204 is expected for that. It's only for
server errors I have changed
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Thu, Jun 16, 2016 at 2:26 PM, Paulo Grácio wrote:
> http://localhost:8085/api/users/URq9lLcM8ID
>
> 204
204? for which endpoint? that doesn't sound right :)
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Thu, Jun 16, 2016 at 2:22 PM, Paulo Grácio wrote:
> Great, getting a 204.
>
> On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen
> wrote:
>
>> Hibernat
Great, getting a 204.
On Thu, Jun 16, 2016 at 8:39 AM Morten Olav Hansen wrote:
> Hibernate exception should now be caught, and a web message sent back,
> please try it out. Also added a new default exception handler, which
> unwraps the message and sends back to the user (full stack trace is st
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
Hi,
maybe I'm missing something but, just one more question, is there any
situation where we can delete a user?
If not maybe we can return 403 - Method Not Allowed, once DELETE is not
supported by User resource.
/Paulo
On Tue, Jun 14, 2016 at 12:56 PM Jason Pickering <
jason.p.picker...@gmail.
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
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 int
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, i
Hi Paulo
I have made a few changes to trunk and 2.23 which might help you. That
said, there are still a few cases where deletion will not be allowed.
You could also try to simple disable the user, so they are not allowed to
login.
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
Hi Lars,
you can find the server.log in attach. The test case is also available here
https://github.com/pgracio/dhis2-api-system-test/blob/master/modules/users.js
BR,
Paulo
On Mon, Jun 13, 2016 at 10:01 AM Lars Helge Øverland wrote:
> Hi Paulo,
>
> can you check the tomcat log on the server si
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 tab
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
20 matches
Mail list logo
