date:20170117

Re: [rt-users] Limiting rt-crontool notifications to every n days?

2017-01-17 Thread Matt Zagrabelny

On Tue, Jan 17, 2017 at 1:24 PM, Alex Hall  wrote:
>  Did your JSON-like syntax for
> updating fields ever make it into core for 4.4.1?

Not yet.

-m

Re: [rt-users] Limiting rt-crontool notifications to every n days?

2017-01-17 Thread Matt Zagrabelny

Just download the .bin and move it into
/opt/rt4/lib/RT/Action/ModifyCustomField.pm

-m

On Tue, Jan 17, 2017 at 1:24 PM, Alex Hall  wrote:
> Thank you, that looks like it'll work. Did your JSON-like syntax for
> updating fields ever make it into core for 4.4.1? I found the attachment in
> your linked message, but it's a bin file and I'm not sure what to do with
> it.
>
> On Tue, Jan 17, 2017 at 11:17 AM, Matt Zagrabelny 
> wrote:
>>
>> Hey Alex,
>>
>> On Mon, Jan 16, 2017 at 8:18 AM, Alex Hall  wrote:
>> > Hi all,
>> > RT is sending out notifications for old tickets just like we want it to.
>> > If
>> > a ticket hasn't been updated in seven days and the status is open or
>> > new,
>> > the owner gets an email every weekday until the ticket is updated. What
>> > I'd
>> > like to do, though, is have a way of changing that "every weekday" bit
>> > for
>> > stalled tickets.
>> >
>> > Instead of warning users every weekday about tickets that are stalled
>> > and
>> > haven't been touched in a while, I'd like to warn them once or twice a
>> > week.
>> > I can't run the cron job that seldom, though, or a ticket could go days
>> > longer than it should without being picked up. Is there any way to only
>> > send
>> > an email to a user if the system has not emailed them in N days? I could
>> > add
>> > a column to the Tickets table for this, or add a new table, but I always
>> > like to stay clear of database schema modifications if I can. Besides, I
>> > don't know how to interface with a custom table using RT SQL.
>>
>> I wouldn't alter the schema.
>>
>> > Is there any way of doing this?
>>
>> You could use a custom field. Something like "Last Email Notification
>> Sent At" or something equally verbose. ;)
>>
>> Then add that CF to your query about which tickets need to get email
>> notifications.
>>
>> We do essentially what you are asking about. We leverage two things:
>>
>> 1. rt-crontool can take multiple --action arguments
>> 2. A custom (but it could be "cored") scrip action. The scrip action
>> is ModifyCustomField. Here is a link to it:
>>
>>
>> http://lists.bestpractical.com/pipermail/rt-devel/2016-December/012601.html
>>
>> Here is one of our cron jobs that keeps track of when it sent an email
>> and also sends the email:
>>
>> 0 12 * * * /opt/rt4/bin/rt-crontool --log=warning --search
>> RT::Search::FromSQL --search-arg ' Queue = "Access Requests" AND
>> Status = "activated" AND ( ( "CF.{Renewal Verified At}" IS NULL AND
>> Created <= "1 year ago" ) OR ( "CF.{Renewal Verified At}" IS NOT NULL
>> AND "CF.{Renewal Verified At}" <= "1 year ago" ) ) AND ( "CF.{Renewal
>> Verification Sent At}" IS NULL OR "CF.{Renewal Verification Sent At}"
>> <= "20 days ago" ) ' --transaction-type Create --transaction last
>> --template "Access Request Renewal Verification" --action
>> RT::Action::MailRequestors --action-arg "" --action
>> RT::Action::ModifyCustomField --action-arg '{ "name": "Renewal
>> Verification Sent At", "operation": "set", "value": "now" }'
>>
>> -m
>
>
>
>
> --
> Alex Hall
> Automatic Distributors, IT department
> ah...@autodist.com

Re: [rt-users] Limiting rt-crontool notifications to every n days?

2017-01-17 Thread Alex Hall

