[rt-users] How unprivileged users could see all tickets in their queue?

Alex Hall ahall at autodist.com
Wed Jan 4 09:47:49 EST 2017


On Wed, Jan 4, 2017 at 9:35 AM, Felix Defrance <felix at d2france.fr> wrote:

>
> Le 04/01/2017 à 15:10, Alex Hall a écrit :
>
> Okay, searching users is the problem? I'm not sure, but what about an
> overlay that conditionally shows that part of page templates? You could
> create a group to which you'd assign any user you don't want viewing other
> users, then find the element that displays the user search and add a
> condition to return nothing if the user belongs to that group?
>
> Yes, this is a part of the problem. The second, but not important, it's
> just for the look&feel, the ability to custom "Rt at a glance" by user
> groups.
>
> For the first, I don't known how I can do " then find the element that
> displays the user search and add a condition to return nothing if the user
> belongs to that group"
>
> In one template, I was able to find this snippet to get the user object:
my $user = $session{'CurrentUser'}->UserObj;

>From there, I imagine you could check if the user is a member of a certain
group. Then "return 0" or something like that to stop the element from
loading. My Perl skills aren't worthy of being called skills in any way,
and I've never tried something quite like this, but it's my first thought.
Sorry I can't help more; hopefully a more experienced user has a much
simpler solution for you. :)

>
>
> On Wed, Jan 4, 2017 at 8:57 AM, Felix Defrance <felix at d2france.fr> wrote:
>
>>
>> Le 04/01/2017 à 14:02, Alex Hall a écrit :
>>
>> Can you describe your setup more? I'm not sure why unprivileged users
>> would need access to all queue tickets, or why each user would have their
>> own queue? As I understand it, unprivileged users are end users (i.e.
>> customers, those who don't work for your organization). Thus, they
>> shouldn't be able to access an entire queue, only tickets they open. Make
>> them privileged, and restrict their rights by adding them to a certain
>> group, and your life may be a lot easier.
>>
>> Yes! In the begining, that's what I tried to do. Restrict privilieged
>> users. But I didn't find how restrict the access to the SearchUser.
>>
>> A member of a queue can search and view all users.
>>
>> In my setup, a queue and group, are dedicated to a customer.
>>
>> A customer should not be able to fetch other informations that are not
>> inside of their queue. Thus, not be able to search all user in RT database..
>>
>> Maybe, it's possible to limit the search function to their queue or
>> desactivate the access to the menu search. Do you know about that ?
>>
>> Thanks,
>>
>>
>> For example, you might have a group called "basic users" to which you'd
>> add the users you currently consider unprivileged. That group would have
>> only a few rights, but since its members would be privileged, you wouldn't
>> run into RT's built-in restrictions.
>>
>> As to one queue per user, that would quickly get hard to manage. Queues
>> are for organizing tickets and users. Sure, a queue may have just one user,
>> but each user shouldn't have their own queue. Trying to keep track of the
>> rights of such a setup would be a nightmare, assuming you have a good
>> amount of users. As an example, we have queues for technology, warehouse,
>> customer service, and other divisions within the company. Some queues have
>> a lot of people, some have a few, butthey are all logical groupings of
>> tasks. If I made a new queue for every user, I'd have dozens of them, and
>> tickets would be all over the place! Plus, there's email to consider; if
>> you want to accept incoming emails for ticket replies, you have to make a
>> new Fetchmail or Postfix entry for every single user/queue you have.
>>
>> I hope this makes some sense. As I said, a lot of this depends on your
>> usage pattern and setup concept. If you can explain that to us more, we
>> might be able to help better.
>>
>> On Wed, Jan 4, 2017 at 3:57 AM, Felix Defrance <felix at d2france.fr> wrote:
>>
>>> Hello,
>>>
>>> You right, this rights isn't checked.
>>>
>>> But I can't view all tickets in selfservice anymore.
>>>
>>> I verify the same rights in :
>>>
>>>  Admin > Queue, "select the queue name" and  Group Rights, select and
>>> grant "unprivileged users" to Seequeue & Showtickets
>>>
>>> In the same section:
>>>
>>>  grant group "compagny name" to Seequeue & Showtickets
>>>
>>>
>>> But no effect.
>>>
>>> I try to add a user to watchers 'CC', and grant watchers 'CC' to Seequeue
>>> & Showtickets but no effect too :(
>>>
>>> Another ideas ?
>>>
>>> Thanks,
>>>
>>> Félix.
>>> Le 03/01/2017 à 18:39, Alex Hall a écrit :
>>>
>>> Have you granted the rights? In Admin > Global > Group Rights, select
>>> the "unprivileged users" tab, then grant "view queue". That should help,
>>> though our setup is quite different so I can't verify it.
>>>
>>> On Tue, Jan 3, 2017 at 12:27 PM, Felix Defrance <felix at d2france.fr>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I don't find how I could add ShowTickets or QueueList in SelfService.
>>>>
>>>> I want to allow my unprivileged users, grouped by company name, to see
>>>> all tickets in their queue.
>>>>
>>>> The group rights on the queue is correctly defined and users could
>>>> access to the tickets by entring the ticket number in the "goto Ticket"
>>>> field (top right in SelfService).
>>>>
>>>> I have tried to play with CustomRole but it's not working for me. So
>>>> anybody known how I can do it?
>>>> Thank you,
>>>>
>>>> --
>>>> Félix Defrance
>>>> PGP: 0x0F04DC57
>>>>
>>>>
>>>
>>>
>>> --
>>> Alex Hall
>>> Automatic Distributors, IT department
>>> ahall at autodist.com
>>>
>>>
>>> --
>>> Félix Defrance
>>> PGP: 0x0F04DC57
>>>
>>>
>>
>>
>> --
>> Alex Hall
>> Automatic Distributors, IT department
>> ahall at autodist.com
>>
>>
>> --
>> Félix Defrance
>> PGP: 0x0F04DC57
>>
>>
>
>
> --
> Alex Hall
> Automatic Distributors, IT department
> ahall at autodist.com
>
>
> --
> Félix Defrance
> PGP: 0x0F04DC57
>
>


-- 
Alex Hall
Automatic Distributors, IT department
ahall at autodist.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20170104/7f4659b6/attachment.htm>


More information about the rt-users mailing list