Questions before i install

RT Users
1

i’m about to install rt; before i dive in, some questions:

  1. the downloaded rt.tar.gz is version 1.0.3; i see commit message regarding 1.3.12, and i see discussion of 2.0
    I assume that “2.0” is what 1.3.x will become?

  2. i assume that when 2.0 comes out, there will be upgrade scripts from the database in version1.0.3.
    but if i install the 1.3.x from cvs (not to mention the twort from sourceforge), i presume there might
    not be scripts to automatically upgrade my database to be compatible with the final 2.0 version?
    so if i do put a 1.3.x snapshot into production, i might be setting myself up for writing some custom sql
    later on?

  3. there is little information on the sourceforge site about twort. judging from the cvs dates,
    there have been checkins there, but there is no information i can find indicating how it compares
    to the fsck cvs archive. Also, neither twort nor fsck seems to have a cvs snapshot available;
    i don’t feel like playing “do i feel lucky” and downloading whatever the latest cvs happens to be,
    even if i did want to try 1.3.x instead of 1.0.3.

  4. i’m kind of mystified by the various rt email aliases, even after reading the README, fax, and user guide.
    There is the “rt mail alias”, which would typically be “rt”.
    Then there is the “default” or “primary” queue, which i guess would be something like “rt-general”,
    and others for each other queue (“rt-helpdesk”, “rt-office”, etc.).
    Then there are optional email aliases for actions, which i guess have to be per-queue, something
    like “rt-general-action”, etc. – if i choose to continue the convention of starting each with “rt-”.
    But when does email originate from the “rt mail alias” (typically “rt”), rather than from a queue?
    When would users send email directly to “rt” rather than to “rt-$queuename”?
    Why does there even have to be a user named “rt”? (assuming i have some other user to
    run my httpd and to login to mysql).

  5. i also couldn’t find a clear explanation of “correspond” vs. “comment”.

  6. is there any revised ETA for a 2.0 alpha?

-mda

2

i’m about to install rt; before i dive in, some questions:

  1. the downloaded rt.tar.gz is version 1.0.3; i see commit message regarding 1.3.12, and i see discussion of 2.0
    I assume that “2.0” is what 1.3.x will become?

You got it.

  1. i assme that when 2.0 comes out, there will be upgrade scripts from the database in version1.0.3.

Also Correct.

but if i install the 1.3.x from cvs (not to mention the twort from sourceforge), i presume there might
not be scripts to automatically upgrade my database to be compatible with the final 2.0 version?

You’re on a roll.

so if i do put a 1.3.x snapshot into production, i might be setting myself up for writing some custom sql
later on?

Yep. and 1.3.x really isn’t feature complete yet. It’s guaranteed to be
both buggy and insecure.

  1. there is little information on the sourceforge site about twort. judging from the cvs dates,
    there have been checkins there, but there is no information i can find indicating how it compares
    to the fsck cvs archive. Also, neither twort nor fsck seems to have a cvs snapshot available;

The 1.3.x releases of RT are essentially minimally tested CVS snapshots. Automated snapshots would be no more stable than checking out the current rt-1-1 branch from CVS.

i don’t feel like playing “do i feel lucky” and downloading whatever the latest cvs happens to be,
even if i did want to try 1.3.x instead of 1.0.3.

nod Completely fair. 1.3 is still for people who want to hack code.

  1. i’m kind of mystified by the various rt email aliases, even after reading the README, fax, and user guide.
    There is the “rt mail alias”, which would typically be “rt”.
    Then there is the “default” or “primary” queue, which i guess would be something like “rt-general”,
    and others for each other queue (“rt-helpdesk”, “rt-office”, etc.).
    Then there are optional email aliases for actions, which i guess have to be per-queue, something
    like “rt-general-action”, etc. – if i choose to continue the convention of starting each with “rt-”.
    But when does email originate from the “rt mail alias” (typically “rt”), rather than from a queue?

