[rt-users] "Hidden" tickets suddenly appear

[Jeff Blaine]

RT 4.2.13 backed by PostgreSQL, though I feel like we've been
experiencing the following for many versions.

I've been suspect for quite some time, but thought maybe I was losing my
mind instead. I've confirmed finally that I am not losing my mind re: RT
in this specific case. We are definitely seeing the following situation.

I'm curious if anyone has thoughts as to where to start debugging the
root cause.

I use a simple saved search as my view into RT at work. Others using
this queue also use a similar one. The query is:

Queue = 'atcc-help'
AND
   (
  Status = 'new'
  OR Status = 'open'
  OR Status = 'stalled'
   )
AND (
   Owner = 'Nobody'
   OR Owner = 'jbla...@our.org'
)

The display settings for the search have "Rows: Unlimited"

It results in a daily list of 70-120 tickets.

We are seeing tickets appear in this list, where they have never
appeared in the list before, after some period of being in the queue. In
most cases, the mystery ticket has a "Created" date of more than a few
weeks ago. The most recent case was 5 months. That is, a ticket with
"Created" of around 5 months ago, and in "new" status, showed up in the
results of the search above where it never had shown up before.

As you can imagine, this is terrible for customer service. Luckily it
seems pretty rare. I would estimate that we see this happen ~5 times per
year, and then have to start the very awkward conversation about how the
ticket "slipped through our cracks".

Thoughts very welcome.

Jeff
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Randomizing / Masking Ticket Numbers / or Intelligently concatenating multiple numbers as ticket number.

[Alex Hall]

To my knowledge, yes, mail is routed through use of the subject line. When you 
create a queue, you give it a tag that is used in email subjects, and that is 
combined with the ticket ID to form the basis for how RT knows which 
queue/ticket a given message goes to. However, you can customize the regular 
expression RT uses, I believe, which fits with my suggestion from earlier 
today. You may be able to tune the expression to pull the true ID out of the 
randomized string, making your only coding task that of generating the random 
characters in the first place. See the $EmailSubjectTagRegex variable on this 
page:
https://docs.bestpractical.com/rt/4.4.1/RT_Config.html
> On Oct 25, 2016, at 19:51, Reza  wrote:
> 
> Thank you for your detailed response Jeff.
> 
> Thinking out of the box, a Random Number is not necessary if we can mask it 
> from email responses.   In my specific case, I do not want non-staff to 
> access RT.  Only support agents.
> 
> Is some sort of ID number absolutely necessary in the subject field and can 
> this be removed?  I guess a more technical question is how RT tracks the 
> email thread?   Is it through the headers, or a basic primitive Subject field 
> comparison ?
> 
> Then again... I'm thinking...  a ticket number is so much easier if its 
> relayed to support agents by caller if they decide to simply call for support.
> 
> Thoughts, ideas and suggestions welcome.
> 
> Best,
> Reza.
> 
> 
> Jeffrey Pilant wrote on 10/25/2016 2:43 PM:
>> Reza writes:
>>> The use case for random IDs is quite simple.   Ascending / serial number
>>> of IDs compromises confidentiality.  End users would be able to guess
>>> how busy I could be with the amount of tickets answered.  Its something
>>> I don't want to disclose.   Almost ALL ticketing systems I have seen,
>>> have a random arbitrary numeric or alpha-numeric ID.  Any other
>>> suggestions on how to approach not displaying an obvious number to end
>>> users?
>> I don't think I have ever seen a random number for ticket ID.
>> I have seen many systems that show reports of number of tickets processed 
>> per unit of time and he average answer time.
>> I guess I have never encountered your need before.
>> 
>> Seeing a series of ticket IDs may tell them how fast tickets come in, but it 
>> will not tell them how fast they are answered.
>> 
>> What might be easier is to create a custom field that holds a random number 
>> (maybe a GUID?).  This number could then be placed in the email subject line 
>> in place of the ticket ID.  Likiewise, the email reader could read the 
>> number from the subject and look up the ID.  This would touch a lot fewer 
>> places in the code, and if the recipient only ever sees the email, they 
>> don't know the real number.  Meanwhile, users of the web interface see both 
>> real number and random number.
>> 
>> If you allow them to see the web interface, the above will not work.
>> 
>> A simple possible solution is to add a random amount to the ticket sequence 
>> in the code that generates ticket numbers.  You will need a much larger max 
>> ticket ID since there is so much wasted space, but the random nature will 
>> obscure the number of real tickets between two given ticket IDs.
>> 
>> /jeff
>> 
>> 
>> The information contained in this e-mail is for the exclusive use of the
>> intended recipient(s) and may be confidential, proprietary, and/or
>> legally privileged.  Inadvertent disclosure of this message does not
>> constitute a waiver of any privilege.  If you receive this message in
>> error, please do not directly or indirectly use, print, copy, forward,
>> or disclose any part of this message.  Please also delete this e-mail
>> and all copies and notify the sender.  Thank you.
>> 
> 
> -
> RT 4.4 and RTIR training sessions, and a new workshop day! 
> https://bestpractical.com/training
> * Boston - October 24-26
> * Los Angeles - Q1 2017