Thank you, that looks like it'll work. Did your JSON-like syntax for
updating fields ever make it into core for 4.4.1? I found the attachment in
your linked message, but it's a bin file and I'm not sure what to do with
it.

On Tue, Jan 17, 2017 at 11:17 AM, Matt Zagrabelny 
wrote:

> Hey Alex,
>
> On Mon, Jan 16, 2017 at 8:18 AM, Alex Hall  wrote:
> > Hi all,
> > RT is sending out notifications for old tickets just like we want it to.
> If
> > a ticket hasn't been updated in seven days and the status is open or new,
> > the owner gets an email every weekday until the ticket is updated. What
> I'd
> > like to do, though, is have a way of changing that "every weekday" bit
> for
> > stalled tickets.
> >
> > Instead of warning users every weekday about tickets that are stalled and
> > haven't been touched in a while, I'd like to warn them once or twice a
> week.
> > I can't run the cron job that seldom, though, or a ticket could go days
> > longer than it should without being picked up. Is there any way to only
> send
> > an email to a user if the system has not emailed them in N days? I could
> add
> > a column to the Tickets table for this, or add a new table, but I always
> > like to stay clear of database schema modifications if I can. Besides, I
> > don't know how to interface with a custom table using RT SQL.
>
> I wouldn't alter the schema.
>
> > Is there any way of doing this?
>
> You could use a custom field. Something like "Last Email Notification
> Sent At" or something equally verbose. ;)
>
> Then add that CF to your query about which tickets need to get email
> notifications.
>
> We do essentially what you are asking about. We leverage two things:
>
> 1. rt-crontool can take multiple --action arguments
> 2. A custom (but it could be "cored") scrip action. The scrip action
> is ModifyCustomField. Here is a link to it:
>
> http://lists.bestpractical.com/pipermail/rt-devel/2016-
> December/012601.html
>
> Here is one of our cron jobs that keeps track of when it sent an email
> and also sends the email:
>
> 0 12 * * * /opt/rt4/bin/rt-crontool --log=warning --search
> RT::Search::FromSQL --search-arg ' Queue = "Access Requests" AND
> Status = "activated" AND ( ( "CF.{Renewal Verified At}" IS NULL AND
> Created <= "1 year ago" ) OR ( "CF.{Renewal Verified At}" IS NOT NULL
> AND "CF.{Renewal Verified At}" <= "1 year ago" ) ) AND ( "CF.{Renewal
> Verification Sent At}" IS NULL OR "CF.{Renewal Verification Sent At}"
> <= "20 days ago" ) ' --transaction-type Create --transaction last
> --template "Access Request Renewal Verification" --action
> RT::Action::MailRequestors --action-arg "" --action
> RT::Action::ModifyCustomField --action-arg '{ "name": "Renewal
> Verification Sent At", "operation": "set", "value": "now" }'
>
> -m
>



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

Re: [rt-users] When replying to a new ticket a new ticket get created

2017-01-17 Thread Martin Petersson

Well i have looked at the rights. I have created a group called support and 
gave all the necessary access and for the group All in general rights i gave 
them access to everything, comment, register new tickets, create tickets and so 
on.

Really strange, anyone have any more ideas?

Martin Petersson
IT-Konsult

+46 (0)522 980 28, mar...@uanet.se, 
www.uanet.se
Gustaf Mattssons Väg 2, 451 50 Uddevalla, Orgnr: 556702-4095

[cid:A93F8E95-F3FC-464A-AF04-402618F91147@uanet.local]

16 jan. 2017 kl. 16:03 skrev Alex Hall 
>:

That looks fine to me, though I'm no expert. I definitely don't see anything 
that would cause email replies to turn into new tickets. My only other idea is 
a rights problem, but I don't know RT well enough to know if it's even possible.

My thought is that the users emailing replies don't have permission to comment 
or correspond on the tickets in question, so RT is making new tickets instead. 
But again, I don't know RT enough to say whether it would do that or not. It's 
just a thought. Still, it might be worth checking the rights, unless and until 
someone with more experience can help.