Errors come from RT’s mail alias. Queues which don’t yet have an email address
assigned to them send their mail from rt’s mail alias.

When would users send email directly to “rt” rather than to “rt-$queuename”?

Once a ticket is created, it really doesn’t matter what alias things get sent to.
RT just does the right thing. rt@ is nice and convenient for people who know
what they’re doing, though.

Why does there even have to be a user named “rt”? (assuming i have some other user to
run my httpd and to login to mysql).

RT’s scripts run setuid to the RT user. That user alone has permission to know
what rt’s mysql database password is and to read and write content files
from disk.

  1. i also couldn’t find a clear explanation of “correspond” vs. “comment”.

Comments don’t get sent to the end-user. correspondence does.

  1. is there any revised ETA for a 2.0 alpha?

Depends on what you want in it. It does basically run now. it doesn’t do
everything right, though. What featureset are you looking for?

Jesse

-mda

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

jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
“It’s buried in the desert, got sand in it, melts Nazis. You know,
the Ark of the Covenant” – siva

3

Errors come from RT’s mail alias. Queues which don’t yet have an email address
assigned to them send their mail from rt’s mail alias.

When would users send email directly to “rt” rather than to “rt-$queuename”?

Once a ticket is created, it really doesn’t matter what alias things get sent to.
RT just does the right thing. rt@ is nice and convenient for people who know
what they’re doing, though.

hmmm, so why not just use one email alias for the entire system?

in fact, what i’m planning on doing is using fetchmail and examining the
subject line for things of the form “(queuename) whatever…” and it’ll
pipe to rt-mailgate with the appropriate first argument.
that takes care of the create case, and as you say, for all other cases it
doesn’t matter because the subject line already has the queuename.

i just have to train users to put “(queuename)” at the beginning of the subject
line when submitting requests, if they don’t want it sent to “general”.

shouldn’t that work?

  1. i also couldn’t find a clear explanation of “correspond” vs. “comment”.

Comments don’t get sent to the end-user. correspondence does.

hmmm, just to make sure i understand the intended use case:
is this for example when two sysadmins want to exchange some biting comment
that the submitter shouldn’t see, like “when will people ever learn that ‘I can’t print’
is not informative?”?

or do both correspond and comment go to the same message log, with
the same access control? if so, i guess i still don’t get the point.

  1. is there any revised ETA for a 2.0 alpha?

Depends on what you want in it. It does basically run now. it doesn’t do
everything right, though. What featureset are you looking for?

nothing in particular, as i haven’t got 1.0 up yet.
mostly i was concerned with getting myself educated on 1.0 only to see
it all replaced. i’ve already spent more time staring at manipulate.pm than
i care to. and inspecting perl code not using -w or -T is not my idea of a good time.

-mda

4

hmmm, so why not just use one email alias for the entire system?

Depends on your user community. Note that -comment -action and -correspond
aliases do different things to messages

in fact, what i’m planning on doing is using fetchmail and examining the
subject line for things of the form “(queuename) whatever…” and it’ll
pipe to rt-mailgate with the appropriate first argument.
that takes care of the create case, and as you say, for all other cases it
doesn’t matter because the subject line already has the queuename.

i just have to train users to put “(queuename)” at the beginning of the subject
line when submitting requests, if they don’t want it sent to “general”.

shouldn’t that work?

It should work great and I’d love to drop the patch in /contrib. I’ve tended
to work places with untrainable users :confused:

  1. i also couldn’t find a clear explanation of “correspond” vs. “comment”.

Comments don’t get sent to the end-user. correspondence does.

hmmm, just to make sure i understand the intended use case:
is this for example when two sysadmins want to exchange some biting comment
that the submitter shouldn’t see, like “when will people ever learn that ‘I can’t print’
is not informative?”?

or do both correspond and comment go to the same message log, with
the same access control? if so, i guess i still don’t get the point.

