Hello,
I am considering an installation of RT, however, I am faced with a somewhat
non-standard (or not well publicly documented) use case. The support
systems/queues to be implemented are not intended to be used by just anyone,
but only by paid customers. And while authenticating customers who use web
interface is more or less an easy process (and well documented), I am
concerned with the e-mail interface. Ideally, I would like to only create
ticket if a special pre-issued code is included in the request e-mail; all
others should be politely replied-to but without ticket creation. The codes
are present in an easily queried SQL database.
I have browsed and searched through mailing list archives, but didn’t manage
to turn up anything similar. In the documentation,
LookupSenderInExternalDatabasehttp://wiki.bestpractical.com/view/LookupSenderInExternalDatabaselooks
promising but lacks any explanations; also, the
RT-Extension-ExtractCustomFieldValueshttp://cpan.uwinnipeg.ca/dist/RT-Extension-ExtractCustomFieldValuesextension
looks like something which neatly fits into the idea. However,
being an RT beginner, I am a bit stumped as to how to fit it all together to
achieve the desired behaviour.
Perhaps I am not the first RT user who needed to implement non-public
support queue with an e-mail, or someone has implemented a similar system.
Any useful advice and/or pointers to information, examples and manuals would
be greatly appreciated.
Many thanks in advance,
Michael Bravo
No, that would be a cop-out, but would kind of defeat the whole endeavour.
Perhaps I wasn’t clear enough - I already have a large number of customers
entitled to e-mail support. And they do have the magic codes. Also, for the
considerable majority of my customerrs, e-mail is more accessible and
convenient than web. At least to start the support request. As such, the
workflow I outlined is more or less a necessity - accept e-mail, parse the
magic code, and either auth the user and create the ticket, or autoreply and
no ticket.On Wed, Aug 19, 2009 at 1:43 AM, Jerrad Pierce < jpierce@cambridgeenergyalliance.org> wrote:
My guess would be:
Do the initial auth and ticket creation via the web, so that you can
impose whatever
requirements you wish e.g; login to SelfService with something like
mod_auth_mysql
Add these customers as privileged users to a group with no special ACLs.
Then
prevent the creation of tickets by non-privileged users.
No, that would be a cop-out, but would kind of defeat the whole endeavour.
That’s an interesting characterization of free advice that doesn’t meet your
changing criteria.
Perhaps I wasn’t clear enough - I already have a large number of customers
entitled to e-mail support. And they do have the magic codes. Also, for the
Yes, which they could use to authenticate.
considerable majority of my customerrs, e-mail is more accessible and
convenient than web. At least to start the support request. As such, the
workflow I outlined is more or less a necessity - accept e-mail, parse the
magic code, and either auth the user and create the ticket, or autoreply and
no ticket.
Then, you’re going to have to do a lot of monkeying around with an
RT::Interface:
:Filter. I’d start with the existing SpamAssassin.pm
(Fail if sender + magic cookie are invalid). You don;t get a lot of control
over the failure message though.
But really, the “Email” thing is a red herring. All you really need to
do is have
all inbound tickets go into a (temporary queue), and use a scrip to
verify tickets
and move the legitimate ones to a real queue / reject the freeloaders.
This should
be very simple with ExtractCustomFieldValues. See recent thread on doing
something with a dummy CF field value.
Cambridge Energy Alliance: Save money. Save the planet.