[rt-users] ticket number sequences

[Bruce Campbell]

On Wed, 21 Nov 2001, Jesse Vincent wrote:

[snip cautions and also patch mention]

> > I think what I'm really wanting is to have one user database for queue
> > (etc) ACLs, but otherwise seperate instances of RT2 (but also the ability
> > to toss a ticket between queues).
>
> Why? What are you losing by having one RT instance?

For historical reasons (heh), my current employer has run seperate
ticketing systems for each section.  When the revolution comes and the
marketing department is up against the wall[1]... or rather, when seperate
sections wish to move from their ticketing system to RT2, a certain
continuity of ticket numbering sequences is preferred.

Now, we can do this by having multiple instances of RT2, referring to
different config files and different database names.  That way, the
tickets for that section can be imported, and the same ticket sequence for
that section continues.

However, this also continues the current procedure of having multiple
areas where per-user ACLs must be configured; ie, a given staff member
must have their ACL configured in each RT2 instance.. implying that they
can have multiple, disjoint passwords if their job requires that they have
access to multiple sections.  ( with the predictable behaviour of 'I
forgot my password' 'to what?' 'I don't know, I forgot it' sequence to
support )

What I'd like is to somehow have multiple ticket numbering sequences
(multiple RT2 databases is the easiest way), but be able to point each RT2
instance at a common ACL database.

I think that this can be done without too much hassle (add a
rt_acl_db_name variable to config.pm, and ensure that appropriate
references to the ACL table are changed).  But I'm not sure that its the
'right' thing to do to solve the problem.

Regards,

-- 
                             Bruce Campbell                            RIPE
                                                                        NCC
                                                                 Operations

[1] We don't actually have a marketing department ;)