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

[Aaron McCormack]

Hi Boris,

This part from 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  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] Can't call method warn for RT-Extension-Assets-Import-CSV

[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  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 
>  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 
> 425-352-5428

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

[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.edu
425-352-5428

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

[Marcos Orallo]

Hi Alex,

Thanks for your reply. My comments inline.

2015-06-22 19:46 GMT+02:00 Alex Vandiver :

> On Mon, 22 Jun 2015 19:10:50 +0200 Marcos Orallo 
> 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

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

> 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?

[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

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

[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

[Alex Vandiver]

On Mon, 22 Jun 2015 19:10:50 +0200 Marcos Orallo 
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

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

[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.info<14>] [6157]

reques...@address.com is blacklisted by notification checkboxes for
this transaction. Skipping
> Jun 22 11:29:55RT:[user.info<14>] [6145] 
>  #4519/69938 - Scrip 59 
> On Correspond from web Notify Requestor and Ccs
> Jun 22 11:29:56RT:[user.info<14>] [6145] 
>  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.