Project-Id-Version: Trac 0.12
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 <>
Language-Team: en_US <>
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 7 (modified by sebastian, 10 years ago) (diff)


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
      • 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_ORIGINAL: Media could be seen in all preview sizes and could be downloaded
  • 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
      • 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 accessible for ordinary users, user's own image group. (System groups dont have an group owner.)
      • GROUP_FLAG_VISIBLE: indicates a group which is visible for all users. These groups are shown in the media details. Users can create visible groups.
      • GROUP_FLAG_OPEN: indicates a group which could be joined freely without an acknowledgment of the group owner. Users can decide if the group is open or closed.
      • GROUP_FLAG_SHARED: indicates a group which could be shared between different users. The group owner keeps the control of the group members and can add or delete members of it.


  • 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)


  • Behavior
    • Create GroupAccess behavior(models/behaviors/group_access.php) which handles all the new access stuff and all its "magic". See (basically behaviors enriches a model class with a behavior and all functions of the behavior is callable from the model itself)
    • Add GroupAccess to behavior to Media model
    • Adapt access management to the behavior and adapt the code, e.g. FileManager?, WebDAV, etc
  • MVC
    • Adapt the group model/view/controller
    • Add database initialization of public system groups in the setup to ensure required groups (e.g. group of public media, group of media accessible for users)
      • public, users, guests
      • Options could define the initial groups for anonymous user and for user creations
    • 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)
      • Options could define the initial groups for media creation
    • 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.
  • Simplified 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 accessible for 'john' select all media with 'john's private user group: SELECT * FROM media INNER JOIN group_media ON = 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 = group_media.media_id AND group_media.group_id IN (1, 2, 3)


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