[rt-users] Notification sent to requestor even when squelched

2015-06-22 Thread Marcos Orallo
Hi all,

I manage an RT 4.2.11 deployment using Debian Wheezy, Apache 2.2, mod_fcgid

Today we had a very concerning issue regarding a notification being sent to
a requestor even when it had been explicitly unchecked in the recipients
list. At first I didn't believe the user, but then I found this in the log:

Jun 22 11:29:08RT:[user.info14] [6157]
rt-4.2.11-6157-1434965348-1424.4519-5...@rtdomain.com
reques...@address.com is blacklisted by notification checkboxes for
this transaction. Skipping
 Jun 22 11:29:55RT:[user.info14] [6145] 
 rt-4.2.11-6145-1434965395-786.4519-5...@rtdomain.com #4519/69938 - Scrip 59 
 On Correspond from web Notify Requestor and Ccs
 Jun 22 11:29:56RT:[user.info14] [6145] 
 rt-4.2.11-6145-1434965395-786.4519-5...@rtdomain.com sent  To: 
 reques...@address.com


You can see that the requestor address was unchecked, but he was notified
anyway. The notificatoin script uses a custom condition to just send the
notification when using the web interface, with the possibility of
squelching recipients manually. The default behaviour (implicit
notification to all requestors even for correspondence by mail) was
confusing for my team mates.

The only odd thing I can see in the log is that the Blacklisted and the
sent to ... entries are written by two different perl processes (PID 6157
and 6145 respectively). That didn't happen when I tried to reproduce the
issue (with no success).
Does anyone know if that's normal in mod_fcgid? Could it be the cause of
the problem?

It's a big problem for us if we cannot fully trust the platform to not
spread confidential information to unintended recipients.

Thank you in advance,

Marcos.


[rt-users] Can't call method warn for RT-Extension-Assets-Import-CSV

2015-06-22 Thread Armin Liedtke
Hello,

I'm experiencing some issues trying to import items into RT Assets.  I have:
RT   4.2.11
RT::Extension::Assets1.05
RT::Extension::Assets::Import::CSV 1.4

I get an error:
Can't call method warn on an undefined value at 
/var/home/uwb/libraryrt.uwb.edu/rt/lib/RT.pm line 954.

I'm wondering if anyone else has seen this or has any quick fixes for it.  I 
have done testing with the data I'm important and that doesn't see to fix it.
I have run -debug but get same error.

Even though I would like to use the import I don't have to today, but If I 
don't at least start this conversation now, then I will be several days later 
before I do.

If there is a better place to send this like a bug reporting page, feel free to 
let me know that as well.

Thanks,

Armin


Armin Liedtke
Senior Computer Specialist
UWB-CC Campus Library
armha...@uw.edumailto:armha...@uw.edu
425-352-5428




Re: [rt-users] Can't call method warn for RT-Extension-Assets-Import-CSV

2015-06-22 Thread Aaron McCormack
I'm also seeing this message after some upgrades today.

I upgraded:
RT 4.2.6 - 4.2.11
RT::Extension::Assets 1.0.2 = 1.05
RT::Extension::Assets::Import::CSV 1.3 (did not upgrade)

I have my log level set to critical and since this function looks to be for 
troubleshooting deprecations with log level warn, I commented it out for now 
and the imports proceed as normal.

Aaron

 
 On Jun 22, 2015, at 2:12 PM, Armin Liedtke armha...@uw.edu wrote:
 
 Hello,
  
 I’m experiencing some issues trying to import items into RT Assets.  I have:
 RT   4.2.11
 RT::Extension::Assets1.05
 RT::Extension::Assets::Import::CSV 1.4
  
 I get an error:
 Can't call method warn on an undefined value at 
 /var/home/uwb/libraryrt.uwb.edu/rt/lib/RT.pm 
 http://libraryrt.uwb.edu/rt/lib/RT.pm line 954.
  
 I’m wondering if anyone else has seen this or has any quick fixes for it.  I 
 have done testing with the data I’m important and that doesn’t see to fix it.
 I have run –debug but get same error.
  
 Even though I would like to use the import I don’t have to today, but If I 
 don’t at least start this conversation now, then I will be several days later 
 before I do.
  
 If there is a better place to send this like a bug reporting page, feel free 
 to let me know that as well.
  
 Thanks,
  
 Armin 
  
  
 Armin Liedtke
 Senior Computer Specialist
 UWB-CC Campus Library
 armha...@uw.edu mailto:armha...@uw.edu
 425-352-5428



