Hi all,
Although we’ve been RT users for several years now, this is our first RT
implementation on a customer. However, this is not a usual application
of RT. We saw an opportunity to implement RT for citizen’s relationship
with Government institutions. So basically, if a citizen has a claim the
go to the institution’s web page and create a ticket in RT. I am sure we
are not the first to this, so any comments welcome. BTW we are using 3.6
because is the stable package on Debian 4.
Anyway, my first post is both an introduction and because there are
several things we need to build and adapt and we would like for these
adaptations to be fed back into the main product, if possible and
worthwhile of course. In any case, we plan to develop everything with
RT’s guidelines described in the code.
Issue 1 - Auto-registration form
Our first problem is that we need for the Citizens to be able to
register themselves in RT. Each Citizen needs to be a RT user because
the final response is to the Citizen. This may ringing all kinds of
alarm bells to normal RT usage, because of the sheer amount of users,
and because the adding of users is usually a task reserved for a
privileged user. But this is the way we’ve modeled it. We are going to
build a self-service registration form that does not require any
privileges.
Before we go and develop this there are several questions we would like
to address here:
-Has anyone else done this?
-Is it of any value for the core RT product?
-Is this crazy?
-Any other suggestions?
Thanks,
Alejandro Imass
Issue 1 - Auto-registration form
Our first problem is that we need for the Citizens to be able to
register themselves in RT. Each Citizen needs to be a RT user because
the final response is to the Citizen. This may ringing all kinds of
alarm bells to normal RT usage, because of the sheer amount of users,
and because the adding of users is usually a task reserved for a
privileged user. But this is the way we’ve modeled it. We are going to
build a self-service registration form that does not require any
privileges.
Before we go and develop this there are several questions we would
like to address here:
-Has anyone else done this?
-Is it of any value for the core RT product?
-Is this crazy?
-Any other suggestions?
Although the possible numbers are different, we have a similar setup for
RT. Our RT has 2 queues - one for Helpdesk and one for Human Resources.
Both use the self-service setup - so any Joe Sixpack can send in an
email and have access to create/comment/view his/her own ticket.
Where the real similaritly (if I am reading what you want to have happen
correctly) is that for our HR, we don’t use a “published” email address.
Anyone intereseted in a job at our school goes to
http://www.pavcsk12.org/apply/ That is a PHP form that I created that
will send an email to this unpublished email account.
So for those that are newly applying to our school, here is how it
looks/goes for them:
- The go to /apply/ on our website, and complete the form
- email sent to RT from the webform
- RT sees this is a new user (from the email address) and creates an
account
- RT emails back the applicate with a “thank you” as well as the login
directions
- Applicant can log into RT at any time to check the current status,
add notes, view notes, etc.
- Same time, HR personal can take care of ticket (searching for
qualifications, review submitted docs, etc)
- Person is interviewed/Hired/Dismissed/etc
I could very easily see this “translated” to a webform, sumbit to
Government queue (maybe even different queues per Government dept)
Citizen gets reply/directions/etc, Government personal “fixes” citizens
claim.
http://gentgeen.homelinux.org
Associate yourself with men of good quality if you esteem
your own reputation; for 'tis better to be alone then in bad
company. - George Washington, Rules of Civility