Project-Id-Version: Trac 0.12
Report-Msgid-Bugs-To: trac-dev@googlegroups.com
POT-Creation-Date: 2008-01-30 09:20+0100
PO-Revision-Date: 2010-07-19 23:05+0200
Last-Translator: Jeroen Ruigrok van der Werven <asmodai@in-nomine.org>
Language-Team: en_US <trac-dev@googlegroups.com>
Plural-Forms: nplurals=2; plural=(n != 1)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Generated-By: Babel 0.9.6

Warning: Can't synchronize with repository "(default)" (Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? ). Look in the Trac log for more information.

Version 5 (modified by sebastian, 9 years ago) (diff)

Add flag and acl proposals for the group model.

This Model is still in the design phase. If you have comments or ideas feel free to add them.

Current Access Model

  • access rights are defined in the picture
  • access rights can only be modified by its owner
  • permissions can be set for group, phtagr users that are logged in and the rest of the world
  • users can create groups that are controlled by the group creator
  • pictures can belong to one and only one group

This model works well, but is very restrictive and hard to understand for non-geeks.

New Access Model

  • access rights are defined in groups
  • access rights can be defined by group moderators
  • users can search, create, and join groups
  • pictures can belong to more than one group
  • for each user there is a private group in which all pictures of the users are
  • members of a group can add own pictures to the group

Advantages of the New Model

The new model better represents the way we would share without internet galleries. We would meet up with friends after a trip, exchange pictures and everyone is happy. We do not have to think for each picture what the access rights should be, instead we rather think with whom we want to share them.

An Example

If a member Josh wants to share pictures with only a group (say his amateur drama group).

Flaws in the Current Model

  • Josh has to add each of the group members manually, if Josh is away on a world trip and currently has no internet, new members of the drama group would have no way to join the group!
  • Even though this group all of them want to share with each other, only Josh is able to add pictures to this group, since it is his group.

Solution with the New Model

Josh would create a group, add a few or all the members as Moderators to the group. The moderators can then add new members while Josh is away. And as each member can add pictures in that group also the second problem is solved!

Steps to do

This is an incomplete list of things that have to be done:

Specifications / Definitions / Repository

  • Create svn branch branches/phtagr-multiple-group-access-model for this non-minor change
  • Access rights granularity
    • Proposed ACL flags: GROUP_ACL_META_ADD, GROUP_ACL_META_DEL, GROUP_ACL_VIEW_PREVIEW, and GROUP_ACL_VIEW_ORIGINAL.
      • GROUP_ACL_META_ADD: MetaData could be added, but not deleted or overwritten.
      • GROUP_ACL_META_DEL: MetaData could be added, modified, and deleted
      • GROUP_ACL_VIEW_PREVIEW: Media could be seen in preview but the original media could not be viewed nor downloaded
      • GROUP_ACL_VIEW_ORIGINAL: Media could be seen in all preview sizes and could be downloaed
  • User Roles
    • owner: can assign moderators and perform everything else a moderator can (Do we need multiple moderators? This could be a open group. See group flags)
    • moderator: can add/invite/delete users (Could be also a public group)
    • member: is allowed to view and assign images to the group
  • New Group Flags
    • Proposed flags: GROUP_FLAG_SYSTEM, GROUP_FLAG_PUBLIC, and GROUP_FLAG_OPEN.
      • GROUP_FLAG_SYSTEM: indicates a group of the system which are initialized at installation or created by admins and sysops. These groups could not be modified or deleted by ordinary users. E.g. the group of public images, group of images accessable for ordinary users, user's own image group. (System groups dont have an group owner.)
      • GROUP_FLAG_PUBLIC: indicates a group which is viewable for all users. These groups are shown in the media. Users can create public groups.
      • GROUP_FLAG_OPEN: indictes a group which could be joined freely without an acknolegement of the group owner. Users can decide if the group is open or closed.

Database

  • Database Schema (config/sql/schema.php)*
    • Change relationship between model Media and model Group from "Media hasMany Group" to "Media hasAndBelongsToMany"
    • Delete "group_id" in Media model
    • Add hasAndBelongsToMany table "groups_media" with "group_id" and "media_id"
    • Add fields to Group schema: flags (int), acl (int), description (text)

Programming

  • Behaviour
    • Create GroupAccess behaviour (models/behaviours/group_access.php) which handles all the new access stuff and all its "magic". See http://book.cakephp.org/view/88/Behaviors (basically behaviours enriches a model class with a behaviour and all functions of the behaviour is callable from the model itself)
    • Add GroupAccess to behaviour to Media model
    • Adapt access management to the behaviour and adapt the code, e.g. FileManager?, WebDAV, etc
  • MVC
    • Adapt the group model/view/controller
    • Add database initialisation of public system groups in the setup to ensure required groups (e.g. group of public media, group of media accessible for users)
    • On user creation create private user group
    • List all user's public groups in his profile
    • On media creation assign the private user group (see section Database Layer)
    • Add a group search which should handle multiple groups (and exclusions)
    • Write schema migration script like vendor/shells/upgradeMediaSchema.php to ensure migration of older phtagr versions

Database Layer

  • If each user has its own private user group and all his media has at least this private user group, the SQL magic and access management is reduced to an INNER JOIN w3schools to the user's groups. The private user group should be handled invisible and must be set always on creation or media group assignment changes.
  • Simplefied Cases: User 'john' has the private user group <1:john> (syntax <group ID:group name>). He is also member of groups <2:nature> and <3:buildings>.
    • To fetch all media accessable for 'john' select all media with 'john's private user group: SELECT * FROM media INNER JOIN group_media ON media.id = group_media.media_id AND group_media.group_id = 1
    • Select all media which are accessible for 'john' (all media having 'john's groups): SELECT * FROM media INNER JOIN group_media ON media.id = group_media.media_id AND group_media.group_id IN (1, 2, 3)

Other

  • Write documentation for new access model
  • Test it and merge it to the trunk
  • Shout "We rule the world"