They go in the same message log. but are for things that customers shouldn’t see. Like “what a bozo” or “Don’t work on this. we’re about to fire this user”
or maybe even status updates that aren’t relevant to the user. Generally
users don’t have queue manipulate rights and thus can’t see comments. If there
were a usermode RT tool, it would be designed such that the users couldn’t see comments.

  1. is there any revised ETA for a 2.0 alpha?

Depends on what you want in it. It does basically run now. it doesn’t do
everything right, though. What featureset are you looking for?

nothing in particular, as i haven’t got 1.0 up yet.
mostly i was concerned with getting myself educated on 1.0 only to see
it all replaced. i’ve already spent more time staring at manipulate.pm than
i care to. and inspecting perl code not using -w or -T is not my idea of a good time.

Nor mine. I’m sorry. I wrote much of that before I learned how to code.
I’m hoping to get something usable out this summer and cranking as hard as I
can on it.

-mda

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

jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Emacs is a pretty good operating system, but Unix has a better editor.

5

Depends on your user community. Note that -comment -action and -correspond
aliases do different things to messages

btw, manipulate.pm in 1.0.3 uses ‘actions’ not ‘action’, but i don’t think
it matters, which is why no one has noticed before.

Nor mine. I’m sorry. I wrote much of that before I learned how to code.

so far it appears to me that you’ve made up for your lack of coding experience
with a good feel for usability & requirements.

far more common is something like bugzilla, which is ugly on both the inside
and the outside :).

-mda

6

Depends on your user community. Note that -comment -action and -correspond
aliases do different things to messages

btw, manipulate.pm in 1.0.3 uses ‘actions’ not ‘action’, but i don’t think
it matters, which is why no one has noticed before.

grin

Nor mine. I’m sorry. I wrote much of that before I learned how to code.

so far it appears to me that you’ve made up for your lack of coding experience
with a good feel for usability & requirements.

far more common is something like bugzilla, which is ugly on both the inside
and the outside :).

Thanks! Take a look around the internals of 1.3.12. I think you should find them
a bit less um, disgusting :wink:

-j

-mda

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

jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
I have images of Marc in well worn combat fatigues, covered in mud,
sweat and blood, knife in one hand and PSION int he other, being
restrained by several other people, screaming “Let me at it!
Just let me at it!” Eichin standing calmly by with something
automated, milspec, and likely recoilless.
-xiphmont on opensource peer review

7
  1. there is little information on the sourceforge site about twort.
    judging from the cvs dates, there have been checkins there, but there is
    no information i can find indicating how it compares to the fsck cvs
    archive. Also, neither twort nor fsck seems to have a cvs snapshot
    available; i don’t feel like playing “do i feel lucky” and downloading
    whatever the latest cvs happens to be, even if i did want to try 1.3.x
    instead of 1.0.3.

More info about “twort” will come shortly, including a running
demonstration instance. It’s official name is now “Support Tracker”
(suptra).

I have as a policy that I never check in things before testing locally
that things doesn’t break, and that bugfixes are committed immediately. I
would appreciate it greatly if anybody actually tested the stuff in the
cvs and reported bugs.

I do use SupTra in the production here … an old, stable version for
receiving mail, and the version I’m actively hacking on for the Web UI.
That way errors in the Web UI are dealt with quite quickly.

Then there are optional email aliases for actions, which i guess have
to be per-queue,

Not really; RT doesn’t need to know what queue a request belongs to
as long as you give away the id of the request (serial_num in RT1). It’s
only important to specify the queue when a request is created, this will
normally only happen through the “correspond” action. The documentation
is a bit poor at this point.

  1. i also couldn’t find a clear explanation of “correspond” vs. “comment”.

Correspond is communication with the requestor, comment is communication
that is kept secret to the requestor.

  1. is there any revised ETA for a 2.0 alpha?

My plans is to have all the essential features in place by August the
14th, and invite people for testing it and rank what features they want to
see, and eventually commit those.

One week later I’ll introduce a code freeze. SupTra 2.0 will be released
as soon as the frequency of bug reports drops to a minimum.

Tobix - +47 22 925 871