[whups] Clients

[Jason M. Felice]

On Fri, Oct 08, 2004 at 12:00:52AM -0400, Chuck Hagenbuch wrote:
> I need a few people to speek up about what they actually use the clients
> functionality for in Whups. I started looking at how to rewrite it to use
> RelationshipManager, and ended up simply removing all references to clients
> from my local version. Looks much cleaner now. ;)
> 
> Obviously I'm not going to just commit that, though, without figuring out what
> the need is. So some questions:
> 
> - Do multiple clients really need to share the same queue? Even if they do, is
> this something that can be solved more cleanly with better queue permissions?

Definitely.  We have a Horde queue here, and we don't want to restrict
it so that only one client can pay us :)  I implemented the 'All
Clients' flag because we have a couple modules we don't want to
restrict to specific clients, but we still want to associate clients
with them.  We have a generic 'Cronosys' queue where we drop odds and
ends requests and support tickets that we don't want to have to make a
separate queues for.  In a professional helpdesk, this could easily be
the case.

I wouldn't object to removing client-to-queue assignments altoghether;
we just need client-to-ticket assignments.  Thinking this through,
client-to-queue assignments restrict the users to selecting from a
subset of clients.  I can only think of two sitatuations for this:

1) You've given a client access to a queue via permissions, and you
   don't want them to enter tickets for other clients.

   I think using it like this is pretty messy, because you can't account
   for the case where you might want to grant more than one client
   access to a queue for a product that both are using.

2) A user entering a ticket might not know which client to select for a
   ticket.

   I can't think of a realistic case where this might happen.  In any
   case, if we had more than one client per queue, we have the same
   problem, anyway.

> 
> - What if queue attributes were extended to be both searchable and customizable,
> so you could custom-define a field that was added to all tickets in queue Foo to
> be a dropdown of clients? Or, a dropdown of ... kinds of tomatoes? Etc. Would be
> a decent amount of work, but potentially a far bigger payoff in terms of
> flexibility/functionality.

This could be useful, but I'd make sure that people really could use
that sort of flexibility.  I know I have an internal request for ticket
due dates, and the requester wants to be able to sort by that so I
offered to make it a column on "My Tickets".  I also have an internal
request for hour estimates.  There is a definite request to show client
in a column and be able to search on it and sort by it, although the
fact that a ticket can have more than one client gets messy here.

Hmm, we could live with one client per ticket.  In fact, it might make things
simpler.  (We'd create two tickets, one is "Implement feature foo for
client X." and the second is "Adapt feature foo for client Y.")

In short, all of these fields are pretty generic, and although not
everyone will use them, I'd say we're not doing anything oddball enough
to really justify a configurable field capability, IMHO.  That's not to
say that noone else isn't.

> - Or does this really need to be in the core of Whups? If so, I say forget about
> relationshipmanager and add a db field for client_id.

Hmm, if we could find a way to put relationships into columns so we can
sort by them, and how to configure requiring certain kinds of
relationships per ticket and enforcing only one of certain kinds of
relationships, this would work really well.

In other words, if we can configure that each ticket must have a client
relationship, and can only have one client relationship, and we can put
the client in a column, that would work.  This will handle associations
with client deliverables and projects, too (the new guy here has impressed
upon me the need to get everyone to focus on the status of deliverables,
make this highly visible to everyone, and tickets, tasks, time, expenses,
and anything else is subservient to that).

What if we had a master list of relationship types in whups (e.g.
"Client", "Deliverable") and whether it appeared in a column, and each
relationship type could be configured per-queue to
be "Zero or more", "One or more", "Zero or one", or "Exactly one"?  That
might be unclear, so here's a little diagram:

  +----------------------------+    +---------------------------------+
  | whups_relationship_types   |    | whups_queue_relationship_rules  |
  +----------------------------+    +---------------------------------+
  | type_id integer not null   |<-+ | rule_id integer not null        |
  | type_name varchar(255)     |  | | queue_id integer not null       |
  | type_incolumn bool         |  +-| type_id integer not null        |
  +----------------------------+    | rule_minimum integer            |
                                    | rule_maximum integer            |
				    | rule_objectfilter text?         |
				    +---------------------------------+

> - What's needed (or desired) in terms of integration with Hermes? I'm not very
> familiar with where this is now. If you could link a ticket with a time entry
> in hermes, and custom fields (those queue attributes) could be linked in too,
> how would that be? Or maybe if you entered hours along with comments in Whups,
> and that generated an entry in Hermes automatically? Etc.

We'd like to associate time entered in Hermes with tickets, and perhaps
other things like clients and projects in the future (but these can be
deduced from tickets).

I'd like to be able to enter hours when updating or adding a comment to
a whups ticket, but that's not really important.

We'd like to be able to associate tickets in whups with deliverables and
projects in thor, with clients, with employees, etc.

It's be nice to associate tickets with other materials - files in
giapeto or pages in the wiki etc., but that's not necessary.

We could implement dependencies, which are something we'd like, by
associating tickets with other tickets with a "Depends on" relationship
type.  That might not be practical, though.

> Just trying to understand how this should all work before I put more time into
> putting it back together/ripping it up.

Those are my overly-wordy thoughts :)

> 
> -chuck

-- 
 Jason M. Felice
 Cronosys, LLC <http://www.cronosys.com/>
 216.221.4600 x302