[thor] Fwd: RE: Horde Customisation and additions

[Carlos Pedrinaci]

Jan Schneider wrote:

>Hi, this is from a potential client, any comments?
>
>=======================================================================
>However, I've been playing with the Projects module (thor) and I'd like
>to use it show the status of the current projects. However, it appears
>to be in the very early stages of development. What I'd like is to
>complete the functionality such that project definitions do not require
>the specification in PHP as it is currently.
>
>Ideally what I'd like to define the project life cycle and deliverable
>and track it along those lines, the whole thing should be configurable
>from the GUI front end, much like Whups is. I'd like to be able to
>change the OSs on a per-project-type basis, enable project deletion,
>enable status notes to be added to the file.
>
>Does this align with the Thor development direction?
>
>I like to keep and extend the ability to request projects as that will
>mean requesting projects will be rigorous.
>=======================================================================
>
>Jan.
>
>  
>
Currently Project types are created ad-hoc in PHP as it simplifies much
of the testing.

My idea is to implement in PHP some skeletal project types with the
basic functionality. This core functionality should already be (almost)
there...

The idea is to couple projects with a library of Items which can
actually be implemented independently and increase the overall power of
Thor. In some cases Items would wrap other Horde modules functionality
such as Tasks, Whups queues etc. and in some other they will just be new
functionality such as the Deliverable or the Project Plan (to be done
yet) items.

Then I plan to allow users to define their own types via GUI.
A project definition would be composed of the required and possible
Items perhaps backed by an XML definition file.

With respect to Projects Request I can see a similar way of dealing with
them, such that one can define what should be included as part of a
Project Request via GUI.

Defining the project life cycle would as well be a very nice feature but
I'd say that this would be a second step.

In other words, all the features you point out there are completly
aligned with Thor's direction.
I just put them in a slightly different order because I think we should
try to go for an incremental functionality addition, maintaining a
working kernel, ready to use.

-- Carlos

PS: Personally I intend to retake Thor and implement the Project Plan
and related Items when I'll get done the stuff I'm currently involved in
(hopefully around October).