[OGo-Developer] Changes to trunk, Testing

[Helge Hess]

On May 29, 2007, at 01:40, Adam Tauno Williams wrote:
>> - parent_id in project table
> Hierarchical projects?

Yes. Not sure whether it would be better to just use obj_link for  
that. parent_id would be a bit more convenient/faster in case we want  
to check parent permissions.

>> - a few other minor things
> What about "Enh: Add ability to create hierarchies of depenedent  
> tasks"
> http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1089
> Jobs already have a parent_id, but that value seems to be treated  
> oddly
> resulting from some relic code.
> (a) The current field could be recycled somehow and the relic code
> removed

If we want to have hierarchical tasks, reusing old stuff is most  
likely the way to go.

> (b) It could be solved with object links

For dependend tasks we would probably just use object_links. Not sure  
whether tasks dependencies need additional information (associated  
accounts?) which is not provided by obj_link's type and/or label.

>> If someone has wishes for additional fields, shout now ;-) This isn't
>> committed yet.
>
> I've been thinking about -
> Enh: notification mails on uploads and document releases
> http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=229
>
> I was imagining just storing a CSV list of users in a property,   
> perhaps
> adding an add-me/remove-me button to the UI.  But if you are in a  
> schema
> changing mood then perhaps you can envision something more elegant.
> Seems like it could be generalized to support change notification on
> just about anything;  just store obj_id, company_id [account id].
> Changes invoke a notification e-mail to email1 of company_id.

Hm, a global change notification thing is a pretty smart idea. It  
would allow for per-user/per-object/per-action notifications. Need to  
think about that.
Might also be a more elegant solution for Sebastians request.

I wonder whether we could again use obj_link for that (type  
notification with the notification object pointing to the user).  
Though maybe this really deserves an own table.

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/