Re: [rt-users] RT 4.2 - owner list changed from pull-down menu to fill-in form

2015-06-22 Thread Aaron McCormack
Hi Boris,

This part from https://www.bestpractical.com/docs/rt/4.2/RT_Config.html 
https://www.bestpractical.com/docs/rt/4.2/RT_Config.html may explain it:

$AutocompleteOwners
If set to 1, the owner drop-downs for ticket update/modify and the query 
builder are replaced by text fields that autocomplete. This can alleviate the 
sometimes huge owner list for installations where many users have the OwnTicket 
right.

Autocompleter is automatically turned on if list contains more than 50 users, 
but penalty of executing potentially slow query is still paid.

Drop down doesn't show unprivileged users. If your setup allows unprivileged to 
own ticket then you have to enable autocompleting.


Aaron

 On Jun 17, 2015, at 12:46 PM, Boris Epstein borepst...@gmail.com wrote:
 
 Hello all,
 
 For some reason, at some point in a not so distant past, the form where you 
 can assign a newly created ticket to a user has changed from a pull-down list 
 to a form where you can type it in (with auto-fill but still). Has anybody 
 seen that? Does anybody know why this is happening?
 
 Thanks in advance for any and all help.
 
 Cheers,
 
 Boris.



Re: [rt-users] Notification sent to requestor even when squelched

2015-06-22 Thread Todd Wade

On 6/22/15 1:10 PM, Marcos Orallo wrote:

It's a big problem for us if we cannot fully trust the platform to not
spread confidential information to unintended recipients.


Along with Alex's suggestions / questions, it sounds like this workflow 
would benefit from the comment functionality. Ticket comments allow 
communication via your internal team (AdminCCs) but do not notify 
Requestors and Ccs.




Re: [rt-users] Notification sent to requestor even when squelched

2015-06-22 Thread Alex Vandiver
On Mon, 22 Jun 2015 19:10:50 +0200 Marcos Orallo m_ora...@yahoo.es
wrote:
 I manage an RT 4.2.11 deployment using Debian Wheezy, Apache 2.2,
 mod_fcgid
 
 Today we had a very concerning issue regarding a notification being
 sent to a requestor even when it had been explicitly unchecked in the
 recipients list. At first I didn't believe the user, but then I found
 this in the log:
 [snip]

There's a 47-second interval between the first and the second of
those.  Can you show the full log of everything between them?  My guess
is that the first one was a dry run to list the potential recipients,
and the second was the actual submission.  This would explain the
different process IDs, as well as the different behaviors.

 You can see that the requestor address was unchecked, but he was
 notified anyway. The notificatoin script uses a custom condition to
 just send the notification when using the web interface, with the
 possibility of squelching recipients manually. The default behaviour
 (implicit notification to all requestors even for correspondence by
 mail) was confusing for my team mates.

Your wording is confusing.  Is this jut the stock Notify Requestor and
Ccs action, with a custom condition?
 - Alex


Re: [rt-users] Notification sent to requestor even when squelched

2015-06-22 Thread Marcos Orallo
Hi Alex,

Thanks for your reply. My comments inline.

