Changing queue name: what's the consequences?

What are the consequences of changing a queue name?

ie:

  • What other things do I need to change to make things work?
  • Do any pre-existing URLs break?
  • Will pre-existing saved searches with that queue name break?
  • etc?

I see I need to change the “|/usr/local/rt3/bin/rt-mailgate --queue” in my
.forward/.qmail files. There may be some human confusion along with this
when the email address associated with a queue no longer matches the queue
name (if one had that set up in the first place).

Anything else?

I see other references in the email list archive on this, but they seem to
be ancient.

-Matt

Matt England wrote:

What are the consequences of changing a queue name?

ie:

  • What other things do I need to change to make things work?
  • Do any pre-existing URLs break?
  • Will pre-existing saved searches with that queue name break?
  • etc?

I see I need to change the “|/usr/local/rt3/bin/rt-mailgate --queue” in
my .forward/.qmail files. There may be some human confusion along with
this when the email address associated with a queue no longer matches
the queue name (if one had that set up in the first place).
You only have to change places where you use queue name direct instead
of id. For example in scrips. RT Core code uses IDs so name changing is
transparent.

You can leave old alias for some time(with new queue name as argument)
and add another one, then hide old email address from all public
resources. After some sane time you can drop old alias.

You only have to change places where you use queue name direct instead
of id. For example in scrips. RT Core code uses IDs so name changing is
transparent.

I’m trying to build a comprehensive list of these “places.” Here’s a start:

Scrips
.forward/.qmail files
SavedSearches (? pending question)
URLs (? pending question)

Anything else?

Also: can I substitute the internal queue IDs (for queue names) in any of
these places so these things/places can be more flexible?

You can leave old alias for some time(with new queue name as argument)
and add another one, then hide old email address from all public
resources. After some sane time you can drop old alias.

Thanks for the tip. The email management side is the easy part for me; I’m
familiar with email-system-management, aliasing old email addrs, etc. I’m
new to RT, so I’m trying to figure out all the associated RT management
logistics.

-Matt

At 7/12/2005 07:28 AM, Ruslan U. Zakirov wrote: