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 9 (modified by sebastian, 8 years ago) (diff)

Add new group flag example

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

  • Create svn branch branches/phtagr-multiple-group-access-model for this non-minor change
  • Access rights granularity
    • Proposed ACCESS flags: GROUP_ACCESS_META_ADD, GROUP_ACCESS_META_DEL, and GROUP_ACCESS_DOWNLOAD_RAW.
      • GROUP_ACCESS_META_ADD: MetaData could be added, but not deleted or overwritten.
      • GROUP_ACCESS_META_DEL: MetaData could be added, modified, and deleted
      • GROUP_ACCESS_DOWNLOAD_RAW: Media could be seen in all preview sizes and could be downloaded in its raw formats with embedded the MetaData
  • 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_VISIBLE, GROUP_FLAG_OPEN, and GROUP_FLAG_SHARED.
      • 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 users. These groups are shown in the media details. E.g. a non visible group of john is not shown in the media details if jack views this media. A visible group could be searched by other users but not a non-visible group.
      • GROUP_FLAG_OPEN: indicates a group which could be joined freely without an acknowledgment of the group owner/moderator. User 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/moderator keeps the control of the group members and can add or delete members. If jack is member of john's shared group food, jack can use the group food for his own media (jack must be a member of the group food first to be able to use it).
    • Example Flags and description
SystemVisibleOpenSharedComment
x A hidden system group like the private user group
x xA system group like the group 'public' (each member should be automatically member of the group public)
xx xA special system group which is not an hidden system group and created by a sysop after phtagr's installation. E.g. the group 'special-screenshots'
A private group of a user like a 'my-secret-pics'
x A group of an user, which needs authorization of the group owner/moderator to join. E.g. 'johns-vacation' group. Only john can use this group for his pictures
xx A group of an user which could be joined freely like the group 'johns-food'. Only john can use this group for his pictures
xxxA shared group of an user which could be joined freely and used by other group members, too. Like 'car-fan-group'
x xA shared group of an user, which needs authorization of the group owner/moderator to join. Group members can use this group for their pictures, too. E.g. 'johns-sunset-contest' group

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

  • Behavior
    • Create GroupAccess behavior(models/behaviors/group_access.php) which handles all the new access stuff and all its "magic". See http://book.cakephp.org/view/88/Behaviors (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 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"