[whups] new to whups

[Gary Weinreb]

At 04:15 PM 10/25/2002 -0400, Chuck Hagenbuch wrote:
>Quoting Gary Weinreb <gweinreb@rocksolidsystems.com>:
>
> > I've been messing around with it, modifying it as a Projects management
> > app,, rather than a Bug tracking app.
>
>I'd be curious about what kinds of things that you were changing.

Mainly the interface references to the data.  Such as referring to 
"Module(s)" as "Client(s)", "State(s)" as "Stage(s)", "Priority(ies)" as 
"Status", "Version(s)" as "Project(s)", "Ticket(s)" as "Job(s)", etc.  I 
have been experimenting with various combinations, and getting feedback 
from clients...


> > Some parts, such as the Query Builder, don't make any sense to me, are
> > incomplete, or I've yet to discover their workings.
>
>The Query Builder is for putting together complex searches that you can
>save, edit, and re-run later. I seem to be talented at breaking it, but as
>of my last commits, it was actually working quite well.

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


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