Hello,
Sorry if this is documented somewhere, but I haven't been able to locate it.
I am running an RT 4.0.8 system with a few privileged Administrators and a few
hundred unprivileged users who log into an RT SelfService interface to
communicate (as well as by rt-mail) for support purposes.
One of the Admins has requested access to the contents of a queue be given to a
small group of unprivileged users. The most obvious way is to use a query to
generate an RSS feed. So far so good. However, we may want to restrict access
of the feed to a select few people in the organization. One way is to keep the
feed URL confidential. This might work, but I was wondering is there is
anything more robust than security-through-secrecy. Also I cannot find any way
to manage the RSS feeds such as deleting or shutting it down when it has
outlived its usefulness. Can anyone suggest where I can find this out.
Another related topic is the "Go to Ticket ..." box where unprivileged users
using the SelfServe interface can type in any ticket IDnumber and access the
entire ticket. I can see how useful this is, but I'm wondering how to restrict
access to this practice in the case where each tickets is to be considered
confidential/privileged between each staff member and the support
Administrators. So far, there is no issue of confidentiality in our
organization, but it may come to the attention of management that naiive staff
or even people who should know better and show lack of judgement by disclosing
passwords, access codes or confidential information in their support requests
that may be read or mined by others without privilege to this information.
Again, we are not a super-secret organization, but I would not want to be in a
situation where one unprivileged RT user has divulged confidential information
to another unprivileged RT user who has been able to mine the RT SelfService
page or a forgotten RSS feed for information. We have a policy right now that
no confidential information or passwords/codes etc be included in tickets, but
people are very fallible and any advice to target access a little better would
be appreciated!
Duncan.