Task #10457 (closed)
Opened 11 years ago
Closed 11 years ago
Bug: rwrw-chgrp fails on ImageAnnotationLink
Reported by: | jamoore | Owned by: | jamoore |
---|---|---|---|
Priority: | critical | Milestone: | OMERO-4.4.9 |
Component: | Security | Version: | 4.4.8 |
Keywords: | n.a. | Cc: | jburel, mtbcarroll, cxallan, cneves |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | Blocker 4.4.9 (1) |
Description
When moving a shared image/annotation pair from a rwrw group to a rw group, a "bad-step" error is raised rather than unlinking the annotation. This seems to be caused by the rwrw handling of BaseGraphSpec.permissionsClause.
See https://docs.google.com/spreadsheet/ccc?key=0AuHdV7GT-8hmdDJXalU3VlhOS0cxdm1QcjE5eEFIRmc#gid=2
Change History (11)
comment:1 Changed 11 years ago by pwalczysko
comment:2 Changed 11 years ago by pwalczysko
Added some more attahments and tags being user-5 (in read-write, user-5 is a simple member, not owner or admin). Moved the Project as described above to "test" group - user-5 is not a member of this group.
Again, all seems fine - all attachments and comments from user-5 are there in the "test" group after the move.
comment:3 Changed 11 years ago by jamoore
- Milestone changed from OMERO-4.4.7 to OMERO-4.4.8
- Priority changed from blocker to critical
Petr: thank. This may be mismarked as 4.4.7, since it does link to the FS spreadsheet. I'll push to 4.4.8, then we can add automated tests for it there, and re-test with those against FS.
comment:4 Changed 11 years ago by mtbcarroll
- Owner set to mtbcarroll
- Version set to 4.4.8
comment:5 Changed 11 years ago by mtbcarroll
- Sprint set to Blocker 4.4.9 (1)
comment:6 Changed 11 years ago by mtbcarroll
- Status changed from new to accepted
comment:7 Changed 11 years ago by mtbcarroll
AnnotationMoveTest.testMoveImageAnnotatedByUsersDestinationGroupRW looks mightily relevant: does this address the situation of concern? If not, do any other tests, or should I create some variant of it? If so, given that the test is failing, is the bug in the server or the test?
comment:8 Changed 11 years ago by jamoore
Mark: if you think the test applies to the test as outlined by Petr and there's no remaining task, then close. There will be a general reworking on permission testings upcoming, so we need not keep this ticket open just as a "write-a-test" placeholder, though we could link this to whatever ticket's we have in place for that reworking.
The only reason to keep this open would be if this or a related bug still exists.
comment:9 Changed 11 years ago by mtbcarroll
- Owner changed from mtbcarroll to jamoore
I am honestly not sure if the test does properly repeat what is described in this ticket, though I think it does. But, also it fails: I don't know if the test is mistaken or the server has a bug. It would be great if you could glance at the test and see if you think it does move a shared image/annotation pair from a read-write group to a private group, and see if its comments agree with your understanding of what should happen with permissions: if both, then perhaps the server does need to be fixed. If you can clarify, and something should be done, then feel free to pass this back to me for work: really I just need some guidance before I can be confident enough to charge ahead.
comment:10 Changed 11 years ago by pwalczysko
Re-tested on Howe: from the UI perspective nothing "bad" happened - a Comment was lost from the image after the move to rw group as expected, no warnings or errors, business as usual
so the problem probably went away (I have never seen it myself though)
Workflw:
- create 2 users (not owners, not admins)
- the 2 users are members of both rw group as well as rwrw group
- in rwrw group, have user1 import some data (and own them)
- let user2 comment on the data of user1
- let user1 move the dtata (commented on by user2) to rw group
- user1 cannot see the comment of user2 in rw group any more (he could see it in the rwrw group though)
comment:11 Changed 11 years ago by jamoore
- Resolution set to invalid
- Status changed from accepted to closed
Cannot repeat this bug on today's dev_4_4 build.
Workflow: