[whups] new to whups

[Gary Weinreb]

At 10:32 PM 11/1/2002 -0500, Chuck Hagenbuch wrote:
>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.

Beautiful.  This is coming together nicely.
Reports also.  Are you thinking about some preferences for these?  i.e. Bar 
vs. Pie, color pickers, etc.

I am pulling from CVS HEAD about once a week, so will get current again 
probably later today.  I feel less stupid about not getting something to 
work when it actually didn't <g>...


> > 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.

That makes sense.  I've got a vague idea about using these Subjects 
(re-labeled to "Specifications" or something like that) to enable my client 
to specify, well <g>, specifications, for a given Type, rather than 
Module.  Doesn't seem too difficult...


> > 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.

Chuck, if you saw my post last week about Whups - Turba Integration, this 
idea evolved (devolved?) into Whups pulling from a specific Turba-List that 
might be statically named "project_clients", so that Turba backend 
transparency would be maintained as far as Whups is concerned, etc.  A 
generic Whups <-> Turba-List mechanism could be developed, so that it would 
be easy to set up Lists in Turba, for use in Whups as Clients, and for 
Notification, such as External, Internal, Internal Admin, etc. either for 
Contexts of Whups, or per Module/Client, or per Project?  I don't yet 
clearly see at what levels of granularity we can (or want to) break 
Notification down to.  I'd like to continue to see dialog, for example with 
Mike Baptiste (current post...) regarding the permissions / notification 
mechanism...

(bunch of stuff I just wrote and now deleted after seeing your reply to 
Mike...)

I see that you are working on this stuff currently, so I'll just try and 
contain my enthusiasm to constructive feedback...


> > 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.

OK.  I'll stumble in that direction....


> > 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. :)

Will do...

> > 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?

Maybe hash is the wrong term.  What I mean is that we create a method 
within Whups to create/encode and later read/decode nag_task records, such 
as:  (very psuedo code here...)
         nag_tasks.task_owner = "WHUPS_RULE:$whups_module:$whups_type:$state"
         nag_tasks.task_desc being encoded with arrays of 
action:action_subjects:
           a:3{NOTIFY_INTERNAL[bob,mary,tom,gilligan]:CREATE_TASKS[__bob__[$some_task_ID,$some_task_ID],__skipper__[$some_task_ID]],NOTIFY_EXTERNAL[turba.project_ABC123_external]}
using the methods for encoding/decoding arrays in to/out of, text fields, 
which are already in use throughout Horde (and which I'm assuming are 
available via API)...

They are, aren't they?


> > 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...

The RULE tasks would encapsulate "data" for processing by specified 
methods, LATER... at the designated EVENT, such as a State change...


> > 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.

I agree.  Maybe the task table is not the "right" place to store what I am 
conceiving as "business rules", but it seems to me that it could work quite 
effectively, since, well, since many of the "things" that we would want to 
have happen upon a subsequent event would be "tasks", for someone, (a 
user), or some method of whups.  It seems that whether a desired event is 
later acted upon by a user through the interface, or later acted upon by 
the program itself is of no consequence to the program in terms of 
creating, storing, and recalling said events, and nag_tasks has a data 
structure which can easily work for this...

Of course, it does create a requirement of one module upon another, which 
is probably undesirable, though not unprecedented.  Your call.  I'm willing 
to create a new whups table, and work forward with that...

Please advise.

It seems that you are moving rapidly ahead on 
Permissions/Notification.  I'll keep working on Turba/Nag/Hermes 
integration with Whups, as well as some Whups interface stuff that I'm 
almost ready to submit to you.  I'd like some feedback on the 
Turba-List  idea, if you don't mind, and I'd like to ask you to consider a 
generic method for triggering events when States change.  Whether it's 
Notification or it's Task Creation, or something else we haven't 
considered, it seems to me that it should get handled in an abstract 
manner, then become more concrete...

Thanks,
Gary


>-chuck
>
>--
>Charles Hagenbuch, <chuck@horde.org>
>"People ask me all the time what it will be like living without otters."
>  - Google, thanks to Harpers
>
>--
>Whups mailing list
>Frequently Asked Questions: http://horde.org/faq/
>To unsubscribe, mail: whups-unsubscribe@lists.horde.org