PHProjekt 6 - Developers Blog - Frontend

SubModule API for the frontend

nospam@example.com (Gustavo Solt) — Fri, 20 Nov 2009 14:18:51 +0100

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)
Continue reading "SubModule API for the frontend"

Privileges on a item

nospam@example.com (Gustavo Solt) — Wed, 09 Jul 2008 21:31:47 +0200

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

Roles system

nospam@example.com (Gustavo Solt) — Wed, 09 Jul 2008 21:12:15 +0200

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

Projects, modules and roles

nospam@example.com (Gustavo Solt) — Wed, 09 Jul 2008 20:50:03 +0200

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.

History on PHProjekt 6

nospam@example.com (Eduardo Polidor) — Fri, 23 May 2008 14:57:21 +0200

On PHProjekt 6 each item -project, todo, timecard entry, etc- will have their own history log. All changes on all fields will be logged since item creation.

On detail panel, when a item is selected, there will be available a history tab where the user will be able to show the changes of the last 30 days -configurable-. The information that will be show on that tab will be the date time of the change, the old value, the field modified and the user who modified the field.

To optimize the original request to server, the content of history tab will be filled only when te user clicks on history tab.

On the tab the user will be able to request all list of history of the item if it needs the complete history.

On configuration file the administrator can enable or disable the history, and setup the number of days to be shown on history tab.

Further the history could be filtered by username and fieldname. Also, on further versions a 'single field' history will be implemented.

Live Search

nospam@example.com (Gustavo Solt) — Tue, 20 May 2008 06:59:04 +0200

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.
Continue reading "Live Search"

Tags on PHProjekt 6

nospam@example.com (Gustavo Solt) — Tue, 29 Apr 2008 20:30:10 +0200

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.

What's new, part 2: New Features for developers

nospam@example.com (David Soria Parra) — Fri, 04 Apr 2008 14:56:55 +0200

While part one of What's new was dedicated to users, part two will give you a short overview what developer can expect from PHProjekt 6.

As a result of the long-lived, procedural and hard to mantainable code from earlier PHProjekt versions, we especially had developers in mind when creating the initial architecture of PHProjekt 6 last year. Thus, PHProjekt is based on well-known technologies including Zend Framework and Dojo. PHProjekt 6.0 is implemented using an model, view, controller architecture, with PHP in the backend and a rich-client frontend based on dojo, giving you a much easier to use interface. And for sure it's PHP5.

Continue reading "What's new, part 2: New Features for developers"

What's new, part 1: New Features for users

nospam@example.com (Albrecht Günther) — Wed, 26 Mar 2008 13:49:01 +0100

Of course one of the most interesting questions for the users is: what can be expected from PHProjekt 6?
Beside the technical aspects which will be treated later, here are some hints which will be different from the current edition:

PHProjekt will focus more on project management
Due to the dojo-client, the usage of the frontend will be fun
Key features like the filter system or the contextmenu handling will be kept in the new version
Addons and modules will be treated in the same way - and the management of new modules will be done very easily
New web2.0 features like tagging, live Search and Ajax will be introduced
In the first version we will skip comunity modules like the votes, chat or forum
The group system will be expanded - each project can manage several members with different roles

Continue reading "What's new, part 1: New Features for users"