[OGo-Discuss] BLOGing/Journaling/ACTing [Was: OGo and asterisk, SUMMARY]

[Adam Tauno Williams]

On Sat, 2006-11-25 at 02:19 +0100, Helge Hess wrote:
> On Nov 24, 2006, at 13:16, Adam Tauno Williams wrote:
> > I am more and more thinking, not because of just this but other  
> > things as well, that a general purpose journal application is what  
> > would be most generally useful.  Making entries with just owner,  
> > date stamp, and comment and allow entries to have object links to  
> > other entries.  This would allow 'comments' on just about  
> > everything in one fell swoop;  it would also be easy to read/view/ 
> > display via RSS or one of the <cough>standard</cough> BLOG APIs.
> I'm not entirely sure about how the use case for that looks like.  
> Could you outline a scenario? (for that general purpose thingy)

I have three jounal/BLOG-esque applications:

1.) For CRM we record a contact journal for a contact and/or enterprise.
Currently we store this in a separate database,  which works but is
messy and make writing consumers irritating (get this here, get that
there, etc...).  We store the OGo Id in the external database and the
application has to jump back and forth.

For this case it is pretty simple: {Date}, {Object Id}, {Comment},
{Commentor}, & {Type}.  Type relates closely to something like
appointment type: meeting, call, etc...  In retrospect I could store
this in the schedular since I think I can retrieve all the 'events' for
a contact or enterprise in a given date range.  For some idiotic reason
I didn't think you could create an appointment with no account
participants;  so this one is really a brain-fart on my part.  I can't
see any reason why that wouldn't work.  By only question would be how to
properly store events that only have a date and no time;  as all day
events?  Even though there may be multiple ones?  The CRMy people really
don't do time, just dates - I got real push back on that one even for
the crappy solution we have now.

2. A work journal.

This is for lawyer and engineering types.  This seems like it would be
related to a project,  but the end-user really looks at it as a journal.
So some way to query and present a view of all entries by a particular
user is needed,  which may traverse multiple "projects"  (at least how
the end-user is thinking of the concept of "project").  This is the one
that seems really arbitrary - and they REALLY want it a certain way
[ lawyers and engineers... if you haven't had the pleasure... :) ]

Presented something like 
{Title][Date]
[Notation.............
   ..........
   .......... 
]
Related Items: {Project Link}, {Task Link}, ...
...

This is why I think object-links are useful in this application;  and it
is already very simple to retrieve links for an object (make a special
"BLOG Entry" link sort of like the assigned task link).

This is the one I can't see how to store in OGo as-is.  Unless each user
has a project that is there BLOG;  seems overkill since projects provide
allot of functionality,  and it would clutter up the WebUI like crazy
unless they could be hidden somehow.

And then there is still the question how to 'properly' store the BLOG
content in the project?

3. The normal ability to BLOG/Journal on an actual project.  Has the
same question as #2 but the 'where' is pretty obvious.

> Most objects in OGo already do have a "journal" (tasks, appointments,  
> projects). I suspect whats actually needed is some kind of  
> "reporting" frontend here? Possibly just an RSS feed which cumulates  
> the "notes" of the individual object types?

I agree,  at least on Tasks.  Otherwise they only 'sort of' have a
journal;  notes could work but I think the functionality would need some
tweaking.

> Personally I'm not a big fan of unstructured data input. I'm rather  
> keen on making structured input easier than on adding facilities to  
> enable unstructured data. Eg while generic object links can be handy  
> hacks sometimes (I _never_ use them), the structured links are much  
> more valuable.

Agree.

> Anyways, I'm not sure how all that relates to Asterisk :-)

The CRM part sort of does;  but not directly.