-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

[rt-users] Randomizing / Masking Ticket Numbers / or Intelligently concatenating multiple numbers as ticket number.

[Reza]

Thank you for your detailed response Jeff.

Thinking out of the box, a Random Number is not necessary if we can mask 
it from email responses.   In my specific case, I do not want non-staff 
to access RT.  Only support agents.


Is some sort of ID number absolutely necessary in the subject field and 
can this be removed?  I guess a more technical question is how RT tracks 
the email thread?   Is it through the headers, or a basic primitive 
Subject field comparison ?


Then again... I'm thinking...  a ticket number is so much easier if its 
relayed to support agents by caller if they decide to simply call for 
support.


Thoughts, ideas and suggestions welcome.

Best,
Reza.


Jeffrey Pilant wrote on 10/25/2016 2:43 PM:

Reza writes:

The use case for random IDs is quite simple.   Ascending / serial number
of IDs compromises confidentiality.  End users would be able to guess
how busy I could be with the amount of tickets answered.  Its something
I don't want to disclose.   Almost ALL ticketing systems I have seen,
have a random arbitrary numeric or alpha-numeric ID.  Any other
suggestions on how to approach not displaying an obvious number to end
users?

I don't think I have ever seen a random number for ticket ID.
I have seen many systems that show reports of number of tickets processed per 
unit of time and he average answer time.
I guess I have never encountered your need before.

Seeing a series of ticket IDs may tell them how fast tickets come in, but it 
will not tell them how fast they are answered.

What might be easier is to create a custom field that holds a random number 
(maybe a GUID?).  This number could then be placed in the email subject line in 
place of the ticket ID.  Likiewise, the email reader could read the number from 
the subject and look up the ID.  This would touch a lot fewer places in the 
code, and if the recipient only ever sees the email, they don't know the real 
number.  Meanwhile, users of the web interface see both real number and random 
number.

If you allow them to see the web interface, the above will not work.

A simple possible solution is to add a random amount to the ticket sequence in 
the code that generates ticket numbers.  You will need a much larger max ticket 
ID since there is so much wasted space, but the random nature will obscure the 
number of real tickets between two given ticket IDs.

/jeff


The information contained in this e-mail is for the exclusive use of the
intended recipient(s) and may be confidential, proprietary, and/or
legally privileged.  Inadvertent disclosure of this message does not
constitute a waiver of any privilege.  If you receive this message in
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message.  Please also delete this e-mail
and all copies and notify the sender.  Thank you.



-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Seeing this error in the log

[Landon Stewart]

On Oct 25, 2016, at 2:17 PM, Alex Hall 
> wrote:

Hello list,
Every so often, and seemingly randomly, I see this error in /var/log/messages 
just as the FCGI server stops working:

