After Update Relationships are lost!

After Update from 2.0.8 to 2.0.9 the Relationships were lost.

The History shows there are Relationships set but the Relationsips
section shows nothing.

Where are this information safed? I found nothing in the mysql db?

We had a simular problem with the upgrade from 2.0.7 to 2.0.8 but we had
only one Ticket with Relations.

Thanks in advance.
Henning Wackernagel
Netzwerkadministration
Schlund + Partner AG
Erbprinzenstr. 4 - 12 Mail: wackernagel@schlund.de
76133 Karlsruhe Tel: 0721 / 91374-0

After Update from 2.0.8 to 2.0.9 the Relationships were lost.

The History shows there are Relationships set but the Relationsips
section shows nothing.

same problem at my installation. :frowning:
-andreas

After Update from 2.0.8 to 2.0.9 the Relationships were lost.

The History shows there are Relationships set but the Relationsips
section shows nothing.

same problem at my installation. :frowning:
-andreas

Please do not ever change the “$rtname” variable in etc/config.pm of rt, if
you have already tickets in the database! This is written in the config
file itself :wink:

-andreas

hiho,

Please do not ever change the “$rtname” variable in etc/config.pm of rt, if
you have already tickets in the database! This is written in the config
file itself :wink:

-andreas

Arg! This is so …

Why can not take the updatescript the settings?

Thanks,
Henning Wackernagel
Netzwerkadministration
Schlund + Partner AG
Erbprinzenstr. 4 - 12 Mail: wackernagel@schlund.de
76133 Karlsruhe Tel: 0721 / 91374-0

hiho,

Please do not ever change the “$rtname” variable in etc/config.pm of rt,
if you have already tickets in the database! This is written in the
config file itself :wink:

-andreas

Arg! This is so …

Why can not take the updatescript the settings?

Thanks,

Perhaps, you can update the “Base” and “Target” Attributes columns from the
“Links” table. I’m not sure if anything else can make trouble if you change
the $rtname?

-andreas

Please do not ever change the “$rtname” variable in etc/config.pm of rt, if
you have already tickets in the database! This is written in the config
file itself :wink:

Ok, how about this concept;

One Organisation.
Multiple Ticket queues
*Seperate* Numbering systems for each queue.

Is it possible to use one SQL database, and multiple $rtname variables to
seperate out the queues ?

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

Regards,

                         Bruce Campbell                            RIPE
                                                                    NCC
                                                             Operations

Ok, I have changed the DB enteries by Hand and now everythink is ok.
Next time by an Update I will check “config.pm”. Can someone take this
in the Dokumentation?

Thanks to all for the help.
Henning Wackernagel
Netzwerkadministration
Schlund + Partner AG
Erbprinzenstr. 4 - 12 Mail: wackernagel@schlund.de
76133 Karlsruhe Tel: 0721 / 91374-0

Please do not ever change the “$rtname” variable in etc/config.pm of rt, if
you have already tickets in the database! This is written in the config
file itself :wink:

Ok, how about this concept;

One Organisation.
Multiple Ticket queues
Seperate Numbering systems for each queue.

Is it possible to use one SQL database, and multiple $rtname variables to
seperate out the queues ?

Hrm, this isn’t what I want. $rtname appears to be used for:

Pretty naming of Web Pages  (RT/$rtname)
Ticket Acknowledgements
Mail loop detection	(X-RT-Loop-Prevention: $rtname)
Self-check on incoming tickets (subject line match)
Identifier on outgoing tickets
Other misc things which don't seem to be important ;)

$rtname isn’t actually stored in the SQL database, leading to the
conclusion of one RT2 instance, one number sequence irrespective of number
of queues. Poot.

As an aside, I’d suggest another feeping creaturism, being to support
migration from previous ticketing systems which had a different identifier
($rtname) in the subject line, but where the same numbering system has
been preserved in conversion from previous ticketing system to RT2
, ie:

