Re: [rt-users] Where to put crontool scripts?

[Alex Vandiver]

On Wed, 4 Jan 2017 11:13:38 -0500
Alex Hall  wrote:
> I'm considering putting them in /opt/rt4/etc, maybe in a "crontool-scripts"
> folder, but I don't know what RT upgrades might do to that.

RT upgrades won't remove any extra files you have lying around.
 - Alex

[rt-users] Self Service interface - can't download attachments for Articles or Assets

[Brett Chambers]

Hi Everyone,

 

I've configured custom fields of the type 'Upload multiple files' for Assets
and Articles.

 

If my users are Privileged, they can see and download the contents of the
'Upload multiple files' custom fields with no problems.

 

However, if my users are Unprivileged (i.e. using the Self Service
interface), they can see the attached files, however they can't download
them.

Clicking on the file links take you back to the self-service home page, and
a right click, Save Target As doesn't work either.

 

I've tried changing global permissions for Unprivileged users, the custom
fields, etc, however haven't had any success.

 

Running RT 4.2.12.

I notice that there are significant improvements to the file upload code in
RT 4.4.x, however I haven't seen anything that explicitly relates to the
above issue.

 

Has anyone else seen this behaviour or know what I'm doing wrong?

 

Cheers,

Brett

 

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

[Martin Wheldon]

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 
wrote:


Le 04/01/2017 à 15:47, Alex Hall a écrit :

On Wed, Jan 4, 2017 at 9:35 AM, Felix Defrance 
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, 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 
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 
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 

Re: [rt-users] Ticket owner in database set to "no owner shown in search results"

[Alex Hall]

While this is still a mystery, please disregard the below email. I was
reading the columns wrong and mistook the subject for the owner. The owner
is actually set properly, yet this and another ticket come up if you search
for tickets whose owner is 'nobody'. Odd, but not quite as odd as I had in
the below message.

On Wed, Jan 4, 2017 at 12:18 PM, Alex Hall  wrote:

> Hi all,
> A while ago I was asking why owners don't always show in search results. I
> just had a look at one such ticket in the database:
>
> select * from Tickets where id = 527;
>
> The "Owner" column is set to the value "no owner shown in search results".
> I don't know how it got that way, or what it means. More puzzling still, if
> I open the ticket in the web UI, the owner is correct. Yet, this ticket
> shows up if I search for tickets in the UI with "Owner='nobody'". Somehow,
> RT knows the owner, but in the Tickets table has it set to this odd value
> I've never seen. What would cause this and, more importantly, how do I stop
> it from happening?
>
> We have a script set up to make the requestor the owner automatically, but
> that's working (I got it straight from the Wiki). This means that users
> aren't manually adding themselves as owners, they're relying on the script
> to do it for them when the ticket is created. Yet, sometimes, we get a
> ticket like the one described above--no owner in the database or searches,
> but an owner when you view the actual ticket. Any thoughts as to how to fix
> this, and how RT knows the owner? Is it substituting the creator somehow?
> I'm very confused! Thanks for any suggestions.
>
> --
> Alex Hall
> Automatic Distributors, IT department
> ah...@autodist.com
>



-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com

Re: [rt-users] RT 4.4.1 and transaction isolation level on Postgres

[Václav Ovsík]

On Wed, Jan 04, 2017 at 04:50:11AM -0800, Alex Vandiver wrote:
>... 
> MySQL suffers from the exact same problem -- but, as it happens,
> both more silently and more catastrophically.  See
> https://github.com/bestpractical/rt/commit/e36364c5

Eh. I'm glad I did transition from Mysql to Postgres years ago :).

> > I can change isolation level in postgresql.conf to 'repeatable read'
> > and things are different.
> 
> I advise against doing that.  Upon inspection, RT is not prepared to
> deal with the "could not serialize access due to concurrent update"
> errors that arise from updates to rows in multiple transactions in
> Postgres' repeatable-read isolation.

OK, thanks!

> Repeatable-read is only possible in MySQL because it has a fascinating
> definition of "repeatable":
> ...
> > Should I change the default isolation level on Postgres for RT to
> > 'repeatable read'?
> 
> No.  You should try the 4.4/previewscrips-race branch, which I've just
> pushed:
> 
> https://github.com/bestpractical/rt/compare/4.4-trunk...4.4/previewscrips-race
> 
> The gory details are contained in the commits therein.

You have my respect! Wonderful job. I tried your changes on my test
instance first. The problem is solved I think.
I installed changes to production instance too.
Thanks for your time and effort!
-- 
Zito

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

[Alex Hall]

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  wrote:

>
>
> Le 04/01/2017 à 15:47, Alex Hall a écrit :
>
>
>
> On Wed, Jan 4, 2017 at 9:35 AM, Felix Defrance  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, 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  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 
>>> 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:

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

[Felix Defrance]

Le 04/01/2017 à 15:47, Alex Hall a écrit :
>
>
> On Wed, Jan 4, 2017 at 9:35 AM, Felix Defrance  > 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, 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 > > 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
>>> > 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 

[rt-users] Ticket owner in database set to "no owner shown in search results"

[Alex Hall]

Hi all,
A while ago I was asking why owners don't always show in search results. I
just had a look at one such ticket in the database:

select * from Tickets where id = 527;

The "Owner" column is set to the value "no owner shown in search results".
I don't know how it got that way, or what it means. More puzzling still, if
I open the ticket in the web UI, the owner is correct. Yet, this ticket
shows up if I search for tickets in the UI with "Owner='nobody'". Somehow,
RT knows the owner, but in the Tickets table has it set to this odd value
I've never seen. What would cause this and, more importantly, how do I stop
it from happening?

We have a script set up to make the requestor the owner automatically, but
that's working (I got it straight from the Wiki). This means that users
aren't manually adding themselves as owners, they're relying on the script
to do it for them when the ticket is created. Yet, sometimes, we get a
ticket like the one described above--no owner in the database or searches,
but an owner when you view the actual ticket. Any thoughts as to how to fix
this, and how RT knows the owner? Is it substituting the creator somehow?
I'm very confused! Thanks for any suggestions.

-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com

Re: [rt-users] Where to put crontool scripts?

[Martin Wheldon]

Hi Alex,

We drop ours in /opt/rt4/local/bin.

Martin

On 2017-01-04 16:13, Alex Hall wrote:

Hi all,
I'm just wondering if there's a conventional place to store scripts
that run crontool jobs? I've got one to notify people of old tickets,
but I'll be making more, now that this one is working. Thanks again
for all the help with that script, by the way.

I'm considering putting them in /opt/rt4/etc, maybe in a
"crontool-scripts" folder, but I don't know what RT upgrades might do
to that. Is it best to just put them somewhere completely separate,
like ~/rt-crontool-scripts, or can I keep them somewhere in the RT
directory tree? Thanks.

--

Alex Hall
Automatic Distributors, IT department
ah...@autodist.com

Re: [rt-users] Where to put crontool scripts?

[Matt Zagrabelny]

On Wed, Jan 4, 2017 at 10:13 AM, Alex Hall  wrote:
> Hi all,
> I'm just wondering if there's a conventional place to store scripts that run
> crontool jobs? I've got one to notify people of old tickets, but I'll be
> making more, now that this one is working. Thanks again for all the help
> with that script, by the way.

We just have the whole script in the crontab:

% sudo crontab -l -u rtcrontool
[...]
15 8-16 * * 1-5 /opt/rt4/bin/rt-crontool --log=warning --search
RT::Search::FromSQL --search-arg ' Queue = "Systems" AND Owner =
"Nobody" AND ( Status = "new" OR Status = "open" ) AND ( Starts IS
NULL OR Starts <= "now" ) ' --condition
RT::Condition::CreatedBusinessHoursAgo --condition-arg 4 --action
RT::Action::MailAdminCcs --transaction-type Create --transaction last
--template "Unowned Ticket"
[...]

-m

[rt-users] Where to put crontool scripts?

[Alex Hall]

Hi all,
I'm just wondering if there's a conventional place to store scripts that
run crontool jobs? I've got one to notify people of old tickets, but I'll
be making more, now that this one is working. Thanks again for all the help
with that script, by the way.

