Gallery 3 permissions

I'm setting up a gallery for a photographer, where users will be able to log on and access the photos from their event. So for example I have set up groups called event1, event2 and event3, and also created albums called event1, event2 and event3. Each album is given viewing permissions for the corresponding group. So a user in the event1 group logs in and sees the photo album from event1, etc. This works fine.

But then, if I were to create a new group called event4, then create an album called event4, when I go into permissions, the event4 group permissions has a padlock on it. If I click it, every other album loses its permissions and gets event4 permissions.

However, If I instead go to the root folder and look at permissions, all groups have viewing permissions except event4 (the reason it has a padlock on it), so if I click the tick for event4, every album has viewing permissions for their own group, and that of event4.

This means if I create a create a new private album, and a new group to go with it, I then have to go through every previous group and untick permissions for the new group.

Is there a way to create a new group and not have it automatically given access to every existing folder? this would make more sense

it is like you said

Root
-- event1
-- event2
-- event3
-- event4

I currently have the permissions for view ticked on everything in the root. Which is fine until I add a new group and album. As soon as I make the new album visible to the new group, every album becomes visible to that group, so I have to go through the permissions of each album one by one, unticking the new group.
Does that make sense?

but it means if i create a new group, it is denied access to everything at root, which is fine, but if i enable access at root it can see everything. Surely a perfect use for this gallery would be a private gallery system for photographers, but it seems to easy to give a new user access to everyone elses private stuff by mistake. It would make more sense to be adding permissions for a new user, not removing.

at the moment, its:

create Album 4,
create Group 4,
give group 4 access to root,
remove access from Album 1
remove access from Album 2
remove access from Album 3

to me it makes more sense if it is:

Create Album 4
Create Group 4
Give access for Group 4 to Album 4

What about having the default permission set to being able to read? Is there a reason they are set to deny by default for new groups when the default permissions for guests is being able to view everything? Perhaps just copy the permissions that have been set on the Everybody group by default so new groups inherit at least what guests have.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here

This might take care of one of our inevitable permission issues which is that right now we have to show every group on every permission dialog. If we were able to say "only these groups are relevant" it would make that problem much easier. But on the flip side, it adds complexity to the permissions dialog because now you can't tell at a glance what permissions are set. What you're proposing is a closer to what we had in G2, where the policy was to deny and you could create exceptions on a per item basis. For this model to work we'd have to have an invariant like "Any group permissions assigned to a parent must also be reflected on the child" so that we can handle cascading permissions.

Would the default policy be assigned at the group level? Ie, would that be in the group admin? It would be really helpful here if you could make mockups of the permissions (and maybe group editing) UIs for the scenario you have above. That would help us figure out how to cover this case without damaging the use case for 80% of our users.

thanks for your help, gillux!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git

Hello!

I am thinking about possible permission systems of Gallery3 because the current one (RC2) does not fit my needs.
gillux, bharat, matjkd, I would be pleased if you would read this and comment to help me elaborate.

I'd chose this post to reply to because both my use case as well as the direction my solution lies in seem similar to those mentioned here.

bharat: I've learned about two design principles from the developers point of view until now:
- "one glance permissions": Every permission screen should show all permissions granted.
- "no permission islands": Every permission granted should be

Are there more? In case there is something to read before thinking about this any further, kindly point me in the correct direction.

What I do not like about the current (RC2) permission system of G3, that is:
What I would like to change:
- While deploying a new group it gets access to possibly unrelated (all) albums (when giving a right to the root album).
- All groups are shown in every permission window. This kind of contradicts the "one glance permissions" target when
large number of groups are involved (and are visible although they do not have any permissions)
- Every user can see all first level albums (assuming he has any rights on any album - leading to
the same right on the root album).

I cannot (or could not until now) think about a way to archive any of this without expanding the permission system of the root album at least. Note all ideas might make the root album special, but need not to. I'd prefer not to do this to make the permissions concept easy to understand and flexible in its possibilities.

Ideas:

OPTIONAL INHERITANCE: I thought about making the inheritance optional. One click to give a right - then an additional click to inherit this right to sub albums. This could be displayed within the rights window with an altered or an additional icon.

That way you could give a group the view right for an album (i.e. the root album) without altering sub-albums.

Sub albums could then display their own rights or inherited rights similar to what is done now.

HIDE USERS/GROUPS: Hide users and groups which do not have any rights. There is nothing to display, so do not waste space. Exceptions my be special groups like "registered users" and others which might come. Then have a possibility to add a new user/group to the window so it is visible in the overview and it can be assigned rights afterwards. If a user/group is displayed in a window, keep it there until the window is closed, even if any rights are revoked from him. This ensures no surprising changes in display happen while changing rights and makes it possible to positively check for a user/group to _not_ have a right while changing thinks.

HIDE SUBALBUMS: Hide (sub)albums a user has no view permission for. In my opinion this is important for many use cases and I do not see any reason to display an album the user cannot access at all from a usability point of view. Performance penalty should be low as this only affects sub albums and only direct childs.

Although i've read trac ticket 1130 and the posts above, i am not sure i did understand the proposal with the policy yet.

Gillux: Do you think my proposal would allow your use cases, too? If not, could you help me understand what is missing?
Did anyone think about how to display the policy part in the permissions window?

My use case like it is implemented in G2 currently - in case someone wants to join my tries to find a solution:
- Several (first level sub-)albums, one for each event (like one party, group jorney, ..).
- One group per album with read rights. Everyone who needs read access gets into this group.
- One "group user": For all people who do not need an individual account as they
are not technically interested, do use only one album at the installation and/or
just don't care.
=> This is a kind of poor mans password protected album without accounts.
- People which do use more than one album do get an own account.
- People who want to add their photos do get an account.
- Many albums have subalbums: One per photographer. Read-permissions are inherited,
everyone has write permissions to his sub-album only.

My proposals would allow this within G3 while keeping the user interface clean.

Thanks for reading and considering my ideas,
regards

butch

ok.
so i am waiting for that. For small sites and one administrator the current permission system would good be enough. I guess. It should be a comlete group based system.