Re: whups mods...

From: "Gary Weinreb" <[email protected]>

> > <Snip interesting use case>

Ahh.. that actually makes sense - it seems that you do just have a lot of
similar types.  I presume that this:

From: "Mike Baptiste" <[email protected]>

> If I follow you correctly here - why not use the Type version feature
> instead?  So you creaet modules for the various project types (radio, CD,
> etc) and then create versions in each type for 2 min, 4min, etc.

While very interesting, isn't applicable because versions are associated with
modules, and you're using the module field to track clients, not the type of
audio production (is that right?)

When you copy the type to the new one, do you alter it in any way at all (other
than the name)?  If not, it just seems to me that there should be an easier way
of representing this - I just haven't thought of it yet...


But this:

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

isn't solved by adding the admin links from the create ticket page.  Perhaps you'd
be better off customising the admin page (or making a new page) that effectivly
shows the 'Create Ticket' forms immediately after completing the 'Create Type' forms.
You could of course make the create ticket a shorter form process than normal because
you already know what type the ticket is being created in.

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

Yes - I looked and it was fine in the first diff you sent.  Use 'cvs diff -u' and
send the output directly to the list (you don't need to edit it that way).  cvs
is one of the most useful tools I've come across - in most cases it just does what
you want.

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

Of course - I'm sure we've all been there before.

> 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

Yes - workflow is the current direction for whups.  Did you see my previous mail
about implementing state transitions for workflow?  I'd be interested to hear how
it fits with the way you're currently using whups.

Regards,
Rob

--
10: Sin
20: Goto Hell
  - From the Futurama Robot Church


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