I'm considering putting them in /opt/rt4/etc, maybe in a "crontool-scripts"
folder, but I don't know what RT upgrades might do to that. Is it best to
just put them somewhere completely separate, like ~/rt-crontool-scripts, or
can I keep them somewhere in the RT directory tree? Thanks.

-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com

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

[Martin Wheldon]

Hi,

You can modify the Ticket Owner dropdowns by using the UpdateObjectList 
callback in Elements/SelectOwner,
you would remove all unwanted users from the list of objects passed to 
this callback.


You possibly need to use the Modify callback in Elements/ShowUser too, I 
suspect there are others, but those should get you started.


Best Regards

Martin

On 2017-01-04 14:35, Felix Defrance 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, 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"


On Wed, Jan 4, 2017 at 8:57 AM, Felix Defrance 
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 
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 
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
ah...@autodist.com


--
Félix Defrance
PGP: 0x0F04DC57

--

Alex 

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

[Alex Hall]

On Wed, Jan 4, 2017 at 9:35 AM, Felix Defrance  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, 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  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  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 
>>> wrote:
>>>
 Hi all,

 I don't find how I could add ShowTickets or QueueList in SelfService.

 I want to allow my unprivileged 

Re: [rt-users] How to create a new RoleGroup?

[Matt Zagrabelny]

On Wed, Jan 4, 2017 at 8:30 AM,   wrote:

> I logged into RT as an admin:
> -> Admin -> Queues -> Select Queue -> Watchers
>
> Then:
> - New Watcher ->  Find NAME -> Choose Option "AdminCc" --> Save Changes
> ERROR: Role group 'AdminCc' not found

I just ran a quick test and it works for me with 4.2.11.

> The Debug-Log says:
>
> "[7814] [Wed Jan  4 14:28:00 2017] [warning]: Use of uninitialized value in
> join or string at /usr/share/perl5/DBIx/SearchBuilder.pm line 1087, 
> line 1662. (/usr/share/perl5/DBIx/SearchBuilder.pm:1087)
> [7814] [Wed Jan  4 14:28:00 2017] [warning]: DBD::Pg::st execute failed:
> FEHLER:  Syntaxfehler bei »)«
> LINE 1: ...nt(main.id) FROM GroupMembers main  WHERE (main.GroupId = )
>  ^ at
> /usr/share/perl5/DBIx/SearchBuilder/Handle.pm line 586,  line 1662.
> (/usr/share/perl5/DBIx/SearchBuilder/Handle.pm:586)

Looking at the above SQL error it looks lie there is no main.GroupId
in the query. The formatting of the email causes the caret (^)
indicator to not point at the right error.

What would cause the GroupId to be scrubbed?

Do you have some custom JS or any Overlays or Callbacks that would interfere?

-m

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

[Felix Defrance]

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, 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"


>
> On Wed, Jan 4, 2017 at 8:57 AM, Felix Defrance  > 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 > > 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
>>> > 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
>>> 

Re: [rt-users] How to create a new RoleGroup?

[patrick . schoenenberg]

Hello,

 


> What version were you running?

4.0.18

 

> What version did you upgrade to?
4.2.18


>> Error Message: In german "Rollen Gruppe 'AdminCc' nicht gefunden"
>> In English something like "Role Group 'AdminCc' not found"

> What actions did you take to generate this error? Please be specific.

 

I logged into RT as an admin:
-> Admin -> Queues -> Select Queue -> Watchers


Then:

- New Watcher ->  Find NAME -> Choose Option "AdminCc" --> Save Changes
ERROR: Role group 'AdminCc' not found

 

The Debug-Log says:

"[7814] [Wed Jan  4 14:28:00 2017] [warning]: Use of uninitialized value in join or string at /usr/share/perl5/DBIx/SearchBuilder.pm line 1087,  line 1662. (/usr/share/perl5/DBIx/SearchBuilder.pm:1087)
[7814] [Wed Jan  4 14:28:00 2017] [warning]: DBD::Pg::st execute failed: FEHLER:  Syntaxfehler bei »)«
LINE 1: ...nt(main.id) FROM GroupMembers main  WHERE (main.GroupId = )
 ^ at /usr/share/perl5/DBIx/SearchBuilder/Handle.pm line 586,  line 1662. (/usr/share/perl5/DBIx/SearchBuilder/Handle.pm:586)