Oct 25 13:43:07 RTServer RT: [8137] Argument "username" isn't numeric in 
numeric ne (!=) at /opt/rt4/sbin/../lib/RT/Interface/Web.pm line 3027.

It shows up three times, at the same exact time, and that's it. The "username" 
appears to be the username of one of our users (I've replaced the actual name 
with 'username' for this email). This is the only reason RT ever goes down. If 
it weren't for this, I doubt we'd have any problems at all. Manually restarting 
the FCGI server fixes things for anywhere from one to five days before the same 
problem happens again. Has anyone seen this before? RT4.4.1 on Debian 8. Thanks.

I think it has something to do with the reminders if that helps.  The following 
if() statement is on line 3027 of that file.  I have no idea why "$args->{ 
'Reminder-Owner-' . $reminder->id }" is has a value of the username of someone 
though since "$reminder->id" should return a numerical ID of the user.  Looks 
like a bug to me.

if (
exists( $args->{ 'Reminder-Owner-' . $reminder->id } )
&& ( $reminder->Owner !=
$args->{ 'Reminder-Owner-' . $reminder->id } )
  )
{
( $status, $msg ) =
  $reminder->SetOwner(
$args->{ 'Reminder-Owner-' . $reminder->id }, "Force" );
push @subresults, $msg;
}
--
Landon Stewart
Lead Analyst - Abuse and Security Management
INTERNAP ®
 lstew...@internap.com
 www.internap.com

-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Seeing this error in the log

[Landon Stewart]

OH!  I should mention that code stanza below is taken from the rt-4.4.1.tar.gz 
since I don't have 4.4.1 installed.

On Oct 25, 2016, at 2:29 PM, Landon Stewart 
> wrote:

I think it has something to do with the reminders if that helps.  The following 
if() statement is on line 3027 of that file.  I have no idea why "$args->{ 
'Reminder-Owner-' . $reminder->id }" is has a value of the username of someone 
though since "$reminder->id" should return a numerical ID of the user.  Looks 
like a bug to me.

if (
exists( $args->{ 'Reminder-Owner-' . $reminder->id } )
&& ( $reminder->Owner !=
$args->{ 'Reminder-Owner-' . $reminder->id } )
  )
{
( $status, $msg ) =
  $reminder->SetOwner(
$args->{ 'Reminder-Owner-' . $reminder->id }, "Force" );
push @subresults, $msg;
}
--
Landon Stewart
Lead Analyst - Abuse and Security Management
INTERNAP ®
 lstew...@internap.com
 www.internap.com

--
Landon Stewart
Lead Analyst - Abuse and Security Management
INTERNAP ®
 lstew...@internap.com
 www.internap.com

-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

[rt-users] Seeing this error in the log

[Alex Hall]

Hello list,
Every so often, and seemingly randomly, I see this error in
/var/log/messages just as the FCGI server stops working:

Oct 25 13:43:07 RTServer RT: [8137] Argument "username" isn't numeric in
numeric ne (!=) at /opt/rt4/sbin/../lib/RT/Interface/Web.pm line 3027.

It shows up three times, at the same exact time, and that's it. The
"username" appears to be the username of one of our users (I've replaced
the actual name with 'username' for this email). This is the only reason RT
ever goes down. If it weren't for this, I doubt we'd have any problems at
all. Manually restarting the FCGI server fixes things for anywhere from one
to five days before the same problem happens again. Has anyone seen this
before? RT4.4.1 on Debian 8. Thanks.

-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Greetings from a New RT user in Toronto.

[Alex Hall]

I'm just taking a shot in the dark, not knowing the code base well, but
what about this. You keep the actual number, but add things before and
after it. For instance:
1207b6988c77
where the ID is 988. Your filter is a letter followed by a number, then
your ID, then a letter. You can add random numbers before and after this to
as much length as you want. The random digit after the first letter will
make it far less obvious where the actual ID is, since the ID would change
for a new ticket, as would the random digit. You might even be able to
avoid reuse by tracking the letters and digit used, giving you 26*26*3
patterns before you'd have to start over. Not true random, but maybe it's
enough for your purposes and would be less of a process to implement?
Again, this is just a thought from someone who doesn't know the code well
at all.

