Permissions Remastered?

stoffer
stoffer's picture

Joined: 2005-02-10
Posts: 75
Posted: Thu, 2005-05-12 18:33

Hi, I don't know how other people fell about the Permissions User-Interface, but I think it can be a bit bewildering for new users as it is today. I of course fully understand that this is still Beta so that the layout of the UI might still be a work-in-progress, but here goes...

I would suggest scrapping the dropdown menus and replacing each and every possible permission with a check box (granted or denied). Sure it will take up more place than now, but I don’t think that people will mind when things in turn are presented so logically. There should of course be a “Check all

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Thu, 2005-05-12 18:37

The permissions UI has been on our task list for a long time.. we just haven't gotten to it yet :)
http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=103796&group_id=7130&group_project_id=14056
Ideas on how to make it better are most welcome!

 
nivekiam
nivekiam's picture

Joined: 2002-12-10
Posts: 16504
Posted: Sat, 2005-05-14 02:49

I did a little (very ugly) mockup of a permissions page I was thinking about. I threw it together really quickly and shows how rough my HTML skills are and the shoddy formatting of HTML code from Nvu.... But I think it could be much more friendly to use for an advanced interface.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2005-05-14 10:03

what is the thing on the top left about? add, remove groups? to change permissions for mutliple groups at once?? i find that more confusing.
i'd keep the group / user selection as it is. not sure about the long list of radio buttons.
but an improvement is definitely needed.

 
stoffer
stoffer's picture

Joined: 2005-02-10
Posts: 75
Posted: Sat, 2005-05-14 14:01
nivekiam wrote:
I did a little (very ugly) mockup of a permissions page I was thinking about. I threw it together really quickly and shows how rough my HTML skills are and the shoddy formatting of HTML code from Nvu.... But I think it could be much more friendly to use for an advanced interface.

Yeah, I was thinking about something like this (just with checkboxes instead of radio buttons).

I don't, however, understand or like that add/remove groups thingy on the top/left.

*thinking and doing notes on a piece of paper*

Hmmm, okay here is another way to do it:

1) We include all the group/users/admin in a drop-down menu.
2) Bob then select one of these, say the guests.
3) Below the drop-down menu Bob is now presented with the permission options for guests. The options are presented as check-boxes.
4) If Bob want his guest to be able to add comments, he'll go check the "Allow Add Comments" box.

Bob can then quickly get an overview over what kind of permissions different members/groups have by selected them in the drop-down menu and comparing the checkboxes (since we'll keep the layout of them exactly the same way for all).

We might have to "grey out" (disable) some of the options for some ID's like admin or guests, but that is just an advantage because people then get a clear view over how the different ID's is envisioned. (Like the admin is more powerfull by having more options than users etc.).

 
nivekiam
nivekiam's picture

Joined: 2002-12-10
Posts: 16504
Posted: Sat, 2005-05-14 14:47

I was just pretty much copying the dialog box for setting NTFS permissions on windows computers. My intention with the list box was the same as a drop down box, it just reduces one click from a drop down box if you want to view or change the permissions someone has.

I agree it could be made more clear, even the dialog box in Windows isn't clear and could raise the same questions from a new user.

Example:
You want to view or change the permissions of "Everyone", just click on "Everyone" and the radio buttons are changed to show which permissions this group or user has. The Add button will add users or groups and the Remove button will remove a selected user or group.

See the attached screenshot of the NTFS permissions dialog box.

 
stoffer
stoffer's picture

Joined: 2005-02-10
Posts: 75
Posted: Sat, 2005-05-14 14:58

Aaahh, now I understand! Yes, the permissions part is is pretty much how I envision it too. :)

1) I would still prefer of the drop-down menu for selection of user-ID because it would otherwise introduce a lot of clutter when having a large number of users.

2) I don't think it would be a smart move have the Add User and Remove User on the permissions page (it is not there today). People might make a stupid mistake and remove someone while setting permissions on a given photo. :P

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2005-05-14 15:04

just a quick note: before we try to copy something, let's make sure it's something worth copying. MS isn't famous for good UIs. It's just that they dominate the market and we are used to their (bad) UIs because we are exposed to these UIs for 10+ years.

 
nivekiam
nivekiam's picture

Joined: 2002-12-10
Posts: 16504
Posted: Sat, 2005-05-14 15:38

Note: I'm not pushing this exact interface, just suggesting it's a large improvment over what we currently have. Just clarifying a few things.

stoffer wrote:
1) I would still prefer of the drop-down menu for selection of user-ID because it would otherwise introduce a lot of clutter when having a large number of users.