Greetings,
Patrick


 

Re: [rt-users] How to create a new RoleGroup?

[Matt Zagrabelny]

Hi Patrick,

On Wed, Jan 4, 2017 at 8:00 AM,   wrote:
>
> Hello,
>
> after an RT-Upgrade I am not able to add Watchers to on Queue.

What version were you running?

What version did you upgrade to?

> Error Message:  In german "Rollen Gruppe 'AdminCc' nicht gefunden"
> In English something like "Role Group 'AdminCc' not found"

What actions did you take to generate this error? Please be specific.

Thanks!

-m

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

[Alex Hall]

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?

On Wed, Jan 4, 2017 at 8:57 AM, Felix Defrance  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  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 
>> 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
>> ah...@autodist.com
>>
>>
>> --
>> Félix Defrance
>> PGP: 0x0F04DC57
>>
>>
>
>
> --
> Alex Hall
> Automatic Distributors, IT department
> ah...@autodist.com
>
>
> --
> Félix Defrance
> PGP: 0x0F04DC57
>
>


-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com

[rt-users] How to create a new RoleGroup?

[patrick . schoenenberg]

Hello,
 
after an RT-Upgrade I am not able to add Watchers to on Queue.
 
Error Message:  In german "Rollen Gruppe 'AdminCc' nicht gefunden"
In English something like "Role Group 'AdminCc' not found"
 
How can I create a new RoleGroup?


Thanks in advance
 
Patrick 
 

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

[Felix Defrance]

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  > 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
>> > 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
>> ah...@autodist.com 
>
> -- 
> Félix Defrance
> PGP: 0x0F04DC57
>
>
>
>
> -- 
> Alex Hall
> Automatic Distributors, IT department
> ah...@autodist.com 

-- 
Félix Defrance
PGP: 0x0F04DC57

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

[Alex Hall]

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.

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  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  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
> ah...@autodist.com
>
>
> --
> Félix Defrance
> PGP: 0x0F04DC57
>
>


-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com

Re: [rt-users] RT 4.4.1 and transaction isolation level on Postgres

[Alex Vandiver]

On Tue, 3 Jan 2017 17:06:47 +0100
Václav Ovsík  wrote:
> How about the Mysql don't have this problem - is this caused by
> the different default transaction isolation level or not?

MySQL suffers from the exact same problem -- but, as it happens,
both more silently and more catastrophically.  See
https://github.com/bestpractical/rt/commit/e36364c5

> I can change isolation level in postgresql.conf to 'repeatable read'
> and things are different.

I advise against doing that.  Upon inspection, RT is not prepared to
deal with the "could not serialize access due to concurrent update"
errors that arise from updates to rows in multiple transactions in
Postgres' repeatable-read isolation.

Repeatable-read is only possible in MySQL because it has a fascinating
definition of "repeatable":

- Process 1 
mysql> set transaction isolation level repeatable read;
Query OK, 0 rows affected (0.00 sec)

mysql> start transaction with consistent snapshot;
Query OK, 0 rows affected (0.00 sec)

mysql> select id, Subject from Tickets where id = 1;
++-+
| id | Subject |
++-+
|  1 | foo |
++-+
1 row in set (0.00 sec)

- Process 2 

mysql> set transaction isolation level repeatable read;
Query OK, 0 rows affected (0.00 sec)

mysql> start transaction with consistent snapshot;
Query OK, 0 rows affected (0.00 sec)

mysql> update Tickets set Subject = 'bar' where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

- Process 1 

mysql> select id, Subject from Tickets where id = 1;
++-+
| id | Subject |
++-+
|  1 | foo |
++-+
1 row in set (0.00 sec)

mysql> select id, Subject from Tickets where id = 1 FOR UPDATE;
++-+
| id | Subject |
++-+
|  1 | bar |
++-+
1 row in set (0.00 sec)



Contrast this with PostgreSQL, whose definition of repeatable read
acknowledges that fully consistent updates are not possible in all
cases:

- Process 1 
rt4=# start transaction;
START TRANSACTION
rt4=# set transaction isolation level repeatable read;
SET
rt4=# select id, Subject from Tickets where id = 1;
 id | subject 
