Re: [RFR] templates://request-tracker3.6/templates
Niko Tyni wrote:
> please review the attached debconf templates of request-tracker3.6
> 3.6.6-2~experimental3, currently in NEW and targeted at experimental
> for now.
> Template: request-tracker3.6/rtname
[...]
> Every installation of Request Tracker must have a unique name. RT will
> look for the name in mail messages to figure out what ticket a new piece
> of mail belongs to, and add it to the subject lines of all outgoing
> emails.
Here's a picky one: the "it" that's added is obviously the rtname
rather than a ticket or message, but switching the clauses round
would eliminate the need to work that out and also seems to make the
chain of events clearer:
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.
[...]
> 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.)
> 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.
> 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".
> 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"?
> Template: request-tracker3.6/webpath
> Type: string
> _Description: path to the RT web interface:
s/p/P/
> Template: request-tracker3.6/handle-siteconfig-permissions
[...]
> 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.
The executable may be php, but the language is named PHP.
> Template: request-tracker3.6/fix-initialdata-442398
[...]
> 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 with eg. dpkg-reconfigure.
A slightly mispunctuated Latin abbreviation. Make it:
tried again unless this setting is re-enabled (for instance with dpkg-reconfigure).
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: