Hi!
I’m fairly new to RT administration, although I’ve been using it in the past
a lot. We’re setting up a new version (3.8.8) and are wondering if there is
way to hide some of the ticket metadata for certain users (basically
privileged users without group membership).
The reason is that we’ve integrated it with Zimbra LDAP server and we wan’t
to offer RT as a support channel for our Zimbra users, but we don’t want to
’clutter’ their ticket display with full ticket metadata. Instead, we’d like
to just show ticket status, ticket owner and replies.
On a related note, is there a way to set default “RT at a glance” contents
for different groups? I know I can change the default one and each user can
change his/her own - what we’d like to achieve though, is that for certain
users (in a group) we’d like to setup a default RT-at-a-glance view with
predefined saved searches (like my-requested-tickets). What we’ve done so
far is that we’ve created a dashboard with those queries and this is the
only dashboard available to those groups. And we’ve added the "Dashboards"
portlet to RT-at-a-glance default layout – but this means that the users
have to click on the dashboard to get to those saved searches.
Thanks,
Miha.
Hi!
I’m fairly new to RT administration, although I’ve been using it in the past a lot. We’re
setting up a new version (3.8.8) and are wondering if there is way to hide some of the ticket
metadata for certain users (basically privileged users without group membership).
It sounds a lot like you actually want those users to be Unprivileged
and use the SelfService interface
Hi!
I’m fairly new to RT administration, although I’ve been using it in
the past a lot. We’re
setting up a new version (3.8.8) and are wondering if there is way to
hide some of the ticket
metadata for certain users (basically privileged users without group
membership).
It sounds a lot like you actually want those users to be Unprivileged
and use the SelfService interface
At first, I configured ExternalAuth to create unprivileged users, but I was
unable to add them to groups. Because I have one ldap for authenticating
all of the users. And I wanted some users (staff) to have more rights than
the rest.
I believe that SelfService would be enough for those users. I’ll remove the
users from RT and reconfigure ExternalAuth again to see exactly what is
going on… and I’ll report back.
Thanks,
Miha.
> Â Â Hi!
>
> Â Â I'm fairly new to RT administration, although I've been using it in the past a lot.
We're
> Â Â setting up a new version (3.8.8) and are wondering if there is way to hide some of the
ticket
> Â Â metadata for certain users (basically privileged users without group membership).
It sounds a lot like you actually want those users to be Unprivileged
and use the SelfService interface
At first, I configured ExternalAuth to create unprivileged users, but I was unable to add them
to groups. Because I have one ldap for authenticating all of the users. And I wanted some
users (staff) to have more rights than the rest.
Sounds like you wanted to make those few users Privileged by searching
for them and editing their User records in the UI. You can then put them
in a group and leave the rest Unprivileged.
-kevin
At first, I configured ExternalAuth to create unprivileged users, but
I was unable to add them
to groups. Because I have one ldap for authenticating all of the
users. And I wanted some
users (staff) to have more rights than the rest.
Sounds like you wanted to make those few users Privileged by searching
for them and editing their User records in the UI. You can then put them
in a group and leave the rest Unprivileged.
Kevin, all is good. I reconfigured RT ExternalAuth to create Unprivileged
users by default and SelfService interface is what seems to work for now.
What I was puzzled about was that the users are indeed created in the DB,
but they were not visible in the UI. I was already prepared to write back
that the users are not visible in the UI, when I tried searching for a
specific handle and UI found that user.
It is a bit unintuitive that in order to list all users (Privileged and
Unprivileged) one has to search for users with filter not matching
“someN0n$en$e” to see all of the users.
Thanks for your help,
Miha.
users are indeed created in the DB, but they were not visible in the UI. I was already
prepared to write back that the users are not visible in the UI, when I tried searching for a
specific handle and UI found that user.
It is a bit unintuitive that in order to list all users (Privileged and Unprivileged) one
has to search for users with filter not matching “someN0n$en$e” to see all of the users.
It is easy to end up with hundreds of thousands of Unprivileged user
records in a long running public RT instance. Having to search for
them tends to work a lot better.
-kevin
users are indeed created in the DB, but they were not visible in the UI.
I was already
prepared to write back that the users are not visible in the UI, when I
tried searching for a
specific handle and UI found that user.
It is a bit unintuitive that in order to list all users (Privileged and
Unprivileged) one
has to search for users with filter not matching “someN0n$en$e” to see all
of the users.
It is easy to end up with hundreds of thousands of Unprivileged user
records in a long running public RT instance. Having to search for
them tends to work a lot better.
-kevin
Personally, I’d like to see that be configurable, since in a company of
under 200, having to search for the user is a little unintuitive. I will
agree that in a public instance where users are created as tickets come in,
it’s a good idea however.
users are indeed created in the DB, but they were not visible in the UI.
I was already
prepared to write back that the users are not visible in the UI, when I
tried searching for a
specific handle and UI found that user.
It is a bit unintuitive that in order to list all users (Privileged and
Unprivileged) one
has to search for users with filter not matching “someN0n$en$e” to see all
of the users.
It is easy to end up with hundreds of thousands of Unprivileged user
records in a long running public RT instance. Having to search for
them tends to work a lot better.
-kevin
Personally, I’d like to see that be configurable, since in a company of
under 200, having to search for the user is a little unintuitive. I will
agree that in a public instance where users are created as tickets come in,
it’s a good idea however.
I’d consider a patch that adds a config option, assuming it was
accompanied by proper docs.
-kevin
users are indeed created in the DB, but they were not visible in the
UI.
I was already
prepared to write back that the users are not visible in the UI, when I
tried searching for a
specific handle and UI found that user.
It is a bit unintuitive that in order to list all users (Privileged
and
Unprivileged) one
has to search for users with filter not matching “someN0n$en$e” to see
all
of the users.
It is easy to end up with hundreds of thousands of Unprivileged user
records in a long running public RT instance. Having to search for
them tends to work a lot better.
-kevin
Personally, I’d like to see that be configurable, since in a company of
under 200, having to search for the user is a little unintuitive. I will
agree that in a public instance where users are created as tickets come in,
it’s a good idea however.
I’d consider a patch that adds a config option, assuming it was
accompanied by proper docs.
-kevin
RT Training in Washington DC, USA on Oct 25 & 26 2010
Last one this year – Learn how to get the most out of RT!
I’ll see if I can hack together a patch in the next week or two then, since
this has confused more than a few people at my site. Thanks.
Gary L. Greene, Jr.
IT Manager and CRE
Information Technology/Operations
Minerva Networks Inc.
Office: (408) 240-1239
Cell: (650) 704-6633