DotProject 3 Directions
From DotProjectWiki
Contents |
1 DP3 Directions
1.1 Modules:
1.2 Companies and Departments
Companies and Departments have been replaced with one type of item called an organisational unit. The reason for this is that the attributes of departments and companies were very similar but provided the same sort of functionality. They both provided some way of grouping people at a structural level and identifying the scope of a (related) project.
Companies and Departments would not satisfy for example the need to have people split into project teams, or the need to split a company over many countries if necessary. By treating these structural parts of an organisation as one type of item, we gain the ability to more accurately reflect the organisation itself, in terms of resources and the organisational scope of work being carried out.
The organisational unit functionality will be carried out by a module called orgunit.
The orgunit module will provide all of the normal end-user operations of a company or department object:
- add/edit/delete
In addition the same module will provide operations for determining the people and organisational units that make up that unit:
- add members(eg. add people to a company)/remove members.
1.3 Contacts and Users
Contacts and Users have been replaced with one type of item named Person. The reasoning is twofold:
- Providing all of the attributes of a contact and a user account in one record allows greater compatibility with directory services.
- Treating users and contacts as a single assignable resource allows greater flexibility in project planning for people that are for instance not allowed to use the system but are resources of the project.
The difference between a contact and a user essentially comes down to the attributes of the record:
Whether they are explicitly allowed to log in to the system, Whether a username and password are set.
The person functionality will be carried out by a module called people.
The people module will provide all of the normal end-user operations of a user admin screen or contacts module. i.e add/edit/delete.
In addition the same module will provide operations for determining the persons membership with regard to organisational units. i.e add to orgunit/remove from orgunit.
The permissions area of the user admin module has been redesigned and will be explained in the section entitled policies.
1.4 Projects
TBD.
1.5 Tasks
TBD.
1.6 Outline
Outline is a new module which will provide the ability to define a project outline which will include the project's name and its tasks. This will give people the ability to outline a project before collecting more detailed information about each of its tasks and how resources will be allocated.
1.7 Calendar
TBD.
1.8 Files
The files module will remain essentially the same in operation. The search functionality will be replaced with the Zend_Search_Lucene search engine.
1.9 Forums
Forums are under discussion: They may be entirely removed from the system due to a number of forum packages being available. Integration of forums on a per project basis will be written in that case with a popular open source forum package.
2 System
2.1 Zend
A number of replacements were made where usage of a Zend component supercedes one of our own components:
- DP_Query has been replaced with various Zend_Db objects, Making us more database agnostic.
- AppUI has been split into its components:
- User session handling is done by Zend_Session
- User authentication is done by Zend_Auth, Giving us more compatibility with other authentication systems.
- TabBox and TitleBlock components have been converted to distinct view objects.
- Status messages are now handled by the zend controller action helper 'FlashMessenger'.
- Translation is now handled by Zend_Translate
- Smarty code in head, or presentation code in the release branch is replaced with Zend_View and DP_View objects. In the case of object view/edit Zend_Form is also used.
- Module redirection code has been replaced with the Zend mvc family of classes.
2.2 DP_View
A new family of objects which inherit DP_View have been created. Most of these objects encapsulate some sort of "widget" and state information. Each DP_View notifies the system when it has changed.
An example of the way DP_View objects interact would be that a list of things often has a search facility and a page numbering facility. With DP_View the list always reflects your search or your page selection, and the page selection and search facility always reflects the list of items you have.
The end result of this system is that it can be quite easy to construct a page that manages a list of items. The time needed to construct an item listing is greatly reduced.
2.3 Policies (Permissions)
The permissions system has been redesigned to deal with permissions at the object level rather than the module level (eg. dealing with a company and not the area of functionality provided by the companies module). The new system which uses "Policies" instead of permissions is designed to be more lightweight than a classic per-object permissions system.
The new system deals with the idea of membership and the previously mentioned organisational units.
- Most system objects will have a membership list. This includes projects and tasks.
- The membership list is comprised of organisational units, which can be an entire company each or just a two man team.
- The policy system will identify you as a member (if you are listed on the membership list, or part of any organisational unit (for instance part of a company) listed in the membership list).
- The policy system will grant permissions according to your status as one of the following:
- an owner/creator (the person who created the project/task/etc)
- a member (a person who has been added to the project's membership list),
- or a non-member (not mentioned at all on the project's membership list).
- The permissions/or actions available on every object are one of the following:
- view (or read) allows the person to view the object and see it in a list.
- edit (or write) allows the person to view and edit/make updates to an object.
- add child, allows the person to be a creator of child objects. there is a natural hierarchy which follows this concept, for example: a person who can create children of a project will be able to make new tasks.
- There are sane defaults for what an owner, member and non-member can do with an object. The system will allow people to define their own policies with regards to what a member or non-member can do. They might for instance say that people not listed as a member of a project cannot view or even see that project at all.
3 Module development
In addition to the new objects provided by the Zend framework and the new system components, module developers will be able to add custom functionality to several parts of the system.
There are two distinct areas where module developers can insert their own functionality:
3.1 Events and User Interface
3.1.1 Events
The events system will allow modules to register themselves as receivers of certain events so that they may take a predefined action whenever any of these events happen. The initial categories of events will be:
- Database: insert/update/delete : modules can be notified whenever a project or task etc is updated or removed from the database.
- Accounting: login/logout/permission denied : modules can be notified whenever someone logs in or out, tries to access an object they are denied access to.
More categories of events will be developed in future.
3.1.2 Interface
DP_View hooks - Will allow module developers to add custom interface code before or after a section of the page, or modify the existing DP_View object. (add a custom tab for example).
Zend_Form hooks - Will allow module developers to add their own fields to object editing pages and receive form submissions in order to handle the data associated with their fields.
Generic parent-child list generator - Will allow module developers to generate a list of their objects wherever necessary with very little code at all.
3.1.3 Module installation
TBD
3.1.4 Module configuration
TBD
3.1.5 Resource Allocation
TBD
For Functionality currently being considered see What's New - 3.0
