taskruQueue - Tasks: task #4295, help@system mail integration


You are not allowed to post comments on this tracker with your current authentication level.

task #4295: help@system mail integration

Submitted by:  John Fulton <jfulton>
Submitted on:  Tue 21 Jun 2005 04:12:50 AM UTC  
Should Start On:  Tue 21 Jun 2005 12:00:00 AM UTC Should be Finished on:  Fri 21 Oct 2005 12:00:00 AM UTC
Category:  None Priority:  1 - Later
Status:  None Privacy:  Public
Percent Complete:  0% Assigned to:  None
Open/Closed:  Open Effort:  0.00

Tue 21 Jun 2005 04:12:50 AM UTC, original submission:

If you have staff who answer user questions via email and
you want ruQueue to track it, then you could take advantage
of this proposed task.

I can think of two methods of help@system mail integration:

1. Mail Interface:

A user sends a ticket to help@system. Help@system replies to the
user and BCC's ruQueue. Then a ticket is created. Help@system can
use XML (in the header) to make certain changes (e.g. change
queue, change status, resolve, etc.). The user will never reply
to all and input into the ticket. Help@system should BCC in
order to include the user's response and their reply. This will
use the same library that Andy's API will use.

* Power users of ruQueue will like it since they can be told
what to do (like the API) to achieve their end, and implement
the means the way that they feel is best.

* Minimal interruption to help@systems workflow.

* Others watching help@system mail may not know how to
configure their mail agent to use this solution.

* We can provide instructions for how to do it for a few
mailers, but not every mailer.

2. Web Interface:

A web-interface (like the rest of ruQueue) is used to interact with
the help@system email. This web-interface would do the
appropriate action to the ticket along with the sending the

* Single Standard Interface that anyone could use.
* User friendly.

* Power users may not like the lack of options.
* Change to help@systems workflow.


I believe I've come up with a solution that will let us be rid of the
cons of the above approaches and just choose the pros: we write a web
interface for the help@system email that can talk to ruQueue, however we
document how that interface works so that a power-user could modify
their mail client to do the same thing if they wanted to. The standard
way to answer help@system email would be to use the web interface, but
that doesn't mean that we can't allow other methods.


One issue with writing a web interface is that a lot of programming
would be required to implement a web-mail system. We should take
advantage of a proven system. I suggest that we get a copy of
SquirrelMail (Free software already written in PHP) and modify it
to interface with ruQueue. That way we'll know that the mail aspect
of the system will work and we can focus on the interface to ruQueue.
After we setup a copy of SquirrelMail on the same server as ruQueue
we can modify it to allow people to use the same authentication
mechanism that they use on ruQueue, i.e. they could just click from
inside of ruQueue.

The next aspect of SquirrelMail that would need to be modified is the
the form that allows you to compose email. This form will need to have
some extra fields put in it. Besides the To: and Body: of the message
there will need to be a set of pull downs which specify what you want
to do to the relevant ticket, e.g. resolve, open, change queue,
etc. Modifying the form should not be too difficult, but once we have
it working how do we get the specifics of that form to ruQueue?

We could have SquirrelMail open up a connection to MySQL, but this
could be complicated. Instead we could take advantage of the API that
we will already have so that our modifications to SquirrelMail will be
minimal (thus less error prone). All that we have to do is add the
appropriate information into the outgoing mail headers (that includes
bcc'ing comment@ruqueue). The end user won't have to know that there is
XML underneath. The system will translate the pull-down menus into the
necessary XML and send it along.

We could even have an external form to create tickets in ruQueue directly
which would sent things up so that help@ staff can use this proposed

The system can have its own security in that we could make the system
only accept email from a certain address. However, for extra security
would could PGP the XML sent in the headers. We would only give the
public key to those we trust and ruQueue could then decode the directions
with the private key. The details of how it works could then be shared
with help@ systems so that they can modify their mailer to work with
it if they choose (Rutgers system's folkes like pine, which already
interfaces with PGP to send encrypted email and modifying it to send
headers is easy enough).

In summary: we provide a mailer that is web-based - so that anyone can
use it - which would take care of the help@ integration and leave the
end user with options. This solution is simple, so hopefully it will
be cost-effective and not very error-prone. It also takes advantage of
things that we already have.

John Fulton <jfulton>
Project Administrator


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.




No changes have been made to this item

Back to the top

Powered by Savane 3.3