The list box is a specific size. It doesn't grow, if there are more users or groups than what will fit in the box then a scroll bar appears.

stoffer wrote:
2) I don't think it would be a smart move have the Add User and Remove User on the permissions page (it is not there today). People might make a stupid mistake and remove someone while setting permissions on a given photo

That's not to add or remove user accounts to G2 it's to add or remove users or groups to set permissions on.

valiant wrote:
just a quick note: before we try to copy something, let's make sure it's something worth copying. MS isn't famous for good UIs. It's just that they dominate the market and we are used to their (bad) UIs because we are exposed to these UIs for 10+ years.

I agree, however, I just have yet to see a better dialog box for setting permissions and I'm pretty much just a Windows user who dabbles in Linux.

I see from this task, http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=103796&group_id=7130&group_project_id=14056 that someone has mock-ups they've done, but where are they?

 
stoffer
stoffer's picture

Joined: 2005-02-10
Posts: 75
Posted: Sun, 2005-05-15 13:53
nivekiam wrote:
The list box is a specific size. It doesn't grow, if there are more users or groups than what will fit in the box then a scroll bar appears.

Okay, sorry for being a bit dense for that one! :wink:

Come to think about it, we could use the list instead of a drop-down menu as a big advantage, if we allow people to select multiple users (Ctrl+click) and check any permission checkbox for all those selected user at once!

Now that would be cool and spare people a lot of work on permissions: If they for example want to change "Allow Add Comments" for at load of users on an item, it goes: Just select Ctrl+click on those users and check the according checkbox! Quick and easy to understand! 8)

nivekiam wrote:
That's not to add or remove user accounts to G2 it's to add or remove users or groups to set permissions on.

Hmmm, okay I think I understand, but it still doesn't make sense to me. I think it is a much more easy to understand concept for people, if all their users just show up in the list. No 'where the heck did the my Bob account now go'?-problems. If they excist, they excist. :wink:

 
moku

Joined: 2005-05-16
Posts: 2
Posted: Mon, 2005-05-16 16:44

Hello,

I tried to synthetized a bit everything said until now, and add a few features that would be very usefull (well, at least to me. But maybe only to me! ^^ ).

Here is the mockup:
http://moku.ghosthack.net/data/dev/gallery/permissions_mockup.html

I did not wrote the javascript for it, but of course it is supposed to do something when you change the select-list "Preselected choices:" or click on the link "Hide to Everybody".
The "Preselected choices:" are supposed to simplify the rights management, because it may be confusing to select between so many choices when you only want to hide some photos, for example, as said mindless in the Task list.

I wonder if this is a good beginning for an ergonomical UI? ^^