etc/config.pm:
	# Incoming subject line match to assist with migration
	rtname_regex = "^\s*\[(old-org-name|new-org-name)\s+\#(\d+)\]\s*";

	# Field within pattern match which has the ticket $Id
	# See perlre man page - 1-9 is the limit
	rtname_regex_Id = 2;

lib/RT/Interface/Email.pm - ParseTicketId():
    my $retval = undef;
    if ($Subject =~ s/\[$RT::rtname \#(\d+)\]//i) {
        $Id = $1;
        $RT::Logger->debug("Found a ticket ID. It's $Id");
	$retval = $Id;
    }
    elsif ( defined( $RT::rtname_regex ) && defined( $RT::rtname_regex_Id ) ) {
        if ( $RT::rtname_regex_Id =~ m/^\d+$/ && $Subject =~ m/$RT::rtname_regex/i ) {
		my (@tsplit) = ("", $1, $2, $3, $4, $5, $6, $7, $8, $9);
		if( defined( $tsplit[$RT::rtname_regex_Id] ) ) {
			# Paranoia checks just in case the local
			# administrator didn't quite specify a
			# number pattern match.  Avoid possible
			# problems later when SQL gets involved.
			my $tval = $tsplit[$RT::rtname_regex_Id];
		        $RT::Logger->debug("Found a possible ticket ID.  It's $tval");
			$retval = $tval if( $tval =~ /^\d+$/ );
		}
	}
    }

    return( $retval );

Ie, if you previously generated tickets like [some_name #1234] and now are
[some_other_name #4321], but do want to preserve continuity to your users
without dropping tickets.

                         Bruce Campbell                            RIPE
                                                                    NCC
                                                             Operations

Ok, how about this concept;
Seperate Numbering systems for each queue.

Because of the underlying way that database sequences are used

this is unlikely to be doable without a fairly major rewrite. If you
just think of the ticket ids as a opaque identifiers, you’ll be happier :wink:

Is it possible to use one SQL database, and multiple $rtname variables to
seperate out the queues ?

I recall seeing a patch for this at some point.

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?

Regards,


Bruce Campbell RIPE
NCC
Operations


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

[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 :wink:

So, a hack to do multiple sequences like that would hurt rather a lot.
A possible solution that might not suck quite as badly from a mantainability
perspective is to have a “translator” that sits between the mail gateway
and maps old ticket ids to new RT2 ticket ids. (perhaps using RT’s relationships functionality and defining an OldTicket RefersTo new ticket mapping.) Over
time, as old tickets got dealt with, things would move gracefully into the
new system, with less hacking to RT, which would mean fewer hassles for you
long term :wink:

For the password issue, if you end up with multiple RT instances, you might
just want to configure RT to use external authentication and set up HTTP auth
for all of your RT instances against the same password database…

Does that make sense?

JesseOn Wed, Nov 21, 2001 at 06:53:58PM +0100, Bruce Campbell wrote:

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 :wink:

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

So, a hack to do multiple sequences like that would hurt rather a lot.

Assuming just one RT instance, yes. Assuming multiple instances, its not
a biggie.

A possible solution that might not suck quite as badly from a mantainability
perspective is to have a “translator” that sits between the mail gateway
and maps old ticket ids to new RT2 ticket ids. (perhaps using RT’s relationships functionality and defining an OldTicket RefersTo new ticket mapping.) Over
time, as old tickets got dealt with, things would move gracefully into the
new system, with less hacking to RT, which would mean fewer hassles for you
long term :wink:

I think I need to look at this relationship mapping thing.

For the password issue, if you end up with multiple RT instances, you might
just want to configure RT to use external authentication and set up HTTP auth
for all of your RT instances against the same password database…

Hrm, may do.

Does that make sense?

Somewhat. I must go and contemplate my naval.

                         Bruce Campbell                            RIPE
                                                                    NCC
                                                             Operations