On Tue, Oct 25, 2016 at 2:43 PM, Jeffrey Pilant 
wrote:

> Reza writes:
> >The use case for random IDs is quite simple.   Ascending / serial number
> >of IDs compromises confidentiality.  End users would be able to guess
> >how busy I could be with the amount of tickets answered.  Its something
> >I don't want to disclose.   Almost ALL ticketing systems I have seen,
> >have a random arbitrary numeric or alpha-numeric ID.  Any other
> >suggestions on how to approach not displaying an obvious number to end
> >users?
>
> I don't think I have ever seen a random number for ticket ID.
> I have seen many systems that show reports of number of tickets processed
> per unit of time and he average answer time.
> I guess I have never encountered your need before.
>
> Seeing a series of ticket IDs may tell them how fast tickets come in, but
> it will not tell them how fast they are answered.
>
> What might be easier is to create a custom field that holds a random
> number (maybe a GUID?).  This number could then be placed in the email
> subject line in place of the ticket ID.  Likiewise, the email reader could
> read the number from the subject and look up the ID.  This would touch a
> lot fewer places in the code, and if the recipient only ever sees the
> email, they don't know the real number.  Meanwhile, users of the web
> interface see both real number and random number.
>
> If you allow them to see the web interface, the above will not work.
>
> A simple possible solution is to add a random amount to the ticket
> sequence in the code that generates ticket numbers.  You will need a much
> larger max ticket ID since there is so much wasted space, but the random
> nature will obscure the number of real tickets between two given ticket IDs.
>
> /jeff
>
> 
> The information contained in this e-mail is for the exclusive use of the
> intended recipient(s) and may be confidential, proprietary, and/or
> legally privileged.  Inadvertent disclosure of this message does not
> constitute a waiver of any privilege.  If you receive this message in
> error, please do not directly or indirectly use, print, copy, forward,
> or disclose any part of this message.  Please also delete this e-mail
> and all copies and notify the sender.  Thank you.
> 
> -
> RT 4.4 and RTIR training sessions, and a new workshop day!
> https://bestpractical.com/training
> * Boston - October 24-26
> * Los Angeles - Q1 2017
>



-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Difficulty of turning one-time CC into full CC?

[Matt Zagrabelny]

Hi Alex,

On Tue, Oct 25, 2016 at 1:55 PM, Alex Hall  wrote:
>
> I know, in theory, how to make such a change now. What I'm wondering is how
> hard it might be. If anyone has ever done this before, can you give an idea
> of what is involved? The UI is one part, but what behind-the-scenes changes
> might I have to make? Is it as simple as changing an argument, or much
> worse? Am I changing the plate on an electrical outlet, or tearing down half
> the wall to change all the wiring?

You could leverage a callback. Ticket/Update.html has a callback named
BeforeDisplay. I don't know if that callback fires before the
transactions are created or not - that would be the question.