(change owner is at the bottom because I guess it is not something you do more often than changing rights, but maybe I'm wrong)

I also think it would be usefull to being able to apply some permissions changes to a list of photos (directly from the album view) and not only one by one, wich is too slow and boring when you have many photos you just want to hide. (that's my case)

PS: sorry for my poor English...
PPS: to the devs: guys, Gallery2 is really a great work! I was amazed when I tried it. Thank you.

 
Arjen

Joined: 2003-06-09
Posts: 47
Posted: Mon, 2005-05-16 17:31

I think the permission issue is very complex. There are really thousands of combinations that can be made. The challenge is this is to on one side provide a lot flexibility and customization and on the other side also have a very easy and time inexpensive way to administrate the permissions.

In addition to Nivekiam's mock-up, I think there are permissions to be set at three different categories, item, album and general. Each of this category has different permissions and each of these permissions can have an allow and deny assigned as also indicated in the mock-up.

As a first thought I can think of the following permissions in the different categories:

Item category                      Allow    Deny
-------------------------------------------------
Delete Item   			
Edit Item   			
View Thumbnail Version   			
View Resized Version   			
View Fullsized Version   			
View All Versions   			
Comments -- Full Control   			
Comments -- Add   			
Comments -- Delete   		
Comments -- Delete Own   		
Comments -- Edit Own   			
Comments -- Edit   			
Comments -- View   			
Comments -- Search 			
Reorder item			
Create link			
Print item		
Crop thumbnail
Rotate photo
Scale photo
Resized photo
Watermark	


		
Album category                     Allow    Deny
-------------------------------------------------
View album
Add new album			
Edit existing album			
Delete album			
Add Items to album   			
Move album			
Reorder album			
Change theme			
Edit theme			
Change layout			
Edit layout			
Edit default resizes			
Recreate thumbnails and resizes			
Change highlight			
Picture size limit			
Edit custom fields			


General category                   Allow    Deny
-------------------------------------------------
List users
Site admin - Full Control			
Site admin - General			
Site admin - Module install			
Site admin - Module deinstall			
Site admin - Module activation			
Site admin - Module deactivation			
Site admin - Captcha
Site admin - Core
Site admin - Debugging
Site admin - Members
Site admin - Quotas
Site admin - Rearrange
Site admin - Registration
Site admin - Search
Site admin - URL Rewrite
Site admin - User Albums
Site admin - Gd
Site admin - ImageMagick
Site admin - NetPBM
Site admin - Image Block
Site admin - Comments
Site admin - Custom Fields
Site admin - EXIF/IPTC
Site admin - MIME Maintenance
Site admin - MultiLanguage
Site admin - Archive Upload
Site admin - Migration
Site admin - Nokia Image Upload
Site admin - Publish XP
Site admin - Remote
Site admin - Upload Applet
Site admin - WebCam
Site admin - Album Select
Site admin - Ffmpeg
Site admin - Dcraw
Site admin - Module (...)

The list above already has a lot of permissions and is not even complete. In this way, you can easially get lost and drowned. Therefore I think the concept of roles could be used. Roles could be thought of a group of permissions. In this way, several roles could be standard provided and people can create their own roles.

For example standard the following roles be provided (just a first thought):

Quote:
Role: Site admin
Item category
Assign all permissions
Album category
Assign all permissions
General category
Assign all permissions

Role: Album admin
Item category
Delete Item
Edit Item
View Thumbnail Version
View Resized Version
View Fullsized Version
View All Versions
Comments -- Full Control
Comments -- Add
Comments -- Delete
Comments -- Delete Own
Comments -- Edit Own
Comments -- Edit
Comments -- View
Comments -- Search
Reorder item
Create link
Print item
Crop thumbnail
Rotate photo
Scale photo
Resized photo
Watermark
Album category
View album
Add new album
Edit existing album
Delete album
Add Items to album
Move album
Reorder album
Edit theme
Edit layout
Edit default resizes
Recreate thumbnails and resizes
Change highlight
Picture size limit
Edit custom fields
General category
Assign all permissions

Role: Display
Item category
View Thumbnail Version
View Resized Version
View Fullsized Version
View All Versions
Comments -- Add
Comments -- Edit Own
Comments -- View
Comments -- Search
Album category
View album
Add new album
Edit existing album
Delete album
Add Items to album
Move album
Reorder album
Change theme
Edit theme
Change layout
Edit layout
Edit default resizes
Recreate thumbnails and resizes
Change highlight
Picture size limit
Edit custom fields
General category
List users

These roles can be changed and created in the site admin section. For example I can imagine that some people will want to allow an album admin to be able to change the theme to something else and other people want a consistent lay-out thoughout the Gallery and do not want album admins to have this permission.

Once the roles have been created, they can then be assigned to users or groups on the general/album/item level, where the lowest level overrides the parent level.

In my opinion the advantage of having roles is that certain permissions have a logic grouping for people. In this way, permissions can be clustered and then be assigned to users/groups on a certain level. I think this would reduce the number of handlings to assigne the apriopriate rights to a number of groups/users on a object.

These are just my own thoughts and I do not know what the impact is on the Gallery code/archritecture, but I wanted to share this with you. I would like to hear other thought on this. Also, I am not sure whether I have externalized my thoughts to be very understandable for you, but if some clarification is needed, please indicate.

 
yys2000

Joined: 2005-05-16
Posts: 13
Posted: Tue, 2005-05-17 01:11

Agree! Same idea of Solaris Role concept. When it can be available?

 
moku

Joined: 2005-05-16
Posts: 2
Posted: Tue, 2005-05-17 08:05

Yes, "Roles" is to "Rights" what "Groups" is to "Users", so it is all good. Good think.

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Thu, 2005-05-19 03:21

How are "Roles" different from "Groups" ? You can create a new group, assign it permissions and add users to the group. Any one user can be in as many groups as you'd like. As far as I can tell, they serve the same purpose.

Can somebody provide me with an example of something that you can accomplish with Roles that you can't accomplish with our existing Groups? Thanks.

 
nivekiam
nivekiam's picture

Joined: 2002-12-10
Posts: 16504
Posted: Thu, 2005-05-19 03:28

I was trying to figure that out too. I thought I had it figured out, but then just talked myself out of it as I was typing this reply and deleted most of my comments.

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Thu, 2005-05-19 03:45

Remastering the permissions UI is very important. I like what I've seen thus far.

A couple of points. Arjen's listing includes a lot of things for which we don't actually have permissions. If we go with an approach like that, we'll have to broaden our concept of permissions somewhat. I'm happy to consider that, but it's out of the scope of this discussion. As I see it, the purpose of this discussion is about figuring out a better ui for our existing permissions system.

Nivekiam's solution is interesting to me. It implies that when you select a user from the list box, all the checkboxes will change. This means that there's some state that is invisible, and you can only see it when you select a given user. I think that's going to be confusing since you can't see at a glance what your permissions are. You need to click each user or group one at a time to see what permissions you've granted.

I envision a UI with a grid of checkboxes. Down the left side is permissions, across the top are users and groups. Permissions (rows) are fixed, but you can add new users/groups (columns) at the top with some javascript fu. There's a checkbox next to Core, and if you select that it checks all the boxes in core for you. Same for comments and Other. You check all the boxes that apply and save.

This way you see all the permissions at a glance and can add/remove them without too much difficulty. How does that sound? Does anybody want to make a mockup of that for us to look at?

 
virshu
virshu's picture

Joined: 2003-09-13
Posts: 314
Posted: Thu, 2005-05-19 03:58

Separating Roles from Groups makes sense if you have very many groups and very manypermissions. In such case you will combine permissions into roles, and assign such multiple roles to groups.

[bharat], I think "what can be done with roles that can't be done with groups" is not a valid question. By the same token, "what can be done with groups that can't be done with users"? After all, you can assign all applicable permissions to the appropriate users. Groups allow you to combine users in a logical way and assign such permissions to one group. Similarly, Roles allow you to combine permissions and assign such combined permissions, rather than individual permissions.

Hope it makes sense...

That said, I think roles can provide such simplification in some situation, and cause confusion in others... I agree with several posters that current permission UI needs major redesign. Roles might be part of such redesign, however, I don't think it adds a lot of value to offset additional confusion (it's just my opinion, of course - I may be completely wrong).

Moreover, since permissions are internally just bits, I can imagine an add-on module that allows you to maintain roles by ORing the permissions. In such case it will be transparent to the security model...

 
nivekiam
nivekiam's picture

Joined: 2002-12-10
Posts: 16504
Posted: Thu, 2005-05-19 05:03

Ah, yes. I had to do a little searching, but it's clearer to me. I found these helpful explainations. Roles are essentially special groups, assigned at the application level. You'd still use Groups in conjunction with Roles, but Groups would be assigned at the object level.

http://blogs.sun.com/roller/comments/rohanpinto/home/in_the_beginning_there_were

http://www.dmdeveloper.com/articles/concepts/groups_vs_roles.html

Sharepoint, which I regrettably have to use at work, uses a similar concept. You can then refine permissions for individual Domain groups or users at the object levels, but Roles allow you to assign someone the ability to edit content or comments for the site without having to create a special Group for this and then assigning that group to the objects. In the scope of Gallery I'm not sure why we'd want to add this extra level and possibly complicate things further. Just my opinion.

I do have some changes to my mockup after these comments and bharat's input. In fact I think bharat's input is really close to what's been rolling around in my head the last few days. I'll make the changes to my mockup and post Sunday (05-22) or earlier.

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Thu, 2005-05-19 05:55

virshu, I undestand what you're saying about Roles. My feeling is that Groups provide us with a large benefit (being able to affect many users at once by tweaking a group setting). By extension, Roles would allow us to affect many groups at once by tweaking a single role setting. This is of smaller benefit to us. Even relatively large sites (like this, the Gallery website) has less than 15 groups where some users belong to multiple groups. So Roles may make the job easier for some small percentage of our users, but in return it's a complicating factor in the UI for everybody. I think it's overkill for now. I agree with you that we could add them later as needed.

nivekiam, I look forward to seeing your next mockup!

 
stoffer
stoffer's picture

Joined: 2005-02-10
Posts: 75
Posted: Thu, 2005-05-19 08:17
bharat wrote:
I envision a UI with a grid of checkboxes. Down the left side is permissions, across the top are users and groups. Permissions (rows) are fixed, but you can add new users/groups (columns) at the top with some javascript fu. There's a checkbox next to Core, and if you select that it checks all the boxes in core for you. Same for comments and Other. You check all the boxes that apply and save.

This grid of checkboxes (with permissions along the left side and users along the top) would by far be the best approach, if possible.

I was thinking about the exactly same layout at first, but then kinda gave up the idea because it could be a potential layout mess at the top once you have 20+ users with weird, long names. :wink:

But on the other hand: We have to pick our poison, and all in all I vote for The Grid because it gives the user an intuitive interface to quickly change permissions.

 
Arjen

Joined: 2003-06-09
Posts: 47
Posted: Fri, 2005-05-20 15:59

Please forgive me for being hard headed, but I would like to give another shot to the role concept. First I will clarify it more and then I will show a scenario where I think the role concept would be proof its value.

Explanation

Current situation

In the figure below I have visualized the current situation.

[img]http://www.xs4all.nl/~gidie/dia1.jpg[/img]

In this case, the following activities are perfomed:
1. Groups are formed by combining multiple users, which is done on a central level in the site admin.
2. Then, on each entity (album/image) permissions are assigned to a group (or user).

Proposal

In the figure below, I have visualized my proposal.

[img]http://www.xs4all.nl/~gidie/dia2.jpg[/img]

In this case the following activities are performed:
1. Groups are formed by combining multiple users, which is done on a central level in the site admin (same as in current situation).
2. Roles are being formed by combining multiple permissions, which is done on a central level in the site admin.
For a mock-up see:

3. Then, on each entity (album/image) a role is assigned to a group (or user).
For a mock-up see:

Scenario
Let's imagine a gallery site where poeple can register and have their own album where they can put their own foto's. Currently there are about 500 registrated people (and therefore also 500 albums in the Gallery's root).

Each user currently has 7 different permissions on their own album:
- [comment] All access
- [core] Add sub-album
- [core] Add sub-item
- [core] Delete item
- [core] Edit item
- [core] View all versions
- [core] Change item permissions

-------------------------------------------------
Now, let's assume that the owner of the Gallery wants to change the policy for registered people. He does not want people to be able to change the item permissions.

Current situation
In the current situation, each user has the 7 permissions assigned on his album. In case of the policy change, the following must be done:

Each album (500 albums!) must be edited and the permission [core] Change item permissions must be removed. Changing 500 albums is a lot of work!

Situation with roles
In the current situation, a role called 'registrated users' is being defined that contains the following permissions:
- [comment] All access
- [core] Add sub-album
- [core] Add sub-item
- [core] Delete item
- [core] Edit item
- [core] View all verions
- [core] Change item permissions

And each user album has the 'registrated users' role assigned on to its user.

In case of the policy change only 'registrated users' needs to be changed at the site admin, where the permission [core] Change item permissions is being removed. And not every album needs to be changed.

---------------------------

I think the current situation is very handy if groups of people needs the same permission on the same entities.

However, if the same users needs the same permissions on different entities, then the roles concpet would be more easy as the scenario indicates.

I am aware that this is way more than 'just' a GUI change and also requires the underlying architecture to be changed. Perhaps this is also too complex much for G2.0 anyway and should only be considered for further versions only.

I would like to hear your opinion about this.

Best regards,

Arjen[/]

[/]

[/]

 
masi

Joined: 2005-05-02
Posts: 6
Posted: Sat, 2005-05-21 04:16

Makes it clear for me. I don't know about the technical work though. But what I definitetly want, whether with roles or maybe just some smart ui, is to assign multiple items the same permission at once.

For example I've a gallery with 50 pictures, but only 25 are for public eyes. The others should be seen by group members of this album only. (I'd have a group for each album)

Atm, I need to edit each item by hand, don't I?

Something like the delete photos check box list, would be sufficient I guess.

Workflow: The album and sub-items permissions are "view by everyone" first. Click link to change a photos permission, set the photos checkboxes for which the submissions should be changed. Now, the simplest would be, to be redirected to the current/future permission page, with a list of the previously checked items shown and then change their permissions as usual at once.

Side note:
Not as complex as the role model would be some "predefined permissions" list. Just a set of permissions that are used often, to be selected from a drop down. Which then check the boxes with some .js magic. Just for the convenience.

Btw, I would like something like the role-model. Makes it more flexible IMHO.

 
nivekiam
nivekiam's picture

Joined: 2002-12-10
Posts: 16504
Posted: Sat, 2005-05-21 18:39

Don't know how much of an improvment this is, but it's what's been going around in my head the last few days.

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Sat, 2005-05-21 21:41

@Arjen

Thanks for the detailed explanation. I have a much better idea of what you're getting at now. The main advantage of roles (from your explanation) is that it gives centralized permissions control to the Site Administrator, and item administrators can only grant roles to their users which means that you can make global permission changes readily. I agree that this would be nice, but I fear that most Gallery users don't want or need it, and the additional complexity of role management is going to make our permissions UI even less useable for small-medium sized gallery installs (which is probably 80% of our user base). This is also too large in scope for G2.0, but it's something we could implement in the G2.1 time frame as an advanced permissions interface.

@Masi

I agree that we should aim for bulk permission changes. That's something that we should try to accomplish with this UI overhaul. I think that you can accomplish what you want without roles.

@Nivekiam

This is still more complicated than I think it needs to be. I think what we really need is something very simplistic that gives users a very simple view into the state of their permissions. I'm attaching a PNG which is my vision for what would be easiest.

In my vision, you can add new users by typing their name into the text box at the top of a new column. You can remove users by clicking the [x] next to their name. You can add/remove permissions by checking the appropriate checkboxes. Note that the permissions are indented to indicate permission groupings. If you check a box that has sub-permissions, it will turn all of them on/off. So if you turn on "All Comment Permissions", it will check all the other comment boxes for you. If you uncheck one of the sub comment permissions, it'll uncheck the "All Comment Permissions" box but leave the other comment permissions checked.

Note that there's no Site Admins column, becase they always have all access. And we should also have a "apply to children" checkbox.

I think this UI covers setting permissions for a single item just fine. What it doesn't cover:

  1. Dealing with the children with dissimilar permissions
  2. Bulk permission changes for peers

I think we can fix the bulk permission changes by providing an interface similar to what we have for ItemMove where you check the peer items that you want to change from a list, then make your permissions changes on those.

I don't have a good solution for the dissimilar permissions problem. Under an album you can have an unlimited number of items, and they can each have any of hundreds of legal permission combinations. Right now we have no way in the UI of knowing what the permissions are for any given item without looking at them individually. That's problematic. I think that we need an at-a-glance way of identifying items that have permissions that are different from the parent album. Perhaps we should have another button in this interface that lets you find those items and examine them?

Let me know what you think...[/]

 
stoffer
stoffer's picture

Joined: 2005-02-10
Posts: 75
Posted: Sun, 2005-05-22 11:03

bharat, this is exactly want I would be very pleased to see! :D

It is a very easy UI to understand for anybody that goes to the permissions page for the first time and it gives a good, instant visual feedback on who can do what.

bharat wrote:
In my vision, you can add new users by typing their name into the text box at the top of a new column. You can remove users by clicking the [x] next to their name. You can add/remove permissions by checking the appropriate checkboxes.

Sorry for still being a bit dense on this add/remove user feature. :oops:

I assume that you guys for ease of use want the admin to be able to setup the default permissions for all registrated users at once, and then afterwards be able to add specific users in order to change specific permissions for those only. Like all users can add items, but only [add] Bob can delete and edit these items?

If this is the case, it is a great feature. We just need to change the discription to something like "Default for Users".

This way an item would only have two colomns by default: one for Guest and one Default All Users, so that people can add exceptions for specific users.

bharat wrote:
Note that the permissions are indented to indicate permission groupings. If you check a box that has sub-permissions, it will turn all of them on/off. So if you turn on "All Comment Permissions", it will check all the other comment boxes for you. If you uncheck one of the sub comment permissions, it'll uncheck the "All Comment Permissions" box but leave the other comment permissions checked.

Excellent solution!

bharat wrote:
Note that there's no Site Admins column, becase they always have all access. And we should also have a "apply to children" checkbox.

Makea perfect sense.

bharat wrote:
I don't have a good solution for the dissimilar permissions problem. Under an album you can have an unlimited number of items, and they can each have any of hundreds of legal permission combinations.

Well, the most simple solution still is if people just make a (sub)album with the child-permissions applied.

If Bob have 23 photos that only he and Julia should be able to view (know-what-i-mean?! :P ), isn't it more easy for Bob, Julia and the admin to just create the sub-album instead of fiddling around with some complex Permission UI-page?

 
nivekiam
nivekiam's picture

Joined: 2002-12-10
Posts: 16504
Posted: Sun, 2005-05-22 20:52

bharat, I like that UI a lot. Now I see what you where talking about.

I do have a few concerns about that UI though. Adding a new user would not be very intuitive unless you had some default text in that box already, like "Add user/group type here" or something like that.

Also, if you have say 50 users or groups assigned to that object then that UI could get a little unwieldy in that it could get very wide and you'd need to scroll horizontally and then you wouldn't be able to see the permission descriptions that are on the left.

I'd like to see permissions on child objects handled like this. Each object would have an "Inherit" property. By default the object inherits their permissions from the parent. The child permissions automatically get the permissions from the parent object without the need to "replace permissions" on the child objects. If you then edit that object's permissions to not inherit from parent, it's permissions would not be updated when the parent's permissions are updated. However, at the parent level you would have the option of replacing permissions on child objects. This would override any inheritence and special permissions someone has placed on their sub-albums or items and they would need to be reapplied.

Also, when editing the permissions of a child object that is set to inherit permissions from the parent all permissions would be greyed out so they could not be edited until you selected the option to no longer inherit the permissions from the parent object.

I hope what I was trying to explain is clear.

 
stoffer
stoffer's picture

Joined: 2005-02-10
Posts: 75
Posted: Mon, 2005-05-23 07:04
nivekiam wrote:
Also, if you have say 50 users or groups assigned to that object then that UI could get a little unwieldy in that it could get very wide and you'd need to scroll horizontally and then you wouldn't be able to see the permission descriptions that are on the left.

As I have already written, I was thinking about the same problem. But if we use a common default for all logged in users and then only add exceptions to certain users, it shouldn't be that bad. Remember that people can setup up groups, which they could just add as an exception instead for adding 25+ users.

nivekiam wrote:
I'd like to see permissions on child objects handled like this. Each object would have an "Inherit" property. By default the object inherits their permissions from the parent. The child permissions automatically get the permissions from the parent object without the need to "replace permissions" on the child objects. If you then edit that object's permissions to not inherit from parent, it's permissions would not be updated when the parent's permissions are updated.

That is clear enough...

nivekiam wrote:
However, at the parent level you would have the option of replacing permissions on child objects. This would override any inheritence and special permissions someone has placed on their sub-albums or items and they would need to be reapplied.

This I don't fully understand?

 
nivekiam
nivekiam's picture

Joined: 2002-12-10
Posts: 16504
Posted: Mon, 2005-05-23 13:51
stoffer wrote:
As I have already written, I was thinking about the same problem. But if we use a common default for all logged in users and then only add exceptions to certain users, it shouldn't be that bad. Remember that people can setup up groups, which they could just add as an exception instead for adding 25+ users.

That's getting down to proper usage of groups. A lot of use will create groups. But most will not, nor will they even understand the concept of groups. I've seen it many times on a lot of the networks I've worked on. Individual users are assigned permissions instead of being placed into groups and the groups being assigned the permissions. In theory and practice it's great. In the real world a lot of people don't get it.

On a similar note though. What if for some reason, you had 50 different groups? I'm using a large number as an example.

stoffer wrote:
nivekiam wrote:
However, at the parent level you would have the option of replacing permissions on child objects. This would override any inheritence and special permissions someone has placed on their sub-albums or items and they would need to be reapplied.

This I don't fully understand?

Similar to what we have now. If you tell Gallery to apply permission changes to sub-items then any permissions you've set on those items are overwritten. Only with inheritence, it would also force any sub-item to being inherited again and if you wanted to apply special permissions on the sub-item(s) again you'd have to go back and do so.

With inheritence you can apply permission changes to parent items and effect all child items that are set to inherit permissions from the parent while still retaining any special permissions you've set on the child objects. Having a tool you can use to force a reset on all permissions below allows you as the admin to force child items to inherit permissions if the the inheritence was broken for some reason. It would probably be a very little used tool, but could be useful for administrating your gallery install.

It would also be great to see a tool like bharat was talking about so you could see what child items had different permissions set at a glance. Then from there you could possibly reset their inheritence without having to force everything else to inherit as well.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2005-05-23 14:01

We need a handful of the most often used predefined sets of permissions.

Extending this idea to user-definable sets of permissions is the same as talking of roles.

For the end-user, we don't have to talk tech-speak, "predefined set of permissions" with easy to understand monikers like "hidden album" are what we need.

I'd say the first step are predefined "sets of permissions" and a GUI to assign them to users and groups.
Extending this to the true roles concept shouldn't be that hard.

 
stoffer
stoffer's picture

Joined: 2005-02-10
Posts: 75
Posted: Mon, 2005-05-23 15:09
nivekiam wrote:
That's getting down to proper usage of groups. A lot of use will create groups. But most will not, nor will they even understand the concept of groups. I've seen it many times on a lot of the networks I've worked on. Individual users are assigned permissions instead of being placed into groups and the groups being assigned the permissions. In theory and practice it's great. In the real world a lot of people don't get it.

On a similar note though. What if for some reason, you had 50 different groups? I'm using a large number as an example.

True, but what poison to pick? :wink:

I do see one potential problem of using groups though: what if an user is member of two groups which is then assigned different permissions? Should the user then get the most restrictive set of permissions or the other way around? And how easy will this be for people to fully understand?

 
buut
buut's picture

Joined: 2003-06-18
Posts: 196
Posted: Mon, 2005-05-23 18:53

Silently following this discussion (as many do ;-) ), I came to the conclusion that all those who are contributing are familiar with the concept of permissions. Either with or without groups/roles.

