Technical

There is a new API for make sub-modules,
A sub module is a front implementation for save various items related to one record.

The current example is the Minutes module, where for one meeting,
you can save various topics, todo, dates, etc.

The idea is that the user clicks on the record (in the grid),
the form appears with all the data,
and there is one tab for the sub-module that contains:
- In the left, a grid with all sub-items related to the record.
- And in the right a form for add / edit and delete the items.
So the user can add many items to this record.

For make it easy, there is a SubModule folder in each module, that can contain many other folders,
(each folder is a new sub-module).
In that folder, called for example "NewSubModule", there is the basic module structure, that means:
Controllers, Models, Languages, Sql and Views.
So the implementation of the submodule is like all the others modules, but inside into the SubModule folder.

For the view, the form must be an extention of phpr.Default.SubModule.Form, the grid of phpr.Default.SubModule.Grid,
and the main of phpr.Default.SubModule.

The function for the grid and the form are the same as other modules,
so the customization is like always.
(For internal use or avoid some features, there are some functions already overwritten)

Since there is 3 system of access, how is the relation?

1- There is a Module access, that say with modules have each project.

Example:
Project 1 have (Projects, To do´s, Notes)
Project 2 have (To do´s)
Project 3 have (Notes)

2. There is a Role system, that say what can do the user in each module.

Example:
Role Admin can:
On Projects, Read, Write, Create and Admin
On To do´s, Read, Write, Create and Admin
On Notes, Read, Write, Create and Admin

Role read only can:
On Projects, Read.
On To do´s, Read.
On Notes, Read.

Role Secretary
On Projects, Read and Wirte.
On To do´s, Read and Wirte.
On Notes, Read and Wirte.

There is a relation role-user for EACH project.
So the same user can have Admin Role for the project 1 and Secretary Role for the project 2

3- The Rights on the item, that say what can do the user on it.

Example:
Project 1 - User 1 - Owner -> Can do all.
Project 1 - User 2 - Can Read, Write, Delete.
Project 1 - User 3 - Can Read.

To do 1 - User 1 - Owner -> Can do all.
To do 1 - User 2 - Can Read, Write, Delete, Admin,
To do 1 - User 3 - None.


- Relation 1. and 2.

When the user see one project node, the allowed modules are showed like tabs.
These modules are the combination of the Modules that have this project ( 1.) and the Role of the current user for this project (2.).
The role of the user in the project that are seeing, must have:
- read access for see the tab of the module
- create or admin access for see the "add" button in the module.

- Relation 2. and 3.
Each item have an array of access for each user.
This access must be combined with the role access assigned for this user on the current project node (or the parent node if there is no role on the current)
The relation is based on the next table:

R o l e s R i g h t s
..................................................................
.................|.read.|.write.|.create.|.admin..
..................................................................
.read.........|...X....|....X....|............|....X....... I
............................................................... t
.write........|.........|....X....|.....X.....|....X....... e
............................................................. m
.access....|...X....|....X....|.....X.....|....X........ s
...............................................................
.create......|.........|....X....|.....X.....|....X...... R
.............................................................. i
.copy.......|.........|....X....|.....X.....|....X........ g
.............................................................. h
.delete......|.........|....X....|............|....X........ t
............................................................... s
.download..|...X....|....X....|............|....X......
..................................................................
.admin.......|.........|..........|............|....X......
..................................................................

All the X are allowed combinations, examples:

If the user have in the item, "delete" access, but on the role have only "read" access, the delete access will be false.
If the user have in the item, "delete" access, and in the role have "write" or "admin" access, the delete access will be true.

The result is an array with true or false in none, read, write, access, create, copy, delete,download and admin.

The Privileges is apply on each item within one module of a project.

The project owner has a tab in the item form where all users (except the current user) are listed in rows and some checkbox with the access as columns
(in fact a matrix). Note that this tab is only accessible if the user is the owner of the item or have admin access on it.

The different stages of privileges can be:
None: The user can´t see the item.
Read: Allow to see the item.
Write: Allow to update the item.
Access: Allow to Pass through the item. (See the sub projects for example, but don´t see the project itself).
Create: Allow to create sub items.
Copy: Allow to copy the items and create other one.
Delete: Allow to delete the item.
Download: Allow to download files (for example in the File manager module)
Admin: Allow to do all, AND edit the access of the item.

The owner of the item, have always all the access checked.

Each user MUST have some type of access to the item, if not, will don´t see it.

Note that the Rights of the item must be combined with:
- Module access
- Role System

The Role system applies directly to the modules within a project.

In order to create a new role, the administrator will have a list of all the active modules, and 4 columns with checkbox: READ, WRITE, CREATE, ADMIN.

The types have different stages of privileges:
Read Access: The User with this role can read all the items in the module.
Write Access: The User with this role can update all the items in the module.
Create Access: The User with this role can create new items in the module.
Admin Access: The User with this role can read/write/create items in the module AND change the access of the item.

How does this look in practice? Here is an example:
The administrator can define some roles like:

Admin Role
To do -> Read, Write, Create, Admin
Note -> Read, Write, Create, Admin
Project -> Read, Write, Create, Admin

Read Only Role
To do -> Read
Note -> Read
Project -> Read

Maintain Role
To do -> Read, Write
Note -> Read, Write
Project -> Read, Write

The role applies for each user in each project.
So in the Project Form, there is a Tab with all the users (except the current user) and a list of all the roles available.
The current user can´t change their role on one project, and if is the owner of it, will have complete access.

If one user don´t have any role on a project, the role of the parent project for this user is used.
The first role-project relation is for the root project, this relation can´t be deleted and is used by default. (Root Project <-> Admin Role <-> User ).
If a new user is created, then a new default relation must be inserted.

Note that the Role system must be combined to other access system like:
- Rights on each item.
- Module access

PHProjekt has a hierarchical project tree.
Each project is a "node", with different modules, roles and access for each user (in other words, each project can have it's own set of modules and respective roles). For project owners there is an additional tab in the form of each project where you can assign the modules will be available within your project.
In this tab, there is a simple list of all the current active modules, and a checkbox for allow it in the project or not.

So, in a tree of project like the:

ROOT
|__ Project 1
|....|__ Project 3
|....|__ Project 4
|........|____Project 5
|__ Project 2

the owner of the project or a user with write access on it, can allow or disallow some modules.

For example:
Is possible to:
- Have in the Project 1, only Sub Projects and To do´s,
- Have in the Project 3, To do´s, Calendar and Notes, (Without Sub Projects).
- Have in the Project 4, To do´s only
- Have in the Project 5, Notes only
- Have in the Project 2, all, Sub Projects, To do´s, Calendar and Notes.

Note that the project can have some modules allowed, BUT the access of it depend on the Role system.
So, if one user have a role that don´t allow to see To do´s in the Project 3, THIS user will don´t see any To do´s in it,
but the other users with other roles, will can.

For read about the Roles, click here.

The live search is other web 2.0 feature that the PHProjekt 6 will have.
This search works on any key press,
and shows any item (Projects, To do´s, Notes, Events, Files, etc) that contain the string or a part of them.

There is a new web2.0 feature on PHProjekt6, The Tagging system.

Each user can tag their items like to do´s, projects, notes, etc.

When you see one item, a list of all of your tags are displayed.
You can click on one tag for see other items tagging with these tag.
So is easy to categorize many items, from different modules, together.

As the normal tagging system, the list of tags are differenced displaying the most popular tag, bigger than the others.

When you edit the item, you will have a text field for add the tags separated by spaces.