[whups] new to whups
Sat Oct 26 04:07:39 2002
At 04:15 PM 10/25/2002 -0400, Chuck Hagenbuch wrote:
>Quoting Gary Weinreb <email@example.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
> > 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
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:
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
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
> > 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.
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
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
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"?