2015-06-22 19:46 GMT+02:00 Alex Vandiver a...@chmrr.net:

 On Mon, 22 Jun 2015 19:10:50 +0200 Marcos Orallo m_ora...@yahoo.es
 wrote:
  I manage an RT 4.2.11 deployment using Debian Wheezy, Apache 2.2,
  mod_fcgid
 
  Today we had a very concerning issue regarding a notification being
  sent to a requestor even when it had been explicitly unchecked in the
  recipients list. At first I didn't believe the user, but then I found
  this in the log:
  [snip]

 There's a 47-second interval between the first and the second of
 those.  Can you show the full log of everything between them?


That's the full log, nothing in between (syslog, info level). The gap is
indeed strange...


 My guess is that the first one was a dry run to list the potential
 recipients,
 and the second was the actual submission.  This would explain the
 different process IDs, as well as the different behaviors.


But the blacklisting happened just for that transaction when composing
the message, it was not a permanent squelch. So the system didn't know it
was blacklisted in the preparation stage...



  You can see that the requestor address was unchecked, but he was
  notified anyway. The notificatoin script uses a custom condition to
  just send the notification when using the web interface, with the
  possibility of squelching recipients manually. The default behaviour
  (implicit notification to all requestors even for correspondence by
  mail) was confusing for my team mates.

 Your wording is confusing.  Is this jut the stock Notify Requestor and
 Ccs action, with a custom condition?


Exactly. This is the custom condition, taken from RT wiki, IIRC.

my $trans = $self-TransactionObj;
return 0 unless $trans-Type eq Correspond;

my $msgattr = $trans-Message-First;
return 0 unless $msgattr;

return 1 unless $msgattr-GetHeader('Received');
return 0;


Re: [rt-users] Notification sent to requestor even when squelched

2015-06-22 Thread Marcos Orallo
Hi Todd,

Thank you for the suggestion. However, in this case, it was a Reply with
One-Time-CCs, so I guess a Comment is not the best option. Moreover, we
don't have control of the mail domain, and you wouldn't believe the
bureaucracy and delay to get a mail alias for comments.

It's true that our use of the system is not always adapted to the platform,
my colleagues want the WebUI to be basically a mail client on steroids.
They want all external recipients to be explicit, either when sending a
mail from their client, or in the webUI message composing screen.

Even if I understand the design of RT, I think a few features would make it
come close to what users are most accustomed to in a mail client, and make
it more flexible:

- Correspondance subject independent from the ticket title. Copied from the
transaction that you are replying to.
- Default recipients selected based on the sender of the transaction you
are replying to, even if they are not the Requestors (with the full list of
Requestors available for checking if desired).
- One-Time-To. There is an extension for this, but I couldn't make it work
properly with RT 4.2.
- Preserved To, CC in mail notifications, by setting them to a different
value independent from the SMTP envelope.
- Show full list of recipients for transactions in History
- Collapsible individual transactions in History.

Anyway, I should maybe wait for Christmas... :-)

Kind regards,
Marcos.

2015-06-22 19:54 GMT+02:00 Todd Wade t...@bestpractical.com:

 On 6/22/15 1:10 PM, Marcos Orallo wrote:

 It's a big problem for us if we cannot fully trust the platform to not
 spread confidential information to unintended recipients.


 Along with Alex's suggestions / questions, it sounds like this workflow
 would benefit from the comment functionality. Ticket comments allow
 communication via your internal team (AdminCCs) but do not notify
 Requestors and Ccs.




[rt-users] Excluding tickets from search based on updated fields?

2015-06-22 Thread Barton Chittenden
We have the following canned search, which will find tickets not updated by
the Current User in the last two days. This search is used in a dashbord
that sends a daily email to our support staff, showing tickets that need
follow-up.

Owner = '__CurrentUser__' AND LastUpdatedBy != '__CurrentUser__' AND
LastUpdated  '2 day ago' AND Status != 'resolved' AND Status != 'answered'
AND ( Queue != 'Development' AND Queue != 'Bugs' )

The problem that we've run in to is that there are certain things that get
updated that don't merit follow up -- changes in ticket priority, or
setting Custom Flags.

Is it possible to exclude updates of certain fields?

Thanks,

--Barton