[whups] new to whups

[Chuck Hagenbuch]

Sorry, the previous message was sent unfinished.

Quoting Gary Weinreb <gweinreb@rocksolidsystems.com>:

> I couldn't seem to figure out how to actually create and save a
> Query.  That second drop-down list threw me.  Current Quey, Choose
> Action:  Hoist?  Then the only criteria constructor is User Criteria, the
> others do nothing.  Maybe somethings broken or maybe it's me.  A brief
> step-by-step would help...

This should be in better shape in current CVS. The change ticket type form
works correctly now, and propery criteria, user criteria, and text criteria
should all work. The Choose Action menu still needs some work, but "Hoist"
just means to pull things up one level of indentation - to the next
outermost branch of the query, as it were. If you play around, I think
you'll start to get the hang of it.

> Right.  The "Summary" is also called the "Subject" in the Search Tickets,
> Results display.  I use this field for the "name" of the specific instance
> of the Project, using a unique ProjectID made up of a ClientID+a date+a
> descriptor, such as ABC_102502_XYZ which fits into my client's existing
> paperbased workflow, AND THEN there are "Subjects" which are associated
> or not with each Module.  This is confusing that they are both referred to
> as "Subject".  I've really not found a use for these.

A client wanted to be able to restrict subjects to a pre-defined list - for
example, a list of service calls which are covered under contract.
Suggestions on how to make this a bit less confusing would be great.

> Right now I'm looking on pulling Whups Modules (and thus hermes
> Client:Jobs) from turba_objects.  I'm looking at flagging turba_objects
> as Clients either through object_type (currently default "Object") or a 
> new field. Maybe using object_alias to store a unique 3 or 4 letter string 
> as a ClientID.  Maybe concatenating that string with my Projects (Jobs) so
> that Timeslice entries can map directly to Client:Job, as the term 
> indicates.
> 
> ADVICE PLEASE!!!  <g>

Sounds interesting. I would avoid using object_type, since, though it sounds
like a good match, is used internally to Turba and probably shouldn't be
mucked with by other apps. But another field, or another criteria for use -
maybe specifing a specific address book as the one to use? - sounds like a
good idea to me.

> I would like to pull Hermes Job Types from the Whups Types.  It looks
> like I could fairly easily create a new set of project API methods which
> expose the Types (as well as other data elements) in addition to the 
> already exposed Module methods...
> 
> Would that be the correct way to implement this?

I think so. If you send a patch for implementing it, I'll take a look at it
and try to get it committed.

> There's a whole Services Workflow scheduling aspect that I really haven't
> sat down and gotten my brain around, but have thought about.  Let me try
> by example:

This makes my brain spin a little bit, but I think I see where you're going.
I'm hoping that you'll keep forging ahead with implementation and I can
catch on eventually. :)

> If it is generic enough, these can happen the same way.  Let's say that
> when we create a type, and define the States for that type, we are
> creating a template for what WILL happen.  We create a set of special 
> nag_tasks which can be referenced later (by Module, Type, State, maybe 
> hashed as owner?)  These nag_tasks define tasks and descriptions with time
> expectations. (We are defining operational Procedures with performance
> parameters).

This actually seems fairly straightforward. I like that idea a lot.

> We also create nag_tasks which contain a hash which stores arrays of
> actions and action subjects, defining what happens under specific
> conditions (We are defining Business Rules).  These Business Rules are
> defined through the interface at each Type definition time, through
> creating arrays of Actions, such as NotifyInternal, NotifyExternal,
> CreateTask, etc, upon a selection of appropriate Action Subjects, be they
> Users, Contacts, or available Procedure tasks.

This is less clear to me. Hashes inside tasks?

> When we create a Ticket (Project), we create an instance of a set of
> potentially expected, latent, nag_tasks, some of which are Rule Tasks,
> assigned to the ticket itself, for programmatic reference upon specific
> States.  Some of the latent nag_tasks are inactive Procedure tasks, which
> just tell someone what to do.  The Rule tasks define which Procedural
> tasks should activate, when, who the owner(s) is/are, and with what 
> Priority and time parameters.

I think I follow...

> When a State is changed, a State object is instantiated.  The State
> object can ascertain whether it has already existed for that Ticket, if so 
> for how long, whether that duration is as expected, or not, and so on.  It 
> can check whether the previous state is as expected, and whether the tasks
> generated by the previous State are completed.
> 
> By mining the hash for the appropriate Action:Action Subject sets, the
> Ticket:State can determine who to contact in which manner, which latent
> tasks to activate with what settings, which latent tasks to delete,
> etc...  It can change it's Ticket's Priority (Status?), and if we use
> colors to represent Priorities, we can generate effective visual cues to
> go with the notifications.

... Okay, you're a bit beyond where I'm conceiving of things now. But it
sounds promising. :)

> Well, great!  Guide me, help me determine what makes sense to do and how
> best to do it.  I'll work at it and get it back to ya'll.  I'm kind of
> new to CVS, and PHP for that matter, but I have pretty good *nix and OOP
> skills.

I think defining tasks to be assigned when a ticket hits a certain state is
a good place to start. Also, I think we need to work on the Notification
library to be able to do email/pager/jabber notifications, and to have those
triggers in the mix as well - using tasks for everything seems overboard,
when really you just want someone to get a message when something hits a
certain state, not necessary to have a task assigned to them.

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
"People ask me all the time what it will be like living without otters."
 - Google, thanks to Harpers