Skip to content

Can edit group 1 9505#309

Merged
joshmoore merged 11 commits intoome:developfrom
will-moore:canEdit_group-1_9505
Sep 6, 2012
Merged

Can edit group 1 9505#309
joshmoore merged 11 commits intoome:developfrom
will-moore:canEdit_group-1_9505

Conversation

@will-moore
Copy link
Copy Markdown
Member

Test for canEdit() and canAnnotate() when we get objects using 'omero.group': '-1'

@ghost ghost assigned joshmoore Aug 27, 2012
@joshmoore
Copy link
Copy Markdown
Member

The tests are still failing, but look to be testing what's intended. Rather than merge this without a fix, I'll open a PR on this branch with my fixes, but not for the build tomorrow.

Will Moore and others added 5 commits August 29, 2012 17:01
Restrictions on objects like Project were being
improperly copied (to some extent from DUMMY
Permissions).
Umasks are unused (and unsupported). No reason
to be creating all of these Permissions objects.
The group permissions object which was being cached in the
BasicEventContext was being assigned directly to multiple
objects causing the restrictions value to be overwritten.
@joshmoore
Copy link
Copy Markdown
Member

Will, rather than my opening a PR on your PR etc., can you push -f my branch (https://github.com/joshmoore/openmicroscopy/tree/9505-perm-restrictions) to your branch which will update this PR? I cherry-picked both of your commits and applied a fix.

@joshmoore
Copy link
Copy Markdown
Member

The tests now pass, but this will need a day of general testing to make sure nothing's gone wrong.

@bpindelski
Copy link
Copy Markdown

Waiting for a review of the "locked project" situation for test users, as reported on 30/08/2012.

Will Moore and others added 3 commits August 31, 2012 15:34
"user" group permissions were not being loaded
properly leading to NPEs. Since modifying data
in the "user" group is not the regular case, a
EMPTY permissions should be a safe default.
@joshmoore
Copy link
Copy Markdown
Member

Removing this from 4.4.4 for the moment, so we can verify that gretzky works as expected without.

This orders users by their id and prints
separate columns for "active" and "admin"
to make group membership easier to read.
Since the restrictions array was being re-used,
the ordering of objects processed affected what
value was returned. Most returned objects tend
to be users and groups, which have lower permissions
leading to the "locked" problem.
If the restrictions array to be created contains
only "false" elements, then there's no reason to
copy it. A null "restrictions" is equally good.
@joshmoore joshmoore mentioned this pull request Sep 4, 2012
@ghost
Copy link
Copy Markdown

ghost commented Sep 5, 2012

I can't see any obvious defects with this PR (tested with user-5/read-annotate-1 on gretzky using insight and web).

@joshmoore
Copy link
Copy Markdown
Member

Merging. For release, we'll need a significant round of permissions testing.

joshmoore added a commit that referenced this pull request Sep 6, 2012
@joshmoore joshmoore merged commit d0cb879 into ome:develop Sep 6, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants