Re: whups mods...

Quoting "Robert E. Coyle" <[email protected]>:

> I don't know what you're trying to achieve with this - why do you need to
> make so many duplicates of types that you need to have a special mechanism
> to do it?  Why can't you define a type that fits your tracking model and use
> it for all your tickets?

I'm not "tracking bugs", I'm "managing projects", or rather my client is, and,
for the way that we are using the types, and the way that I project (no pun
intended) using the whups framework for workflow management, it made sense...
Perhaps, I'm failing to see or understand something that is already there, or
maybe I'm just plain missing the point.  It's happened before.

Let me try and explain my perspective, and maybe you will either understand, and
my efforts will make sense to you, or maybe you can help me clarify my thinking:

My client is an audio post-production house, but from my perspective they could
be any creative, project oriented organization.  They work on a large variety of
multi-party collaborative projects, including music and voice tapes, CD's, radio
spots (advertising), radio shows (talk and/or music, of different lengths of
time).  Let's take the radio shows:  They are all going to have the same basic
Priorities and States, but we want a different Type for each of them:  2 minute,
4 minute, 8 minute, 15 minute, 30 minute, with/without music, with/without
talent, etc.  They take different lengths of time to produce, and the client is
charged different amounts for each Type.

Ideally we will have set them up, through Admin, before they need to be used,
but invariably, someone will call up to schedule a project which will be a
different Type than those that have already been set up.  Also, my client
doesn't want to re-enter all of those States and Priorities for each Type,
whether setup ahead of time, or not.  

We want to copy them from a "template" type.  The Priorities will standardize,
apparently across all  Project Types in the system, but the States will
standardize across "types" of Types, such as Radio Shows, Lecture Series, Tape
Ministries, Audio Engineering, Music Production, etc.  The States that a Project
will move through will vary greatly depending upon what "type" of project it is.
 A Radio Show is produced very differently than a Tape Ministry and flows
through very different States, but whether a Radio Show ends up being duplicated
on CD or Tape, is 2, or 4, or 5, or 30, 60, or 90 minutes, it will still go
through a similar production path, or workflow...

Does that make sense?  Maybe this statement will sum it up, as an end goal:
Each Type is a billable service, at a specific price.  Also, toggling States
will trigger the creation of Tasks, which will cause another billable item, an
additional (optional) billable service.

In this current application, for this small and rather narrowly focused client,
I imagine having 40 or 50 Types, and maybe 4 or 5 "template" types, some with 10
or 15 States.  That's a lot of duplicate entry that I hope to have my client
avoid through this mechanism...

An organization which engages in more complex projects, such as an advertising
agency, which is involved in co-ordinating an even greater variety of services,
could have even more Types of projects...
 
>
> Also, it looks like you're trying to link to the edit states page while
> creating
> a ticket (although you're using $statelink and $prioritylink in Create.php
> but
> never setting these values).  Why on earth do you want to do this??  You
> should
> be creating the states before creating tickets.  I can't imagine why you
> would
> want to change the state flow process when you have tickets moving through
> it.

Yeah, in a perfect world, that would be the case.  But...  my client foresee's
the necessity for him to create a Ticket (Project) on the fly, quickly, while on
the phone with his client...  I can see your point, and I see that my solution
really doesn't solve my client's request, becuase it does not yet allow for Type
creation on the fly, just Versions, States and Priorities, AND, it opens up
problems down the road for already active Types...

Also, maybe I screwed this diff up.  I must have set $statelink and
$prioritylink in order to use them...

> See http://www.cvshome.org/docs/manual/

Will do...

Listen, I know that hand-holding a "newbie" like myself is a hassle.  I've been
where you guys are, in different contexts.  When it's more difficult to use what
I give you because it's not in a tidy, well-wrapped package, the whole thing is
just, well, less attractive than you want it to be...

Please be patient.  I'll get it...

And, also, not everything that makes sense for my perspective on "workflow",
which is the "context" I'm interested in, will make sense for "bugs".  So, maybe
as we dialog about "workflow", we can agree about direction and features, and
how to implement different contexts, "bugs", "workflow", "treatment plans", etc.
 No doubt you have longer term perspective on whups than I...

Regards,
Gary
Gary Weinreb
RockSolid Systems, LLC


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

-- 
Whups mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]