If it does fire before the transactions, then you could look at the
submitted ticket/txn data manipulate the ARGSRef to remove the
one-time ccs and add them in as ccs (if they aren't already ccs.)

I'm not sure the best way to go forward if the BeforeDisplay fires
after the txns are created.

-m
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

[rt-users] Difficulty of turning one-time CC into full CC?

[Alex Hall]

All,
People at work are wanting me to modify RT so that the one-time CC options
on ticket replies are instead full CCs. That is, anyone added there is
CC-ed on the full ticket rather than on just the transaction being made. No
one wants to use the 'people' tab, and one-time CC-ing isn't something
anyone expects to use.

I know, in theory, how to make such a change now. What I'm wondering is how
hard it might be. If anyone has ever done this before, can you give an idea
of what is involved? The UI is one part, but what behind-the-scenes changes
might I have to make? Is it as simple as changing an argument, or much
worse? Am I changing the plate on an electrical outlet, or tearing down
half the wall to change all the wiring?

-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Greetings from a New RT user in Toronto.

[Jeffrey Pilant]

Reza writes:
>The use case for random IDs is quite simple.   Ascending / serial number 
>of IDs compromises confidentiality.  End users would be able to guess 
>how busy I could be with the amount of tickets answered.  Its something 
>I don't want to disclose.   Almost ALL ticketing systems I have seen, 
>have a random arbitrary numeric or alpha-numeric ID.  Any other 
>suggestions on how to approach not displaying an obvious number to end 
>users?

I don't think I have ever seen a random number for ticket ID.
I have seen many systems that show reports of number of tickets processed per 
unit of time and he average answer time.
I guess I have never encountered your need before.

Seeing a series of ticket IDs may tell them how fast tickets come in, but it 
will not tell them how fast they are answered.

What might be easier is to create a custom field that holds a random number 
(maybe a GUID?).  This number could then be placed in the email subject line in 
place of the ticket ID.  Likiewise, the email reader could read the number from 
the subject and look up the ID.  This would touch a lot fewer places in the 
code, and if the recipient only ever sees the email, they don't know the real 
number.  Meanwhile, users of the web interface see both real number and random 
number.

If you allow them to see the web interface, the above will not work.

A simple possible solution is to add a random amount to the ticket sequence in 
the code that generates ticket numbers.  You will need a much larger max ticket 
ID since there is so much wasted space, but the random nature will obscure the 
number of real tickets between two given ticket IDs.

/jeff


The information contained in this e-mail is for the exclusive use of the 
intended recipient(s) and may be confidential, proprietary, and/or 
legally privileged.  Inadvertent disclosure of this message does not 
constitute a waiver of any privilege.  If you receive this message in 
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message.  Please also delete this e-mail 
and all copies and notify the sender.  Thank you. 

-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Deleting one attachment

[Ram]

>
> Sorry for not seeing this sooner, but I'll leave this for people wondering
> about the same in the future.
>
> We have sucessfully deleted single attachments from a ticket using
> rt-shredder. Issue the command like this;
>
> rt-shredder --plugin 'Objects=Attachment,​'
>


This is what I expected to be able to do but it's not on the web docs nor
the built-in USAGE. Guess I could've read through the code to confirm.
Thanks for follow up here Thomas!

Confirmed this works on rt 4.4.1.

br,
ram
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Greetings from a New RT user in Toronto.

[Reza]

Greetings Jeff:

Thank you for your reply.

The use case for random IDs is quite simple.   Ascending / serial number 
of IDs compromises confidentiality.  End users would be able to guess 
how busy I could be with the amount of tickets answered.  Its something 
I don't want to disclose.   Almost ALL ticketing systems I have seen, 
have a random arbitrary numeric or alpha-numeric ID.  Any other 
suggestions on how to approach not displaying an obvious number to end 
users?


Thanks!
Reza.


Jeffrey Pilant wrote on 10/25/2016 10:12 AM:

Reza writes:

The last 24-48 hrs has been an amazing learning experience.  I feel
as-if I can do Kung Fu now :)

 From my recent agenda of:

1. Create Random Ticket numbers.
2. Suppress "RT System Itself - Outgoing email recorded"
3. Customization of Auto ticket reply.
4. Assigning tickets / transferring to someone else (when not logged in
as root)
5. 3rd Party CRM integration basics.
6. How to Customize the RT at a glance (Just added to my list for Oct
25, 2016)

I have learned points #2, #3, #4.

Can anyone here guide me to the proper direction to accomplish #1
(Generating random ticket number versus ascending ticket numbers), and
guide me towards a fundamentally basic API example for 3rd Party CRM
integration?

