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.
Last modified 10 years ago Last modified on 01/25/10 18:55:47

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 through groups assignments
  • 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 user group in which all pictures of the users are
  • members of a group can assign this group to their own pictures

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

  • [done] Create svn branch branches/phtagr-multiple-group-access for this non-minor change

Types of groups

There are (basically) two types of groups: private and public (the system group is for internal use only). The only difference of the two is that a public group will be listed when someone searches for groups whereas a private one is not. To be able to become a member of a hidden group one needs an invitation by a group moderator. For public groups one might need an approval for joining the group by a group moderator.

The GROUP_TYPE_SYSTEM is required to handle the access mechanism only on groups. Therefor a media must be bound to a user with the group and each media is at least in the system group of the user. Each user has a dedicated system group for this purpose.

The flags for the group types are: GROUP_TYPE_SYSTEM, GROUP_TYPE_PUBLIC and GROUP_TYPE_HIDDEN

Visibility of images belonging to a group

Images that belong to a group can have the following visibility:

  • member: Only members of the group can view the images.
  • registered: Images are visible for registered users (also for users that are not members of the group) but not for anonymous visitors.
  • anonymous: Images are visible for everyone.


Access rights for tagging

To prevent that tags or other meta data get deleted by accident or are being maliciously modified, one can assign the following access rights with respect to tagging:

  • readonly: Tags cannot be modified at all but are displayed.
  • only add: Tags can be added but not removed or modified.
  • full: Tags can freely be added, removed and modified.


Access levels for viewing the media

One might be interested to provide download of the original image to some people so that they can print them out or save them in high quality. But this is not always the case. Therefore there should be two different kinds of access levels for media:

  • view: Images and videos can only be viewed in the browser.
  • full: Images and videos can also be downloaded.

Flags for the access levels for the media: GROUP_MEDIAVIEW_VIEW and GROUP_MEDIAVIEW_FULL.

User Roles for groups

To be able to make groups self-governing we need the following user roles for groups:

  • owner: can assign moderators and perform everything else a moderator can,
  • moderator: can add/invite/delete users,
  • member: is allowed to view and assign images to the group.


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


One should take care that the user-interface simplifies the creation of groups. It would be rather confusing for non-geek users to expose all flags to them. By providing a small set of examples with a fixed access sheme, e.g.:


and additional checkboxes, whether users should be allowed to tag and/or download the original media should suffice. More advanced combinations should be hidden by an "Advanced Settings" tab or similar.


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