For this group of 'system administrators' the permission system shouldn't be a major issue. Even with an 'unfriendly' gui!

The trick is to make the permission concept 'easy to use' for all those who aren't familiar with the concept.

To me 'easy to use' means that setting permissions should take no more than one action, any extra action would make it more 'unfriendly to use' .

This single action 'easy to use' method can be achieved by assigning every gallery item to three groups 'Everyone', 'Loggedin' and 'Superuser'.
These three groups will have a predefined permission set. Note: Superuser != SiteAdmin.

What make this 'easy to use' is the fact that the 'gallery administrator' only needs to known which user needs to be in which group.
This single action makes permissions 'easy to use'.

This approach may not suite every gallery site, it will certainly not suite complex sites, but it will cover the majority of the other sites.

Also this doesn't take away the wish of a better gui, but it will make the use of permissions very easy.

 
stoffer
stoffer's picture

Joined: 2005-02-10
Posts: 75
Posted: Sat, 2005-07-02 08:24

Is there any hope that anybody is working on this in order to get it into the Beta4 release?

 
nivekiam
nivekiam's picture

Joined: 2002-12-10
Posts: 16504
Posted: Sat, 2005-07-23 18:06

<as seen in a different thread...> http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=33191

I think the apply changes to sub-items check box should not be checked by default and that it should be below all of the permission settings.