In order to generate a random ticket ID, you need a random number generator, a 
min and max ID number allowed, and a way to determine if any given ID has 
already been used.  You then need to replace the standard SQL that gets the 
current max ID and adds one to assign a new ID.  I don't know where that code 
is.  As you fill the IDs, generating a new ID becomes harder and harder, 
because you will hit duplicate entries in the random generating process.  You 
also loose the relation of ID#s to date order.  Sorting a list of IDs by ID 
number will randomize the time that the IDs occur, requiring reports to be 
modified to be sorted by some other key.

Basically, you need a very strong reason to break the defaults the program 
uses, because there is a lot of work needed to rewrite the many things that use 
the defaults, and the time spent verifying that you found all the bits that 
need to be changed.

What is your use case?

/jeff

The information contained in this e-mail is for the exclusive use of the
intended recipient(s) and may be confidential, proprietary, and/or
legally privileged.  Inadvertent disclosure of this message does not
constitute a waiver of any privilege.  If you receive this message in
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message.  Please also delete this e-mail
and all copies and notify the sender.  Thank you.

-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017


-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Deleting one attachment

[Thomas Oddsund]

?Hello,


Sorry for not seeing this sooner, but I'll leave this for people wondering 
about the same in the future.

We have sucessfully deleted single attachments from a ticket using rt-shredder. 
Issue the command like this;

rt-shredder --plugin 'Objects=Attachment,?'


We use RT 4.2.8.


Med vennlig hilsen,
Thomas Oddsund
SDS/USIT

Fra: rt-users  på vegne av Ram 

Sendt: 25. oktober 2016 01:45
Til: rt-users
Emne: Re: [rt-users] Deleting one attachment

Inline..
> A user at work added an attachment that violates corporate policy to a
> ticket; the ticket itself is valid and must be kept. I need to delete the
> attachment. A quick look at the rt-shredder tool does not make it apparent
> to me how to do this with rt-shredder. I can readily do it editing the db in
> mysql but I'd rather use rt-shredder if it will do the job.
> any help?

I'll be going with a direct DB edit which I'm documenting here for the next 
person. Since I just want to suppress the file and do not want to hide the fact 
that it existed. Here is what I did, be very careful! If you don't know SQL or 
you don't understand every step below then find someone else to help you - this 
is the WRONG PATH for you:

1 Get the attachment id of the attachment to remove (as of RT 4.4.1  it's the 
*second* number in the URL that displays the attachment).

2 Add a comment to the ticket indicating that you are deleting the offending 
attachment for policy violation (or whatever you motive).

3 Run this command to improve your odds of not messing up and deleting the 
wrong transaction:
> select id, Transactionid, MessageId, Subject, Filename, ContentType, 
> ContentEncoding, Headers, Creator, Created from Attachments where id= 
> ATTACHMENT_ID_FROM_STEP_1 \G

4 If that looks right to you then run this SQL against A TEST COPY OF YOUR DB 
to ensure you are killing the right attachment
> update Attachments set Content = NULL where id = ATTACHMENT_ID_FROM_STEP_1 
> limit 1;

5 Go look at the ticket in RT and ensure that you did indeed eliminate the 
offending attachment.

6 Repeat steps 3,4,5 in your production environment.

7 Do not call me if you shot yourself in the foot. No warranty expressed or 
implied!

If this isn't perfectly clear, hire Best Practical (https://bestpractical.com/) 
 to do it for you.

cheers,

Ram
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Greetings from a New RT user in Toronto.

[Jeffrey Pilant]

Reza writes:
>The last 24-48 hrs has been an amazing learning experience.  I feel 
>as-if I can do Kung Fu now :)
>
> From my recent agenda of:
>
> 1. Create Random Ticket numbers.
> 2. Suppress "RT System Itself - Outgoing email recorded"
> 3. Customization of Auto ticket reply.
> 4. Assigning tickets / transferring to someone else (when not logged in
>as root)
> 5. 3rd Party CRM integration basics.
> 6. How to Customize the RT at a glance (Just added to my list for Oct
>25, 2016)
>
>I have learned points #2, #3, #4.
>
>Can anyone here guide me to the proper direction to accomplish #1 
>(Generating random ticket number versus ascending ticket numbers), and 
>guide me towards a fundamentally basic API example for 3rd Party CRM 
>integration?