On Mon, Jan 16, 2017 at 9:25 AM, Martin Petersson 
> wrote:
Yes here it is:
I have no files in RT_SiteConfig.d/

#
# To include a directive here, just copy the equivalent statement
# from RT_Config.pm and change the value. We've included a single
# sample value below.
#
# If this file includes non-ASCII characters, it must be encoded in
# UTF-8.
#
# This file is actually a perl module, so you can include valid
# perl code, as well.
#
# The converse is also true, if this file isn't valid perl, you're
# going to run into trouble. To check your SiteConfig file, use
# this command:
#
#   perl -c /path/to/your/etc/RT_SiteConfig.pm
#
# You must restart your webserver after making changes to this file.
#

# You may also split settings into separate files under the etc/RT_SiteConfig.d/
# directory.  All files ending in ".pm" will be parsed, in alphabetical order,
# after this file is loaded.

Set( $rtname, 'uanet.se');
Set( $Organization, 'uanet.se');
Set( $Timezone, 'Europe/Stockholm');
Set( $WebDomain, 'help.uanet.se');
Set( $WebPort, 443);
Set( $WebPath, '');
Set( $DatabasePassword, ’secret');
Set($CorrespondAddress , ’supp...@uanet.se');
Set($CommentAddress , 
'support-comm...@uanet.se');
Set(@ReferrerWhitelist, qw(helpdesk.uanet.se:443 
 helpdesk.uanet.se:80));
# You must install Plugins on your own, this is only an example
# of the correct syntax to use when activating them:
# Plugin( "RT::Authen::ExternalAuth" );
#Plugin('RT::Extension::SLA');
#Plugin('RT::Extension::CommandByMail');
#Set(@MailPlugins, qw(Auth::MailFrom Action::CommandByMail));
1;

Martin Petersson
IT-Konsult

+46 (0)522 980 28, mar...@uanet.se, 
www.uanet.se
Gustaf Mattssons Väg 2, 451 50 Uddevalla, Orgnr: 556702-4095

16 jan. 2017 kl. 15:19 skrev Alex Hall 
>:

Yes, the regexp would be in there if you've modified it. Can you just post your 
entire RT_SiteConfig.pm file (or files if you're using files inside 
RT_SiteConfig.d)? That might be the best way for us to see what you're working 
with.

On Mon, Jan 16, 2017 at 9:14 AM, Martin Petersson 
> wrote:
Hello,

Thank you for your answer.
Should $EmailSubjectTagRegex be in RT_SiteConfig.pm?

I have renamed the RT site, could that cause anything?

Martin Petersson
IT-Konsult

+46 (0)522 980 28, mar...@uanet.se, 
www.uanet.se
Gustaf Mattssons Väg 2, 451 50 Uddevalla, Orgnr: 556702-4095

16 jan. 2017 kl. 15:00 skrev Alex Hall 
>:

My first thought is that you've modified your $EmailSubjectTagRegex setting. If 
you have, there may be a mistake in that which is causing a problem. If you 
have changed it, can you give us its current value? Or disable the change and 
see if replies start working correctly, then debug the regexp?

On Sat, Jan 14, 2017 at 5:10 PM, Martin Petersson 
> wrote:
Hello,

Somehow i get the auto reply ticket that the customer receive.
And then when i reply to the ticket it creates a new ticket, whats wrong?

I have Ubuntu latest OS and RT 4.4.1

Martin Petersson
IT-Konsult

+46 (0)522 980 28, mar...@uanet.se, 
www.uanet.se
Gustaf Mattssons Väg 2, 451 50 Uddevalla, Orgnr: 556702-4095

Re: [rt-users] Limiting rt-crontool notifications to every n days?

2017-01-17 Thread Matt Zagrabelny

Hey Alex,

On Mon, Jan 16, 2017 at 8:18 AM, Alex Hall  wrote:
> Hi all,
> RT is sending out notifications for old tickets just like we want it to. If
> a ticket hasn't been updated in seven days and the status is open or new,
> the owner gets an email every weekday until the ticket is updated. What I'd
> like to do, though, is have a way of changing that "every weekday" bit for
> stalled tickets.
>
> Instead of warning users every weekday about tickets that are stalled and
> haven't been touched in a while, I'd like to warn them once or twice a week.
> I can't run the cron job that seldom, though, or a ticket could go days
> longer than it should without being picked up. Is there any way to only send
> an email to a user if the system has not emailed them in N days? I could add
> a column to the Tickets table for this, or add a new table, but I always
> like to stay clear of database schema modifications if I can. Besides, I
> don't know how to interface with a custom table using RT SQL.

I wouldn't alter the schema.

> Is there any way of doing this?

You could use a custom field. Something like "Last Email Notification
Sent At" or something equally verbose. ;)

Then add that CF to your query about which tickets need to get email
notifications.

We do essentially what you are asking about. We leverage two things:

1. rt-crontool can take multiple --action arguments
2. A custom (but it could be "cored") scrip action. The scrip action
is ModifyCustomField. Here is a link to it:

http://lists.bestpractical.com/pipermail/rt-devel/2016-December/012601.html

Here is one of our cron jobs that keeps track of when it sent an email
and also sends the email:

0 12 * * * /opt/rt4/bin/rt-crontool --log=warning --search
RT::Search::FromSQL --search-arg ' Queue = "Access Requests" AND
Status = "activated" AND ( ( "CF.{Renewal Verified At}" IS NULL AND
Created <= "1 year ago" ) OR ( "CF.{Renewal Verified At}" IS NOT NULL
AND "CF.{Renewal Verified At}" <= "1 year ago" ) ) AND ( "CF.{Renewal
Verification Sent At}" IS NULL OR "CF.{Renewal Verification Sent At}"
<= "20 days ago" ) ' --transaction-type Create --transaction last
--template "Access Request Renewal Verification" --action
RT::Action::MailRequestors --action-arg "" --action
RT::Action::ModifyCustomField --action-arg '{ "name": "Renewal
Verification Sent At", "operation": "set", "value": "now" }'

-m

[rt-users] REST-API crashes on history of long ticket with long format

2017-01-17 Thread Sinapius, Vinzenz

Hi everyone,

I have a ticket with a long history and many merges, but it shows fine under 
/rt/Ticket/History.html?id=$ID. RT also gives me its history without problems 
when I use the REST-API with the short format /rt/REST/1.0/ticket/$ID/history ->

RT/4.2.12 200 Ok

# 642/642 (/total)

[...]

But when I use the long format /rt/REST/1.0/ticket/$ID/history?format=l the CPU 
usage on my RT process spikes and becomes unresponsive. Which leads to 
supervisord restarting the process after a while.

Were on RT 4.2.12 and our stack is nginx -> nginx -> supervisord -> 
rt-server.fcgi -> postgresql

It looks like a bug in RT to me, or could it be some misconfiguration on my 
part?

Cheers,
Vinzenz
Vinzenz Sinapius
Information Technology | Informationstechnik

tracetronic GmbH
Stuttgarter Str. 3
01189 DRESDEN
GERMANY

Phone: +49 351 205768-167
Fax: +49 351 205768-999
E-mail: vinzenz.sinap...@tracetronic.de

Head Office | Hauptsitz: Stuttgarter Str. 3, 01189 DRESDEN, GERMANY
Managing Directors | Geschäftsführer: Dr.-Ing. Rocco Deutschmann, Dr.-Ing. 
Peter Strähle
Registration Court | Registergericht: Amtsgericht Dresden, HRB 23 086

Re: [rt-users] Limiting rt-crontool notifications to every n days?

Re: [rt-users] Limiting rt-crontool notifications to every n days?

Re: [rt-users] Limiting rt-crontool notifications to every n days?

Re: [rt-users] When replying to a new ticket a new ticket get created

Re: [rt-users] Limiting rt-crontool notifications to every n days?

[rt-users] REST-API crashes on history of long ticket with long format

6 matches

Site Navigation

Mail list logo

Footer information