Most people don't even notice it where it's at (I know I don't) and I can't think of why you'd always want to apply the permissions recursivly by default. I would think that would be the exception, not the normal case.

 
avizion

Joined: 2007-01-06
Posts: 2
Posted: Sun, 2007-01-07 12:47

I've been searching these forums from end to end, and this post seems to cover my question base best. I know it's an old topic - but I'll give it a shot anyway.

Basically - my issue with permissions is this: When you move an album from one tree to another, the permissions are moved along, and no relearnt based on the new tree's permissions.

Take this structure as an example:

+ Root
  - Album Collection 1
    + Album 1 A
    + Album 1 B
  - Album Collection 2
    + Album 2 A
    + Album 2 B

Now "Album Collection 1" is free for everyone to view, but "Album Collection 2" requires special rights. For the sake of simplicity, lets say that all "Albums" are created after permissions have been set on "Album Collections" (everything is just albums, but I use the term collection to paint the picture better).

If I move "Album 2 A" from "Album Collection 2" to "Album Collection 1" it cannot be viewed by "Everyone" because it had its permissions inherited from "Album Collection 2" at time of birth.

My "simple" question is - can this behaviour be changed easily - as in: did I miss a checkbox when creating "Album 2 A" saying "Always inherit permissions from parent album"?

I think I've played with the permission system long enough to claim that the current version of Gallery have no such functionality, but I would assume that this would be the most logical system to use, and the negated one should be an option.

I know the "Apply changes" (recursively) exists, but that's only in effect when you change permissions. It that would only be a "property" to the album, it would be a good start. Then new albums created under this album wouldn't be restricted in the same way - but naturally if the top album has narrow restrictions these apply to the child albums as well while they are attached to the parent.

Inputs are most appreciated. And let me know if my post doesn't make sense, and I'll do my best to elaborate.

Thank you for reading

- avizion

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2007-01-07 13:29

There's no option available to change this, no.
Your options:
- File a feature request, see the sfvote thing (http://gallery.menalto.com/sfvote_help)
- Write a patch yourself. Requires php and g2 knowledge
- Create a module yourself that intercepts moving operations and changes the permissions on the fly. Requires php and g2 knowledge
- Find a freelancer to do one of the above for you
- Do nothing :)

--------------
Enter the Gallery 2 Theme Contest today!

 
avizion

Joined: 2007-01-06
Posts: 2
Posted: Sun, 2007-01-07 13:59

Thanks for a quick answer :)

I will probably request the feature then, as I do not have the time at hand to sit down and learn the G2 code right now.

My primary use is just for hobby/vacation/party albums (though, lots of them!) - so it's not really mission critical - but I just thought it would be an obvious functionality to have implemented :)

I only found the lack of feature when I added some 100 pictures I hadn't sorted yet - so I put them in a hidden area and moved them out little after little. To my big disappointment I had created a lot of manual work for myself when I had to reset permissions everywhere ;)

Thanks again

- avizion