In order to generate a random ticket ID, you need a random number generator, a 
min and max ID number allowed, and a way to determine if any given ID has 
already been used.  You then need to replace the standard SQL that gets the 
current max ID and adds one to assign a new ID.  I don't know where that code 
is.  As you fill the IDs, generating a new ID becomes harder and harder, 
because you will hit duplicate entries in the random generating process.  You 
also loose the relation of ID#s to date order.  Sorting a list of IDs by ID 
number will randomize the time that the IDs occur, requiring reports to be 
modified to be sorted by some other key.

Basically, you need a very strong reason to break the defaults the program 
uses, because there is a lot of work needed to rewrite the many things that use 
the defaults, and the time spent verifying that you found all the bits that 
need to be changed.

What is your use case?

/jeff

The information contained in this e-mail is for the exclusive use of the 
intended recipient(s) and may be confidential, proprietary, and/or 
legally privileged.  Inadvertent disclosure of this message does not 
constitute a waiver of any privilege.  If you receive this message in 
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message.  Please also delete this e-mail 
and all copies and notify the sender.  Thank you. 

-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Delivery Status Notification

[Jeffrey Pilant]

Maik Nergert writes:
>is there a simple way to proof, that a message and the attachment was 
>delivered to the recipient?
>It would be much better if the recipient has to confirm, that the 
>message arrived and he has read it.

SMTP, by definition cannot do this.  It cannot even guarantee delivery.

That said, there are specific implementations of email clients that can 
acknowledge delivery, and even being opened.  However, that is very client 
dependent, and you cannot count on what client will be used to read the email.

Again, that said, if you can enforce the client chosen (like at work having a 
company mandate), then you might be able to include control tags in the email 
header produced that will cause that client to perform that feature.

/jeff

The information contained in this e-mail is for the exclusive use of the 
intended recipient(s) and may be confidential, proprietary, and/or 
legally privileged.  Inadvertent disclosure of this message does not 
constitute a waiver of any privilege.  If you receive this message in 
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message.  Please also delete this e-mail 
and all copies and notify the sender.  Thank you. 

-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

[rt-users] Rename Owner Role only for Assets

[Dimitris Maniadakis via rt-users]

--- Begin Message ---
Hello!

I would like to ask if I can rename the word "Owner" in RT.
I modified the file en.po and indeed the word changed.
However, it changed BOTH for the TICKET Owner and the ASSET Owner.
I cannot find a way to change ONLY the ASSET Owner, although I specified it as 
following:

#: lib/RT/Asset.pm:86
msgid "Owner"

msgstr "Renamed Owner"

Any help, please?

Thanks in advance!
Dimitris
--- End Message ---
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Slow quote folding

[Petr Hanousek]

Hi,
we have migrated to another server with newer Debian and this issue
suddenly dissapeared. So I wanted just let you know. Thanks to Jeffrey
Pilant for interest and morale support :)
Petr

On 1.6.2016 11:04, Petr Hanousek wrote:
> Dear all,
> we have here some users who have such a habit to keep all the
> conversation history in e-mails. Some of them have also stupid mail
> clients which doubles the number of spaces. This results in looong mails
> and therefore long ticket history. So some individuals use, for better
> information overview, quote folding.
> This works quite well, but when the stuff that is to be quoted in ticket
> is too long (or too many of them?), the quoting procedure takes very
> long time. I've got here a ticket with 24 replies, each with the full
> mail history, and showing the ticket with folding turned on takes about
> 8 minutes. The ticket history during that time shows only "Loading..."
> notice.
> 
> When I searched in the code to see how this folding is done, it gave me
> an impression that it uses some general method which affects the whole
> RT. So I am little bit scare to give it some tuning :) Could you someone
> please either to confirm a bug, or (if it is a feature) explain me the
> mechanism how this should work and what to tune/rewrite?
> 
> Thank you, Petr
> 

