Re: more types stuff

> > here's another addition that we're finding useful over here -- the ability
> to

<snip>

> Hrm. I have mixed feelings about this one - I'm pretty sure that tickets
> shouldn't be changing type, though. At least not often. Well...

I tend to agree with you on this -- the types shouldn't be changing around too
much. But I can forsee instances where someone reporting a bug would give a
ticket the wrong type, and this might mean that someone allocated to watch that
type might miss the issue entirely.

Also given that whups is extremely flexible we can't really predict how
different people are going to set up their types (they might actually use
'types' the way you're suggesting using 'modules').

> I'm going to commit this for now, but restrict the functionality to admin
> users.
> Also, could you submit a patch that adds a second step form, so that we don't
> get invalid state or priority data when this happens? Users should get a
> chance
> to make sure that the state/priority is still valid.

yep that's a good idea. I'll have a look at that now.

> I think it'd work better to allow moving tickets into different modules, in
> general, though.

ok I think this would cover a situation in which developers/technicians/whatever
are allocated to tickets on the basis of what module they're in. It doesn't
really cover a situation in which tickets are allocated to staff on the basis
of type (eg. 'mail server issue' vs 'web server issue', which might be 'types'
within the 'sysadmin' module or whatever).

Also I think focusing on moving modules rather than types would make more sense
if we could separate the client list from the modules. At the moment the only
way to represent a 'client' in whups is to create a module for it. So right now
it doesn't really make sense to move a ticket to another module when you're
working with multiple clients (to change a ticket's module would be to change
its client). I know there are some moves afoot over on the hermes and juno
lists to move clients to a Turba addressbook, and that's going to improve the
situation for people with multiple clients. Anyone know where that's up to?

(actually i should explain -- i have an early version of a new application to
help with network tech support that also uses 'clients' so i'm also keen to see
clients abstracted from whups! if anyone is interested in this app i can submit
it)

thanks,

bo.





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