[whups] Clients

[Chuck Hagenbuch]

Quoting "Jason M. Felice" <jfelice at cronosys.com>:

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

Okay, I think I'm with you going with something like the below...

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

Yes.

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

I think this has possibilities. We'd essentially be storing the 
relationship in
Whups' tables (so Whups could search on it). We'd want some way to access the
relationship from Turba, too, but we can work on that.

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

Easy with Relationship_Manager, except for the case as above of things that we
want to be able to search on faster. Would be great if it could handle
everything.

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

This is something I'd like to handle with DataTreeObject_Relationship
subclasses. One of the things I want to do before release is add a
validate($action) method to relationship objects, so that subclasses can
disallow deletion, completion, etc. when there are dependancies.

-chuck

-- 
"But she goes not abroad in search of monsters to destroy." - John 
Quincy Adams