-- 
+---+
   Petr Hanousek   e-mail: petr.hanou...@cesnet.cz
   MetaCentrum User Supportphone: +420 950 072 112
   CESNET z.s.p.o. mobile: +420 606 665 139
   location: Zikova 13a, Praha room: 32b
Czech Republic
+---+
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

[rt-users] Delivery Status Notification

[Maik Nergert]

Hi @all,

is there a simple way to proof, that a message and the attachment was 
delivered to the recipient?
It would be much better if the recipient has to confirm, that the 
message arrived and he has read it.



best
Maik



smime.p7s
Description: S/MIME Cryptographic Signature
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

Re: [rt-users] Greetings from a New RT user in Toronto.

[Reza]

Many thanks to my first 3 teachers, Kenneth Crocker, Alex Hall and Chris 
McClement, for guiding me to the right direction.


Ken, many thanks for your generosity for passing me a copy of your book 
"Request Tracker for Beginners - A Topical Guide" ( also available on 
Amazon if those of you newbie seeking knowledge )


Many thanks to the authors of "RT Essentials" published by O'Reilly.  
This is also a good start for the fundamental basics for RT.


The last 24-48 hrs has been an amazing learning experience.  I feel 
as-if I can do Kung Fu now :)


From my recent agenda of:

1. Create Random Ticket numbers.
2. Suppress "RT System Itself - Outgoing email recorded"
3. Customization of Auto ticket reply.
4. Assigning tickets / transferring to someone else (when not logged in
   as root)
5. 3rd Party CRM integration basics.
6. How to Customize the RT at a glance (Just added to my list for Oct
   25, 2016)

I have learned points #2, #3, #4.

Can anyone here guide me to the proper direction to accomplish #1 
(Generating random ticket number versus ascending ticket numbers), and 
guide me towards a fundamentally basic API example for 3rd Party CRM 
integration?


The new things I've learned:

1. Creating Queues
2. Creating Memberships
3. Understanding Group Permissions
4. Taking ownership of a ticket
5. Assigning tickets to someone else
6. Basic Ticket operations (Open, Close, Delete, Forward, Stealing etc)

I'm learning that RT is not only for managing Support Tickets, but it 
can also be used to followup on Sales leads etc (in the same manner as a 
support ticket is handled), but I have yet to understand how it can be 
used in Project Management.   A combination of active / hands on 
learning is needed here, in parallel to passive learning.  That's the 
hardest part because I'm not a very good passive learner (learning 
through reading).


I'm anticipating my status updates on this learning curve will serve as 
an agenda for the new folks adapting RT.


In the mean time, I will be reading Ken's "Request Tracker for 
Beginners" guide till I pass out.


Thanks for welcoming me to the community.

Cheers!
Reza.



On Mon, 24 Oct 2016 at 21:50 Reza > wrote:


Greetings Folks:

I successfully installed RT on a virtual machine and it has been a
non-stop learning marathon for 12+ hrs non stop.   If you are as
new as
me in RT, please reply to my message, and perhaps we can have a
conference call (at my expense) to do some sort of study group
session,
so we can share knowledge.

Its easiest to learn when there are friendly tutors.  FYI, I have
acquired the following knowledge the very hard way.
1.  Setup / Installation.  (The hardest part)
2.  Creating Users
3.  Creating Groups
4.  Understanding Permissons
5.  Enabling watchers
6.  Configuring Fetch Mail with SSL option to a gmail account (for
testing)
7.  Configuring Sendmail / Exim and smart host
8.  Purging / Shredding tickets


What I would like to learn is:
1.  Create Random Ticket numbers.
2.  Suppress "RT System Itself - Outgoing email recorded"
3.  Customization of Auto ticket reply.
4.  Assigning tickets / transferring to someone else (when not
logged in
as root)
5.  3rd Party CRM integration basics.

Thanks in advance to all the folks here, specially the creators of RT.

Best,
Reza.

-
RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017



-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017