After using RT for years through CPAN, I’ve finally taken the plunge and
set it up for my company. The install of v3.4.2 went fairly well. I was
even able to get it running under mp2-RC6 with some hacking of the
webmux and HTML::Mason modules (not recommmended for the short-tempered :).
Now I’m trying to figure out how to manage this incredible tool. I have
setup 2 groups–staff and clients. Now I want my clients to be able to
submit tickets which my staff can take. I think that my preference would
be to have global queues with tickets categorized by client. The goal is
to allow a client to acces only their tickets but to allow staff to see
all tickets.
CPAN looks like a good model where each project has its tickets
separated. Is this done via separate queues or some other method? I’m
hoping that others have already been down this path and can advise me to
the most logical setup.
Also, is there a way to allow unregistered users the ability to bypass
the logon and simply submit a new ticket? Of course, when an
unregistered user submits a ticket, a new user is created. Is there a
way to grant access to that user to the RT system or must a new password
be manually created by an administrator? It’s probably best that they
not be granted immediate access since I would need to give them access
to the right queue or category of tickets (based on whatever design I
come up with from my question above).
Speaking of passwords, I’m finding that when I add a new user, I have to
submit the password twice before it will take effect. Is this normal?
I checked the Wiki and the manual but could not find any references to
the above despite all the other excellent advice I was able to find. If
I overlooked anything, references would be appreciated so that I know
where to look next time.
At Saturday 5/14/2005 10:19 AM, William McKee wrote:
Now I’m trying to figure out how to manage this incredible tool. I have
setup 2 groups–staff and clients. Now I want my clients to be able to
submit tickets which my staff can take. I think that my preference would
be to have global queues with tickets categorized by client. The goal is
to allow a client to acces only their tickets but to allow staff to see
all tickets.
William - I can’t answer all your questions, but here’s something for a
couple of them -
I think the typical setup is to use groups only for staff. The way to
distinguish between clients and staff is to flag staff users as
‘privileged’ and to leave client users unprivileged. The acl screens all
provide a way to set rights for privileged and unprivileged users. This way
you can define different access for staff & clients.
You can then use groups then control the access of different staff groups
to different queues.
CPAN looks like a good model where each project has its tickets
separated. Is this done via separate queues or some other method? I’m
hoping that others have already been down this path and can advise me to
the most logical setup.
Using queues for different projects would be a good approach.
Stephen Turner
Senior Programmer/Analyst - Client Support Services
MIT Information Services and Technology (IS&T)
Has any progress been made on getting RT 3.4 into FreeBSD ports? The
last update to the RT32 port was on 5/12/2005, and while there’s been
some murmoring on the list about a 3.4 port, nothing seems to have
been committed yet.
-n
-----------------------------------------------------------memory@blank.org
“History, which torments other countries, mostly just teases America.”
(–www.suck.com) http://blank.org/memory/---------------------------------------------------
William - I can’t answer all your questions, but here’s something for a
couple of them -
Hi Stephen,
Thanks for the reply. I was starting to think my message got lost in the
weekend traffic.
I think the typical setup is to use groups only for staff. The way to
distinguish between clients and staff is to flag staff users as
‘privileged’ and to leave client users unprivileged. The acl screens all
provide a way to set rights for privileged and unprivileged users. This way
you can define different access for staff & clients.
That’s the setup I’m hearing as I read through the messages on the list.
Do you provide the web interface for your unprivileged users or must
they correspond only via email? I can’t seem to get around the login
page when I’m trying to access the site as an unprivileged user.
You can then use groups then control the access of different staff groups
to different queues.
You’re working in a bigger organization than I :). One staff group will
be sufficient for the forseeable future though it’s good to have the
option in mind if only for a potential client.
CPAN looks like a good model where each project has its tickets
separated. Is this done via separate queues or some other method? I’m
hoping that others have already been down this path and can advise me to
the most logical setup.
Using queues for different projects would be a good approach.
OK, that’s the picture I’m starting to get. Now if I can only figure out
how to give an unprivilege user access to only his/her queue.
Has any progress been made on getting RT 3.4 into FreeBSD ports? The
last update to the RT32 port was on 5/12/2005, and while there’s been
some murmoring on the list about a 3.4 port, nothing seems to have
been committed yet.
FWIW, I had no trouble (besides hacking in support for mp2-RC6)
installing onto a FreeBSD server from source.
Has any progress been made on getting RT 3.4 into FreeBSD ports? The
last update to the RT32 port was on 5/12/2005, and while there’s been
some murmoring on the list about a 3.4 port, nothing seems to have
been committed yet.
I prodded tobez toward it, but it depends on his free time, so
I don’t really know how long it will take… And I’m stuck to
this highly addictive Pugs thing. :-/
At Monday 5/16/2005 01:43 PM, William McKee wrote:
That’s the setup I’m hearing as I read through the messages on the list.
Do you provide the web interface for your unprivileged users or must
they correspond only via email? I can’t seem to get around the login
page when I’m trying to access the site as an unprivileged user.
If you grant an unprivileged user access to RT, they will see the “Self
Service” interface - it gives visibility of their own tickets and the
ability to create tickets in queues they have rights to. They would still
have to log in though to get there.
I don’t think RT has an interface for unauthenticated users to create
tickets (apart from the email interface). I think I remember this subject
being raised before in the mailing list but I can’t find a reference.
Using queues for different projects would be a good approach.
OK, that’s the picture I’m starting to get. Now if I can only figure out
how to give an unprivilege user access to only his/her queue.
What would be the association between an unprivileged user and a queue?
Would it just be the tickets she created? If so, you can grant rights to
the Requestor role. Then she’d have access to “her” tickets.
At Monday 5/16/2005 01:43 PM, William McKee wrote:
That’s the setup I’m hearing as I read through the messages on the list.
Do you provide the web interface for your unprivileged users or must
they correspond only via email? I can’t seem to get around the login
page when I’m trying to access the site as an unprivileged user.
If you grant an unprivileged user access to RT, they will see the
“Self Service” interface - it gives visibility of their own tickets
and the ability to create tickets in queues they have rights to. They
would still have to log in though to get there.
I don’t think RT has an interface for unauthenticated users to create
tickets (apart from the email interface). I think I remember this
subject being raised before in the mailing list but I can’t find a
reference.
A while back, people posted templates for auto-generating passwords.
This one looks promising, but I do not know if it will work with 3.4.2
Using queues for different projects would be a good approach.
OK, that’s the picture I’m starting to get. Now if I can only figure out
how to give an unprivilege user access to only his/her queue.
What would be the association between an unprivileged user and a
queue? Would it just be the tickets she created? If so, you can grant
rights to the Requestor role. Then she’d have access to “her” tickets.
Steve
Autrijus Tang wrote:> On Mon, May 16, 2005 at 01:32:36PM -0400, Nathan J. Mehl wrote:
Has any progress been made on getting RT 3.4 into FreeBSD ports? The
last update to the RT32 port was on 5/12/2005, and while there’s been
some murmoring on the list about a 3.4 port, nothing seems to have
been committed yet.
I prodded tobez toward it, but it depends on his free time, so
I don’t really know how long it will take… And I’m stuck to
this highly addictive Pugs thing. :-/
It includes a couple of patches regarding internationalization & a new
italian translation. The only part it’s not really tested is the upgrade
of the DB schema from previous versions (or rather, the only person I
asked to test reported unspecified problems), but I really invented
nothing in that part, copying it directly from rt32 with just some minor
editing.
I followed the previous pattern, and generated a www/rt34 port to
preserve the 3.2.x customizations by elixus.
I patched the pkg-plist to make the port really relocatable
(eg. make RT_DIR=rt34 will install in /usr/local/rt34 instead of
/usr/local/rt3, and the package will deinstall cleanly)
I am sure it DOESN’T WORK with mod_perl2 2.0rc3 (the version in ports)
I plan to add some sample apache2 config files (for both mod_perl &
fastcgi), but that can be done later.
If you think it’s OK, you are free to commit it, possibly removing some
of the patches if you feel they are not really generally useful.
If you prefer me to post a PR, just tell me.
It includes a couple of patches regarding internationalization & a new
italian translation. The only part it’s not really tested is the upgrade
of the DB schema from previous versions (or rather, the only person I
asked to test reported unspecified problems), but I really invented
nothing in that part, copying it directly from rt32 with just some minor
editing.
I think I’m the unspecified tester … As it turns out, the problems I
had with the upgrade were related to some customizations. So I would
recommend removing rt3/local, doing the upgrade, making sure things
(most notably logins, which was where I had the most problems) work,
then adding your customizations back in.
Do you provide the web interface for your unprivileged users or must
they correspond only via email? I can’t seem to get around the login
page when I’m trying to access the site as an unprivileged user.
If you grant an unprivileged user access to RT, they will see the “Self
Service” interface - it gives visibility of their own tickets and the
ability to create tickets in queues they have rights to. They would still
have to log in though to get there.
I don’t think RT has an interface for unauthenticated users to create
tickets (apart from the email interface). I think I remember this subject
being raised before in the mailing list but I can’t find a reference.
ISTR several people noting they’d created standalone fill-out-forms
which created a ticket, and emailed to the mailgate.
Cheers,
– jra
Jay R. Ashworth jra@baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
If you can read this... thank a system administrator. Or two. --me
If you grant an unprivileged user access to RT, they will see the “Self
Service” interface - it gives visibility of their own tickets and the
ability to create tickets in queues they have rights to. They would still
have to log in though to get there.
I guess I’m not clear on how an unprivileged user accesses the
Self-Service interface. There is no link in the email that is sent out
or on the default login page. I have found the article about Rights in
the wiki which was useful.
It referenced a page called SelfService which made no sense to me as it
was talking about custom fields, not unprivileged user access. I also
found SelfService referenced on the Contributions page. This made it
look like an extension or patch but with no other link than the one
above.
I don’t think RT has an interface for unauthenticated users to create
tickets (apart from the email interface). I think I remember this subject
being raised before in the mailing list but I can’t find a reference.
The suggestions by Drew and Jay should work fine if I need to implement
that option. Too bad someone hasn’t made an extension or patch yet for
this feature.
What would be the association between an unprivileged user and a queue?
Would it just be the tickets she created? If so, you can grant rights to
the Requestor role. Then she’d have access to “her” tickets.
Yes, you’ve got the idea. I have granted SeeQueue to Everyone but still
do not know what the url is that she would use to see her tickets. Sorry
if I’m being dense.
If you grant an unprivileged user access to RT, they will see the “Self
Service” interface - it gives visibility of their own tickets and the
ability to create tickets in queues they have rights to. They would still
have to log in though to get there.
I guess I’m not clear on how an unprivileged user accesses the
Self-Service interface. There is no link in the email that is sent out
or on the default login page. I have found the article about Rights in
the wiki which was useful.
It referenced a page called SelfService which made no sense to me as it
was talking about custom fields, not unprivileged user access. I also
found SelfService referenced on the Contributions page. This made it
look like an extension or patch but with no other link than the one
above.
If you let unprivileged users log it, they are taken to SelfService. It is a
very stripped down version of the regular RT interface. To see what it looks
like, you can manually enter www.yoursite.tld/SelfService/index.html
If you let unprivileged users log it, they are taken to SelfService.
Based on Erek’s reponse, I’m guessing I have to assign a password to
allow an unprivileged user to log in.
It is a very stripped down version of the regular RT interface. To
see what it looks like, you can manually enter
www.yoursite.tld/SelfService/index.html
Without being logged in, I’m taken to the login screen when I try to
access this url.
If you let unprivileged users log it, they are taken to SelfService.
Based on Erek’s reponse, I’m guessing I have to assign a password to
allow an unprivileged user to log in.
Yes you will need to do that, although it seems trivial given the wiki link he
provided.
It is a very stripped down version of the regular RT interface. To
see what it looks like, you can manually enter
www.yoursite.tld/SelfService/index.html
Without being logged in, I’m taken to the login screen when I try to
access this url.
Log in to the site as yourself and enter that address and you will be able to
see if the SelfService interface meets your needs at all.
If an unprivileged user logs in, they automatically get sent to SelfService, so
you really only need a link to the login page.
Thanks, the log in was the part where I was getting stuck.
One thing I’ve noticed about self-service is that the user can change
the status of a ticket. I was surprised by that. I checked the wiki but
despite finding an excellent list of all the rights, could not figure
out which one allows the user to modify the ticket status. I’m guessing
it’s the ReplyToTicket. Is that right? Am I overlooking a reason why I’d
want to let a client change the ticket status?
One thing I’ve noticed about self-service is that the user can change
the status of a ticket. I was surprised by that. I checked the wiki but
despite finding an excellent list of all the rights, could not figure
out which one allows the user to modify the ticket status. I’m guessing
it’s the ReplyToTicket. Is that right?
ModifyTicket
Michael
Michael S. Liebman m-liebman@northwestern.edu http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”