Just finished upgrade to RT 3.4.2, and all looks fine except…
When creatingor editing a ticket, and clicking open the “Owner” dropdown
list, the list shows users that are not granted rights to RT. Most are
users that I had unchecked the “Let this user be granted rights”
checkbox, and I’ve verified that this is still turned off in the
imported user list.
How can this be fixed so ony active users with rights show up as
possible ticket owners?
Thanks in advance for any suggestions.
-Alan
Alan Sparks, UNIX/Linux Systems Integration and Administration
asparks@doublesparks.net
I suspect that, at some point in the past, these users were granted
"OwnTicket" rights globally or for specific queues.
One of the bugs in RT 3.2.X (and perhaps carried over to RT 3.4.X) is
that if you give rights or group membership to a user, then uncheck the
"Let this user be granted rights" checkbox, RT does not strip that
user’s rights or group membership.
It does demote them to the SelfService interface (so they can’t log in
to the real RT interface), but they can still post to all the queues on
which they formerly had rights and open tickets by direct reference
number and lots of things. And they still appear as valid owners if they
have the “OwnTicket” right, even if you demote them to unprivileged.
So it’s vital to remove rights & group memberships before unchecking the
"Let this user be granted rights" checkbox.
Rick R.
Alan Sparks wrote:
Rick Russell said:
I suspect that, at some point in the past, these users were granted
“OwnTicket” rights globally or for specific queues.
This was an excellent hint, thanks. My predecessor basically set stuff up
for “everone” to have ownticket rights (not good), this was causing the
problem. Working on the user/group rights is making that look much
better.
One of the bugs in RT 3.2.X (and perhaps carried over to RT 3.4.X) is
that if you give rights or group membership to a user, then uncheck the
“Let this user be granted rights” checkbox, RT does not strip that
user’s rights or group membership.
Bummer. Disabling a user should suspend all rights for that user. Wonder
if that’s been filed as a bug?
-Alan
Alan Sparks, UNIX/Linux Systems Administrator asparks@doublesparks.net
One of the bugs in RT 3.2.X (and perhaps carried over to RT 3.4.X) is
that if you give rights or group membership to a user, then uncheck the
“Let this user be granted rights” checkbox, RT does not strip that
user’s rights or group membership.
Bummer. Disabling a user should suspend all rights for that user. Wonder
if that’s been filed as a bug?
Cannot reproduce in 3.4.2, disabling and removing privileges works
as expected. (though I am getting a “no connection to syslog available at
/usr/share/perl5/Log/Dispatch/Syslog.pm line 77” when trying to login as a
disabled user. The entry is logged appropriately)
(though I am getting a “no connection to syslog available at
/usr/share/perl5/Log/Dispatch/Syslog.pm line 77” when trying to login as a
disabled user. The entry is logged appropriately)
I don't know why it suddenly appeared, but the fix is in the wiki.
http://wiki.bestpractical.com/index.cgi?NoConnectionToSyslog
Jon Daley wrote:
One of the bugs in RT 3.2.X (and perhaps carried over to RT 3.4.X) is
that if you give rights or group membership to a user, then uncheck the
“Let this user be granted rights” checkbox, RT does not strip that
user’s rights or group membership.
Bummer. Disabling a user should suspend all rights for that user.
Wonder
if that’s been filed as a bug?
AFAIK this is “problem” of all(even 3.4.x, but may be it has some
“fixes”) RT versions. You can block access to RT only by disabling user.
IMO best approach is grant rights only to groups and control access by
adding/deleting users to/from groups. After you know user has rights you
want, you can use privileged status to choose WebUI(fullfeatured or self
service). If you want block user at all then disable his record.
Cannot reproduce in 3.4.2, disabling and removing privileges works
as expected. (though I am getting a “no connection to syslog available
at /usr/share/perl5/Log/Dispatch/Syslog.pm line 77” when trying to login
as a disabled user. The entry is logged appropriately)
I think “no connection to syslog” is unrelated to user status. This
error is documented on the wiki. Are you sure that you don’t get this
error in other situations?