[rt-devel] RE: [rt-users] Some features I'd like to see

[Jesse]

On Sat, Mar 18, 2000 at 11:07:01AM -0500, Daniel Rinehart wrote:
> 
> 	I think that last point is the most important. Different places
> that use RT are going to have very different work flows in how tickets are
> assigned, dealt with, merged, etc. Given the more modular design of RT2 I
> think the following might be something to consider.
> 
> 	Using grouping and parent-child relationships, combined with
> logic, a default set of work flows can be created, but also allow
> customization based on a particular site's needs.
> 
> 1) Grouping: This supersedes the "merge" functionality. Two or more
> requests on the same subject can be associated with each other and then
> actions can be done on the complete set, a subset, or the individual
> request. This would also allow easy "unmerging" or "splitting" requests,
> should you change your mind.
> 
> 2) Parent-Child: Single Parent multiple Child. This allows the
> ability to create dependencies or subtasks. It would also allow the ability
> to divide up a multiple request, request into sub requests which could
> then be assigned to different people (most likely by creating new requests
> and associating them)
> 
> 3) Interrelationships: This is where things get icky, but if done, would
> add a lot of flexibility or power to the system. Allow groups to be either
> the parent or child in a relationship. A example: 5 different people send
> is requests that the mail spool is full. Use grouping to associate them to
> together. The create 2 child requests one of which is assigned to an admin
> to find a quick solution while the other is assigned to purchasing to
> order more disk space.
> 
> 	Logic would be needed to make sure that loops weren't created and
> that things like orphaned requests didn't appear in the relationships.
> Finding intuitive ways to show this to users gets interesting.
>


This actually sounds a lot like what I was already planning :)
Eventually I see several distinct ticket types:
	* User Request
	* Trouble Ticket
	* Bug
	* Task

These aren't firm distinctions. In earlier iterations of this, I really only had Requests, Tasks and Bugs..
But I thiink these four make sense. In this system,
	The users would send in Requests describing the problem that they were experiencing.
An administrator would open a Trouble Ticket and associate all the user requests with it.
Then, she would create two children of the trouble ticket "Clean out a bit of space" and "Buy some disk"
 
But anyway, I don't think you've gone off the deepend. or, if you have, so have I.

	jesse 

> 	Maybe I'm just rambling, maybe I've gone off the deep end, but I
> thought I'd throw it out.
> 
> -- Daniel R. <danielr at ccs.neu.edu> [http://www.ccs.neu.edu/home/danielr/]
> 
> 
> 
> _______________________________________________
> Rt-devel mailing list
> Rt-devel at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-devel
> 

-- 
jesse reed vincent -- jrvincent at wesleyan.edu -- jesse at fsck.com 
pgp keyprint:  50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
--------------------------------------------------------------
...realized that the entire structure of the net could be changed to be made 
more efficient, elegant, and spontaneously make more money for everyone 
involved. It's a marvelously simple diagram, but this form doesn't have a way 
for me to draw it.  It'll wait. 				-Adam Hirsch