Re: [rt-users] Do not email user if they are requestor when also admin cc of a queue
On further thought, I realise that a custom condition on the send email to Admin CCs scrip is not a solution—you can only use such a condition to send either all admin CC emails or none (i.e. you can't send to some admin CCs and not others this way). To achieve your desired behaviour without adjusting the ticket's watchers (i.e. requestor list), you would need to monkey-patch the underlying code of your RT installation responsible for sending emails. It has been done before, and someone has kindly written up something on the wiki about it: http://requesttracker.wikia.com/wiki/NotificationsTuning It's not ideal though, because it complicates RT upgrades/migrations and it also makes RT behave in a manner contrary to its documentation. I still think that removing your administrator's email address from the Requestor field of each ticket is the best solution. By doing this with a scrip, your administrator wouldn't even need to know that it's happening. Additionally, if you do any reporting on tickets that requires the Requestor fields to be complete, you could always write a scrip to re-add them as a requestor when the ticket is resolved. What are your thoughts at this time? On Mon, 2 Mar 2015 at 22:46 Daniel Moore daniel.mo...@osbornewood.com wrote: Hi Alex, Thank you for the information. The administrator cannot remove themselves as a requestor. My code in my example is horribly wrong; however, I believe it is pretty close to what I need. I am new to Perl. If someone could possibly help me clean up the code where, on submission of the ticket transaction (correspond) it checks the requestor email and admin cc email against each other and if they are the same then it only sends to the requestor. I am putting the code in the script that sends to Admin CCs (both queue admin cc and ticket admin cc). I cannot figure out the IF statement and validation checks. That seems to be the only acceptable solution to me. V/R, *Daniel Moore* IT Systems Technician Osborne Wood Products, Inc. [image: http://hosting-source.bm23.com/9241/public/OsborneLogo111.jpg] P: 706.282.5764 F: 888.777.4304 http://www.osbornewood.com *From:* Alex Peters [mailto:a...@peters.net] *Sent:* Saturday, February 28, 2015 5:12 PM *To:* Daniel Moore; rt-users@lists.bestpractical.com *Subject:* Re: [rt-users] Do not email user if they are requestor when also admin cc of a queue The simplest solution is that the administrator manually removes themselves as a requestor when putting in their own tickets. The simplest coding for this solution (unless your administrator is willing to do this manually on every ticket creation) is to write a scrip on this queue that runs on ticket creation time and manually removes the administrator's address if it appears in the list of requestors. Let me know if that's not an acceptable solution, and we can work further on the scrips that filter the emails. On Sun, 1 Mar 2015 at 00:17 Daniel Moore daniel.mo...@osbornewood.com wrote: Hello, I have an administrator here in my department that is a Queue Admin CC but he also puts in a lot of tickets for special requests from our contractors. He is then the Queue Admin CC and the Requestor. Also, the contractors have a group email address that is also the admin cc. Therefore, he ends up getting multiple emails for one ticket. I have tried the coding from the “Notifications Tuning” that is supposed to limit the emails sent out if they are the same for multiple fields; however, that did not work as expected. I fixing the queue and making a new group that includes the individual set of contractors so that he doesn’t get emails that way, but that’s not what he wants. My question is in two parts (Code will be included at the ends): 1) How can perform a custom condition in the scrips for the queue to not send an email to admin Cc if his email address matches the requestor? OR 2) If I reverse my settings and take him off of admin CC and put him back in the group, how can I check for his email address and code it only to send one email address ? Here’s the coding for question number one: Description: Notify AdminCc only if not Requestor Condition: User Defined Action: Notify AdminCcs Template: Custom Custom Condition: First set of code I tried by using another example: my $trans = $self-TransactionObj; return 1 unless $Ticket-RequestorAddresses eq $Ticket-QueueObj-AdminCcAddresses; Return 1; Second code: my $trans = $self-TransactionObj; my $admincc = $self-QueueObj-AdminCcAddresses; my $requestor = $self-RequestorAddresses; return 0 unless $requestor == RT::Nobody-id; return 1; If somone could help me get the coding down that would be great. I don’t fully understand Perl yet. V/R, *Daniel Moore* IT Systems Technician Osborne Wood Products, Inc. [image:
Re: [rt-users] RT saves data in quoted-printable, why???
Hi, On Thu, Mar 05, 2015 at 06:37:21PM -0500, Alex Vandiver wrote: On Fri, 6 Mar 2015 00:06:32 +0100 Václav Ovsík vaclav.ov...@i.cz wrote: https://issues.bestpractical.com/Ticket/Display.html?id=29735 Aha -- thanks for digging that out! I thought I vaguely recalled something in this area previously. https://issues.bestpractical.com/Ticket/Attachment/286095/157750/utf8-encoding.patch looks to be functionally fairly similar to the branch. Thanks for attention to this... There are a few other, orthogonal fixes in there that may still be interesting to tease out into their own commits. It looks like I see changes to: * Fix the computed max size of base64'd attachments; I'd need to squint at it harder, but seems eminently reasonable. * Attempt to gracefully deal with TruncateLongAttachments truncating mid-byte of UTF-8 data. As above; the decode/encode is an interesting trick to attempt to ensure that the byte stream is consistent. I'd like to test it a bit, but seems not unreasonable. It is not too efficient maybe, but easy and safety first :) * Choose base64 vs QP based on which is shorter; I'm less convinced by this, since it means that for large data, it gets QP'd, base64'd, and then one of those _again_ -- which isn't terribly efficient. I'm less convinced by the tradeoff of computation time to stored in-database size. You are right. My intention was to gather as much readable text as possible. Maybe a text contains some invalid characters, but the rest of the text is readable, so QP is more appropriate, because it leaves the most of a text readable. So the measuring of length of an encoded data Base64/QP gives a result of how much ASCII chars are there. len Base64 len QP - many binary data - maybe some octet stream len QP len Base64 - many ASCII chars - maybe the text But this is corner case probably and it is not very interesting. The most of the text should be UTF-8 valid and the rest is not interesting these days. If you're interested in reworking the patch into a 2-3 commit series, I'm happy to apply for 4.2-trunk. - Alex https://github.com/bestpractical/rt/compare/stable...zito:4.2-zito-encodelob-utf8-fix This is a bit newer version I'm using within production instance rt-4.2.9. I will be happy if some part will be usable for RT mainline. Thanks for fine software! Cheers -- Zito
[rt-users] Show recipient on ticket update - not working
Hi all, I have both the 'Recipients' and the 'Scrips and Recipients' sections empty when I resolve/reply to a ticket. I mean, I see no recipients and no check boxes. I have no warnings/errors in the log. What can it be that is causing this behavior? Thank you in advance. Cris
Re: [rt-users] script to check out if max attachment size is reached
On Fri, 06 Mar 2015 12:42:38 +0100 Loïc Cadoret lcado...@keyyo.com wrote: Greetings rt-users followers, I would like to create a script that check out if the max attachment size of a response is reached and if so, send an autoreply to the requestor informing him that his documents are too heavy. Indeed, customers send documents to our customer services but sometimes the transaction is droped by the system because max attachment is reached and neither the customer service or the client is notified of it. Starting in RT 4.2.7, RT records explicit transactions when attachments are dropped or truncated due to hitting $MaxAttachmentSize. While we explicitly prevent such transactions from triggering scrips (to prevent infinite loops), you can likely use them as the basis of your notifications -- or, at least the signal to the RT users to notify customers of the drop. - Alex
Re: [rt-users] Issues with Article Permissions
On Thu, 5 Mar 2015 12:06:55 +1100 Matthew Crozier matt...@staff.broadbandsolutions.com.au wrote: I'm having an issue when attempting to create a new article as the root (SuperUser rights) account. It simply says Permission denied Check your error logs. Running rt-validator --check might also be a good idea. - Alex
Re: [rt-users] Upgrade to 4.2.9 Lost Dashboards.
Hi Alex, I have upgraded from 4.0.4, But the strange thing is that some people kept their dashboards and some didn't. Sam -Original Message- From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Alex Vandiver Sent: 05 March 2015 19:57 To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Upgrade to 4.2.9 Lost Dashboards. On Thu, 5 Mar 2015 14:52:39 -0500 Alex Vandiver ale...@bestpractical.com wrote: On Wed, 25 Feb 2015 11:52:37 + Sam Maher sam.ma...@lawsonlewisblakers.co.uk wrote: I have moved to a new server and upgraded to the latest version but all my privileged users except one have lost their dashboards. Has anyone else had this problem? Please specify what you mean by latest version. I missed that the subject specified you upgraded to 4.2.9. What version were you upgrading from? - Alex Sam Maher - IT Technician Lawson Lewis Blakers T: 01323 720142 F: 01323 725349 Partners: Jeremy H Sogno, Nadine M Ashford and Mark Barrett Lawson Lewis Blakers Solicitors Authorised and Regulated by the Solicitors Regulation Authority. SRA No: 00053703 THIS E-MAIL AND ANY ATTACHED FILES ARE CONFIDENTIAL AND MAY BE LEGALLY PRIVILEGED If you are not the addressee or the intended recipient any disclosure, copying, distribution, or other use of this e-mail and attachments is strictly prohibited. If you have received this e-mail in error please notify the sender immediately and delete this e-mail. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, be incomplete or contain viruses. We do not accept liability for any errors or omissions which arise as a result of e-mail transmission. Any e-mail attachment may contain software viruses. Whilst reasonable precaution has been taken to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. Lawson Lewis Blakers reserves the right to monitor or record e-mails for any purpose allowed by prevailing legislation.
[rt-users] Search users with special searches on RT on the glance
Hello, we have different users with different by-group or globally-saved-searches on their own RT at the glance. In the WebInterface I only can find by user which saved-search is on this users RT at the glance. Is there a way to do this vice versa, so to find by saved-search, on which users RT at the glance one specified globally or by-group saved search is? Best regards Bernhard
[rt-users] script to check out if max attachment size is reached
Greetings rt-users followers, I would like to create a script that check out if the max attachment size of a response is reached and if so, send an autoreply to the requestor informing him that his documents are too heavy. Indeed, customers send documents to our customer services but sometimes the transaction is droped by the system because max attachment is reached and neither the customer service or the client is notified of it. I have already checked out the different contribs but nothing seems to match my request... Unfortunatly, I'm not really comfortable with rt-users mailing list yet so maybe this request has already been asked. Thanks is advance for your help and sorry for my bad english ! -- Loic Cadoret IT Technician Keyyo
