Thanks for your reply. I experimented with unblocking users with the privileged bit disabled, and from what I recall, this limits the number of emails that the user can see via /SelfService/.
However one thing that I am concerned about is that by unblocking users, they re-gain their ownership of old tickets and also have AdminCC (that was manually set by another privileged user) for old tickets restored. I suspect that they can see those tickets, but I’m not sure. Part of the concern is that they will get email updates if those tickets are updated even if they can’t see them on our RT instance. This seems to occur regardless of how we set up custom group membership and how those memberships connect with privileges in our queues.
I could write an SQL query to revoke AdminCC and ownership of tickets, but am not sure if I need to also write queries to update ticket histories so that their AdminCC and ownership is recorded as being revoked at some point. I’m hoping that I won’t have to write SQL queries in order to let old, previously privileged users email our RT instance.
It seems like disallowing users to access RT is a useful feature for quickly disabling their access to our website, but has the unfortunate additional feature of blocking inbound emails. It seems like there should be two separate options for blocking site access, and inbound email access. To add to the complexity of that, I would want people who cannot access the site and who have their AdminCC status disabled to receive replies to tickets for which they are requesters.
I think that could be a complicated change, but think it would be a great feature in RT.