+-
  1 | foo
(1 row)

- Process 2 
rt4=# start transaction;
START TRANSACTION
rt4=# set transaction isolation level repeatable read;
SET
rt4=# update Tickets set Subject = 'bar' where id = 1;
UPDATE 1
rt4=# commit;
COMMIT

- Process 1 
rt4=# select id, Subject from Tickets where id = 1;
 id | subject 
+-
  1 | foo
(1 row)

rt4=# select id, Subject from Tickets where id = 1 FOR UPDATE;
ERROR:  could not serialize access due to concurrent update



 ( Yes, MySQL requires SET TRANSACTION ISOLATION _outside_ the
   transaction, and PostgreSQL requires it to be _inside_.  See 
   https://dev.mysql.com/doc/refman/5.7/en/set-transaction.html
   https://www.postgresql.org/docs/9.1/static/sql-set-transaction.html )


> Should I change the default isolation level on Postgres for RT to
> 'repeatable read'?

No.  You should try the 4.4/previewscrips-race branch, which I've just
pushed:

https://github.com/bestpractical/rt/compare/4.4-trunk...4.4/previewscrips-race

The gory details are contained in the commits therein.
 - Alex

[rt-users] Authentication-Problems after Upgrading

[patrick . schoenenberg]

Hello,


I have upgraded our RT-Database und RT-Installation the 4th time in the last 10 years.

 

Unfortunatly I run at the last update into problems.

I upgraded from 4.0.19 to 4.2.8

 

Everything seems to be fine - but when I logged in with an privileged User, I have

only access to the self-service-interface. Also the Admin User

 

I can access to tickets (that are not mine) via the search field.
(Or via the list my tickets)

 

But I am not able to manage tickets.

 

Does anyone have an idea?

 

Thanks

Patrick

 

 

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

[Felix Defrance]

Hi Manu,

Thanks for your answer ;)

I have tried to modify MyRequests in an overlay, yesterday, but my perl
coding is quite bad as you known ;)

Nevermind, I try to imagine use CC instead of modifing the hard coded
things, but in this goal, I'll need to define watchers automatically.

For example, I'll need to add "user group" called foobar to all existing
tickets in queue foobar and the futurs created tickets in it!

The question is, is it possible ?

In the other hand, I don't know whyone queue per customer is not a good
workflow.

Thanks,

Félix.

Le 04/01/2017 à 09:45, Emmanuel Lacour a écrit :
> Le 03/01/2017 à 18:27, Felix Defrance a écrit :
>>
>> 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?
>>
>
> SelfService filters ticket list to tickets the user is watcher on
> (requestor or Cc). This is hard coded in
> share/html/SelfService/Elements/MyRequests:
>
> my $id = $session{'CurrentUser'}->id;
> my $Query = "( Watcher.id = $id )";
>
> if ($status) {
> $status =~ s/(['\\])/\\$1/g;
> $Query .= " AND Status = '$status'";
> }
>
>
> so if you wan't to relax this to all tickets users have ShowTicket
> rights, you have to modify this query ;)
>
> But I strongly discourage (unless really needed) to setup an RT
> instance with one queue per customer, best to think queues per
> internal support team and play with customroles/groups or customfields
> to set the customer.

-- 
Félix Defrance
PGP: 0x0F04DC57

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

[Felix Defrance]

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  > 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
> ah...@autodist.com 

-- 
Félix Defrance
PGP: 0x0F04DC57

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

[Emmanuel Lacour]

Le 03/01/2017 à 18:27, Felix Defrance a écrit :
>
> 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?
>

SelfService filters ticket list to tickets the user is watcher on
(requestor or Cc). This is hard coded in
share/html/SelfService/Elements/MyRequests:

my $id = $session{'CurrentUser'}->id;
my $Query = "( Watcher.id = $id )";

if ($status) {
$status =~ s/(['\\])/\\$1/g;
$Query .= " AND Status = '$status'";
}


so if you wan't to relax this to all tickets users have ShowTicket
rights, you have to modify this query ;)

But I strongly discourage (unless really needed) to setup an RT instance
with one queue per customer, best to think queues per internal support
team and play with customroles/groups or customfields to set the customer.