[rt-users] How unprivileged users could see all tickets in their queue?
Felix Defrance
felix at d2france.fr
Thu Jan 5 04:55:49 EST 2017
Thanks for your answers.
Before work on overlay to custom my rt setup, i have a question.
Privileged users have a rights to search in all RT database. But in my
setup, some users are customers and they are grouping in RT groups
called by their compagny name.
On the queues (called by compagny name too), the rights are applied by
using groups.
So, why they are able to search in all queues. I supposed they are
restricted to search just on their queue.
Thus, is it a mistake in my setup or RT have a security issue ? Is it
possible to limit the search instead of hide the search menu ?
Thanks,
Félix
Le 04/01/2017 à 21:53, Martin Wheldon a écrit :
> Hi,
>
> If you are looking at modifying menus then the following will help.
>
>
> https://docs.bestpractical.com/rt/4.4.1/writing_extensions.html#Adding-and-Modifying-Menus
>
> Best Regards
>
> Martin
>
> On 2017-01-04 17:31, Alex Hall wrote:
>> I'm honestly not sure which file you want, but my guess is
>> share/html/Elements/Tabs. In that file is a line that goes something
>> like:
>>
>> $search->child( users ...
>>
>> If you wrap that bit in a conditional, checking that the active user
>> is not a member of the group as I said in a previous message, that
>> should do the job.
>>
>> On Wed, Jan 4, 2017 at 12:21 PM, Felix Defrance <felix at d2france.fr>
>> wrote:
>>
>>> Le 04/01/2017 à 15:47, Alex Hall a écrit :
>>>
>>> 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. :)
>>
>> Do you know if the menu search come from :
>> rt/share/html/Dashboards/Elements/* ? Or from another file ?
>>
>> I don't find documentation about these files and what are they doing
>> :(
>>
>> Thanks
>>
>>> 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
>>
>> --
>> Félix Defrance
>> PGP: 0x0F04DC57
>>
>> --
>>
>> Alex Hall
>> Automatic Distributors, IT department
>> ahall at autodist.com
--
Félix Defrance
PGP: 0x0F04DC57
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20170105/53924fcd/attachment.htm>
More information about the rt-users
mailing list