Re: [RFR] templates://request-tracker3.6/templates
On Mon, Mar 24, 2008 at 11:10:18PM +0000, Justin B Rye wrote:
> > This setting corresponds to the $rtname variable in RT_SiteConfig.pm .
>
> Here and elsewhere you're contorting the punctuation to avoid
> ".pm."; I suppose we could use:
>
> This setting corresponds to the RT_SiteConfig.pm's $rtname variable.
>
> Odd... there doesn't seem to be an RT_SiteConfig.pm in the .deb,
> only an RT_Config.pm that says "NEVER EDIT RT_Config.pm. Instead,
> copy any sections you want to change to RT_SiteConfig.pm and edit
> them there." Huh? If it's an uneditable Perl module, why put it
> in /etc?
>
> But apparently I'm _really_ meant to put my config snippets in
> RT_SiteConfig.d/ and then run update-rt-siteconfig. In which case,
> perhaps we shouldn't be talking about .pm files anyway:
>
> This setting corresponds to the $rtname variable in the SiteConfig.
>
> (And likewise for other templates.)
Yes, RT_SiteConfig.pm is now dynamically created from these answers,
so it's not in the .deb anymore. All existing upstream documentation
talks about RT_SiteConfig.pm variables, so it felt natural to write so.
But it's indeed better to leave the filename out altogether. I went for
'configuration variable'. People caring about the name of the variable
should already know where to find it (or read NOTES.Debian etc.)
The fact that RT_Config.pm is in /etc is mostly historical. I'll see
about moving it, but now that it is in /etc, I'd have to prepare for
people having modified it despite the warnings. I'm not sure the gain
is worth the effort.
> > Template: request-tracker3.6/organization
> [...]
> > Using your fully qualified host or domain name is recommended.
>
> That sounds to me as if it might include fully qualified hostnames
> like "mypc.local". How about:
>
> Using your fully qualified hostname plus DNS domain name is recommended.
Well, 'fully qualified hostname' isn't very well defined, and it sounds
to me like it already includes the DNS domain name. How about this?
Using this machine's fully qualified hostname, including the DNS domain name,
is recommended.
> > Template: request-tracker3.6/correspondaddress
> [...]
> > This address will be listed in From: and Reply-To: headers of
> > correspondence email tracked by RT, unless overridden by a queue-specific
> > address.
>
> "Correspondence email" feels unnatural. It could be "emails",
> "correspondence", or "email correspondence".
RT has two classes of email: correspondence (usually seen by the client)
and comments (usually internal to the helpdesk or whatever). The important
thing here is that it's not 'comment email' but the other.
I settled for just 'emails' for now, what about 'correspondence messages'?
> > Template: request-tracker3.6/commentaddress
> [...]
> > This address will be listed in From: and Reply-To: headers of comment
> > email, unless overridden by a queue-specific address. (Comments can be
> > used for adding ticket information that is not visible to the client.)
>
> Again, since we're talking about individual messages it doesn't feel
> right to talk about "email". "Comment emails"?
OK.
All other suggestions applied. Thanks! Updated templates attached.
Please comment or at least ack them so I know when to proceed
to the translation phase.
On Tue, Mar 25, 2008 at 06:49:47AM +0100, Christian Perrier wrote:
> Once setteld, I recommend of course using podebconf-report-po to call
> for translation updates (use it with "--call" to also call for new
> translations). I recommend a minimum of 10 days left to
> translators. Of course, you may prefer doing a first upload with the
> new templates, then another one (or more) with l10n updates.....as
> long as you commit to do them and not make them rot in the BTS, that's
> fine by me..:-)
Sure, I'll try to be good :)
Cheers,
--
Niko Tyni ntyni@debian.org
Template: request-tracker3.6/rtname
Type: string
_Description: Name for this RT instance:
Every installation of Request Tracker must have a unique name. RT will
add this name to the subject lines of all outgoing emails, and look for
it in incoming emails to figure out what ticket a message belongs to.
.
The domain name or an abbreviation of the name of your organization are
usually good candidates.
.
Please note that once you start using a name, you should probably never
change it. Otherwise, mail for existing tickets won't get put in the right
place.
.
This setting corresponds to the $rtname configuration variable.
Template: request-tracker3.6/organization
Type: string
_Description: Identifier for this RT instance:
In addition to its name, every installation of Request Tracker must also have
a unique identifier. It is used to generate Message-Id headers of outgoing
emails and unique ticket identifiers when linking between RT
installations.
.
Using this machine's fully qualified hostname (including the DNS domain name)
is recommended.
.
This setting corresponds to the $Organization configuration variable.
.
Template: request-tracker3.6/correspondaddress
Type: string
_Description: Default email address for RT correspondence:
This address will be listed in From: and Reply-To: headers of
emails tracked by RT, unless overridden by a queue-specific
address.
.
This setting corresponds to the $CorrespondAddress configuration variable.
Template: request-tracker3.6/commentaddress
Type: string
_Description: Default email address for RT comments:
This address will be listed in From: and Reply-To: headers of comment
emails, unless overridden by a queue-specific address. (Comments can be
used for adding ticket information that is not visible to the client.)
.
This setting corresponds to the $CommentAddress configuration variable.
Template: request-tracker3.6/webbaseurl
Type: string
_Description: Base URL to the web interface:
Please specify the scheme, server and (optionally) port for constructing
URLs to the RT web interface.
.
The value should not have a trailing slash (/).
.
This setting corresponds to the $WebBaseURL configuration variable.
Template: request-tracker3.6/webpath
Type: string
_Description: Path to the RT web interface:
If the RT web interface is going to be installed somewhere other than at
the root of your server, you should specify the path to it here.
.
The value requires a leading slash (/) but not a trailing one.
.
This setting corresponds to the $WebPath configuration variable.
Template: request-tracker3.6/handle-siteconfig-permissions
Type: boolean
_Description: Handle RT_SiteConfig.pm permissions?
The main RT configuration file, /etc/request-tracker3.6/RT_SiteConfig.pm,
contains the database password and should therefore not be world-readable.
On the other hand, the database password must be known by the web interface,
usually running as the www-data user.
.
The normal setup is to make the file owned by root with the group
www-data, and set the mode to 0640 (readable by the group but not
the world.) This can be made automatically, but please consider the
security implications first. For instance, if you have PHP installed
on the system, anyone running a PHP script could read the database
access details if the file is readable by www-data.
.
If the answer is negative, the file will be readable only by root,
and you will have to set up the access control yourself.
.
Note: if you are using SQLite as the database backend, your answer
will also affect the permissions of automatically generated local
database files.
Template: request-tracker3.6/fix-initialdata-442398
Type: boolean
_Description: Fix the "10 highest priority tickets I own" table automatically?
RT version 3.6.1 (the one distributed with the Etch release) had a bug
in the database initialization data that broke links in the "10 highest
priority tickets I own" table in certain circumstances.
.
While the initialization data has been fixed after Etch, existing
databases created with the Etch version can only be fixed by changing
the database contents. This can be done automatically if you want.
Note that if the database is already OK, this won't change anything.
.
The change will be attempted only once. If fixing the database fails for
some reason (for example because the database is unavailable), it won't be
tried again unless this setting is re-enabled (for instance with
dpkg-reconfigure).
.
See Debian bug #442398, http://bugs.debian.org/442398 , for more
information.
Reply to: