[whups] new to whups

[Chuck Hagenbuch]

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 Choose Action menu is
still iffy; Hoist brings things up a level (in one level of indentation),
etc. But the Change Current Ticket Type form now works correctly, and
Property Criterion, User Criterion, 

> > > Same with the Reports section.
> >
> >Try it as of yesterday...
> 
> Will do, over the weekend.  I'm about a week out...
> 
> > > 2.3)  Subjects - I don't use these, but you can set up key words
> which
> > > can apparently be queried against...
> >
> >It's the summary. I hated not having a one-line tag for what each
> >bug/ticket/entry was.
> 
> 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.
> 
> > > Whups integrates with Hermes (time-tracking) in the following
> > > manner:  Hermes seems to use the whups_modules table as it's data
> source
> > > for what is called Client:Job.  The other data element in Hermes that
> > > could integrate with Whups is called Job Type, which seems like it
> should
> > > be mapped to whups_types, but currently isn't.
> >
> >There was a reason I didn't do this, and I don't remember what it was.
> >Brain? What brain?
> 
> 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>
> 
> 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?
> 
> 
> >That makes sense; I'm not sure if modifying the en_US translation would
> be
> >enough for you, but it's described here:
> >http://www.horde.org/faq/admin/config/index.php#c6
> 
> That's what I eventually did.   That showed me that the way I was wanting
> to look at the data made sense within the framework that whups
> provides.  This doesn't really provide anything for me share with you
> guys.  And it doesn't do anything for integration with the other modules,
> which can really make the framework powerful.
> 
> Right now I've just got a whups preference for Mode?  Bugs or Projects. 
> 0
> or 1.  Then I'm working at toggling the human readable strings according
> to
> the preference setting.  That gives me 2 sets of 5 or 6 different
> strings,
> but doesn't really get into abstracting the framework out to be
> applicable
> to generalized Procedure Management.  i.e. I see this thing as being
> useful
> to manage Organizational Events, actual and expected, and sets thereof,
> not
> only from an operational, "delegate and manage", perspective, but also
> from
> a "define Standard Operational Procedures and publish them web & print"
> perspective.  What we expect or plan to have happen (Workflow) as well as
> managing what does happen (Bugs).  I guess I could just set up case
> structures and we could predefine a few sets of default English
> descriptors
> (msgids) for different organizational paradigms.  That would work for
> now.  Maybe we could later map each Module to a particular set of
> descriptors, so that an organization could use the same framework for
> different things...  What a concept <g>...
> 
> 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:
> 
> Let's say we're a Medical Clinic.  We have patients come in twice a week
> for 12 weeks for some sort of therapy with a specific therapist and her
> assistant.  Every other week the patient meets with the therapist on the
> 1st session, and then works with any one of three assistants on the other
> sessions.  Every third week on the 2nd session we run some tests which
> are
> submitted to an outside clinician for evaluation.  The clinician modifies
> the therapy, alters the frequency of therapy, changes a prescription,
> notifies the patient, and advises the therapist, who instructs the
> assistants.  There is a recurring feedback loop which involves multiple
> parties who may or may not ever talk face to face.  Additionally, the
> patient needs to be reminded the day before he/she has an appointment,
> and
> requires a phone call, so a receptionist or telephony application must be
> notified.
> 
> > > I'd also like to have the ability to fine-tune what happens at
> various
> > > events, i.e. When a Project of Type ABC, goes from State 01 to State
> 02,
> > > Notification is sent to Internal Users Joe, Sue, and Mary, and
> External
> > > User Client_Tom; but when it goes from State 02 to State 03, only the
> > > Internal Users Joe and Sue are notified.
> >
> >That sounds great; a workflow like that would take some work to develop,
> but
> >could be widely applicable if it was generic enough.
> >
> > > Likewise, when a Project changes State, I'd like to automatically
> > > generate a certain set of Tasks (Nag integration), and request a
> specific
> > > User assign them manually, or assign them based upon some algorithm.
> >
> >Oooh. :)
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 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.
> 
> >I'd encourage you to keep discussing what you'd like done, and hopefully
> get
> >to the point of patches; we can get you CVS access to whups if you start
> >doing heavy work on it. The workflow stuff sounds especially exciting to
> me,
> >as you may have figured out.
> 
> 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.
> 
> This could be incredibly useful stuff.  Often, organizations
> aren't.  Unless they have established some means of being that
> way.  Defining corporate culture in terms of what to do when, maintaining
> agreement about what is being done when, and then managing to get it all
> done is half the work of being an organization.
> 
> It's late.  I may no longer be making sense. Thanks much for the
> interest.  What the hell do you mean "living without otters"?
> 
> Regards,
> Gary
> 
> 
> 
> --
> Whups mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: whups-unsubscribe@lists.horde.org
> 
> 


-chuck

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