From: Tim A. <tna...@sh...> - 2008-11-30 15:24:28
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Sounds sane and reasonable to me.<br> <br> Bharat Mediratta wrote: <blockquote cite="mid:493...@me..." type="cite"> <pre wrap="">I'm implementing the permission model for Gallery3. It's going to be fundamentally different from both G1 and G2, but in a way that should make more sense to our users and be easier to understand in the UI. This is still very much a work in progress and all decisions are reversible. Please note that I am balancing the following factors: 1) Comprehension. Permissions should be simple to understand and you should know their implications. We want to avoid the situation where you think that you've protected an image, but it's really public if somebody knows the right URL. This combats a problem we had in G2 where permissions were per-item. 2) Efficiency. 2a) I want to be able to do a single query with no table joins that returns the complete set of photos and albums that the user is allowed to see. It has to be a single query in the database so that we can do pagination efficiently. It should avoid table joins so that we're not doing large table cross products when searching the entire Gallery. 2b) I want to be able to do a single query to get the complete permissions for a set of items. Preferably also with no table joins. 3) Modularity. Modules should be able to add their own permissions easily. Below is the PHPDoc description from a new helper class that I'm writing. Let me know what you think. -Bharat ======================= Manage access to items. Permissions are hierarchical. If you apply a permission to an album, you're applying it to all elements below that item. This mimics Gallery's hierarchical and allows us to enforce a rule that if a group cannot view a specific album, that group cannot view any of its sub-albums. This way you can create a "private" hierarchy and not worry about parts of it accidentally becoming visible later on. This does limit you from having exception cases deep down inside your hierarchy where different rules apply, but the philosophy here is that the lack of exceptions will lead to a simpler and more intuitive interface. Permission Rules: R1) Permissions apply only to items vs. groups (not users, or other models) R2) All permissions are revoked by default. R3) Revoked permissions cascade downwards. You cannot grant a permission on an item if one of its ancestors has revoked it. R4) A permission can only be allowed on items where the parent item already has that permission Practical applications for an album hierarchy like this: A1 / \ A2 A3 / \ A4 A5 o If A1 is marked as not-viewable to group::EVERYBODY, then none of the rest of the hierarchy can ever be marked as viewable for that group. o If A1 is marked viewable by group::EVERYBODY and A3 is marked non-viewable by group::EVERYBODY then o A2 is viewable and A4/A5 are non-viewable by group::EVERYBODY o A4 *cannot* be marked viewable because A3 overrides it o A3 *can* be marked as viewable because A1 allows it, and when this happens A4 and A5 immediately become viewable also. o In the UI for A4 we can express the fact that it cannot be made viewable unless you change the permissions for A3. o In the UI for A3 we can express the fact that if you make A3 viewable, it will also affect the viewability for A4 and A5. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world <a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a> __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> <a class="moz-txt-link-freetext" href="http://gallery.sf.net/lists.php">http://gallery.sf.net/lists.php</a> ] [ gallery info/FAQ/download --> <a class="moz-txt-link-freetext" href="http://gallery.sf.net">http://gallery.sf.net</a> ]</pre> <pre wrap=""> <hr size="4" width="90%"> No virus found in this incoming message. Checked by AVG - <a class="moz-txt-link-freetext" href="http://www.avg.com">http://www.avg.com</a> Version: 8.0.176 / Virus Database: 270.9.11/1820 - Release Date: 11/29/2008 6:52 PM </pre> </blockquote> </body> </html> |