Re: [rt-users] Custom Charting and Tables

2015-08-31 Thread Jeffrey Pilant
Anton Panetta wrote:
>Hi There
>I'm curious if anyone else has attempted or found a way to achieve this.
>What I am
>Able to make is this (sort for the lack of formatting)
>
>  Ticket
>Queue   Statuscount
>new   11
>open  5
>rejected  1
>BPA resolved  7
>new   2
>open  3
>rejected  2
>COO Projectsresolved  6
>new   8
>open  3
>resolved  1
>DI  stalled   1
>new   6
>Finance resolved  5
>new   12
>IT BI Requests  stalled   1
>new   8
>open  8
>IT Helpdesk resolved  42
>new   18
>open  1
>resolved  2
>IT Projects stalled   1
>Total   0 154
>
>What id like to make is closer to this
>
>QueueOpen  New  Resolved  Stalled  Rejected  Total
>IT   1 51020 18
>DI   2 51030 20
>BI   3 51020 20
>Project  4 51031 23
>Total1020   4010   1
>
>The Idea is to include it in a dashboard.
>I am aware that using the chat tool to make a table is a bit of a side way, I 
>could possibly make do if I could make the tables run horizontal.
>Regards
>Anton

You need to make a query that returns 6 values per queue.
Pseudo SQL:
  select queue.name as queue, sumOpen, sumNew, sumResolved, sumStalled, 
sumRejected, sumTotal
from queue
   where queue.disable = 0
join (select count(*) as sumOpen, queue.id
from tickets
   where tickets.status  = 'open'
 and tickers.queueid = queue.id)
join (select count(*) as sumNew, queue.id
from tickets
   where tickets.status  = 'new'
 and tickers.queueid = queue.id)
join (select count(*) as sumResolved, queue.id
from tickets
   where tickets.status  = 'resolved'
 and tickers.queueid = queue.id)
join (select count(*) as sumStalled, queue.id
from tickets
   where tickets.status  = 'stalled'
 and tickers.queueid = queue.id)
join (select count(*) as sumRejected, queue.id
from tickets
   where tickets.status  = 'rejected'
 and tickers.queueid = queue.id)
join (select count(*) as sumTotal, queue.id
from tickets
   where tickets.status  in 
('open','new','resolved','stalled','rejected')
 and tickers.queueid = queue.id)

As I don't have easy access to the database, I am not sure I have the syntax or 
table names correct.  But this should give you an idea of what you need.

Basically, you need to gather the sum of tickets for each type by queue, and 
then list them all at once.  That needs multiple joins to achieve.

/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. 

For alternate languages please go to http://bayerdisclaimer.bayerweb.com



[rt-users] scrip to delete a Cc adress in a ticket

2015-08-31 Thread Loïc Cadoret

Hi RT user followers !

I need your help on my scrip creation.

Here is my need :

I would like to delete a Cc address if this address is the same that the 
RT queue response mail address.


We are running RT 3.8.11 (update to RT 4.2.x is currently not an option)

I need that because the email domain given to a customer to create a 
ticket is different from the one set in RT. We made a forward from this 
email address to RT one but when a mail is sent and the ticket created, 
RT add the email as Cc of the ticket.


Thanks very much for your help.

--
Loic Cadoret
IT Technician
Keyyo



Re: [rt-users] Problem with extension RepeatTicket

2015-08-31 Thread Moose
There is no problem with Repeat Ticket (that I am aware of), the problem was
between our ears! It seems that we both misunderstood how these recurrences
work.

The four cronjobs are doing exactly what they should. As are the ticket
recurrence settings.

Basically, the repeated ticket due date is controlled by the "Ticket lead
time" setting. The repeated ticket starts date is controlled by the
"Recurrence pattern".

These are what we should have been paying attention to, not the ticket
creation event. The cronjob may create a repeated ticket on Monday but that
repeated ticket will not be due to start until the following Thursday.







--
View this message in context: 
http://requesttracker.8502.n7.nabble.com/Problem-with-extension-RepeatTicket-tp60471p60560.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.


Re: [rt-users] scrip to delete a Cc adress in a ticket

2015-08-31 Thread Matt Zagrabelny
On Mon, Aug 31, 2015 at 10:24 AM, Loïc Cadoret  wrote:
> Hi RT user followers !
>
> I need your help on my scrip creation.
>
> Here is my need :
>
> I would like to delete a Cc address if this address is the same that the RT
> queue response mail address.

Create a scrip. They can do pretty much anything at anytime in the
ticket's life.

-m


[rt-users] Pg FTS query works, RT search returns 0 results ( was: '.' as delimiter/boundary breaks domain name searches)

2015-08-31 Thread Jeff Blaine
I'm reviving this one time in case anyone has further ideas.

* PostgreSQL 8.4.20 (RHEL 6.6) with FTS does the right
  thing when parsing an email address[1]

* An RT 4.2.12 search for the same string returns 0 results[2].
  I'm 98% certain the ticket *is* indexed though as other queries
  return it[2].

* The rt-fulltext-indexer script runs every 10 minutes and has
  no errors.

Jeff

Footnote 1:

rt4=# SELECT alias, description, token FROM ts_debug('f...@domain.com');
 alias |  description  | token
---+---+
 email | Email address | f...@domain.com
(1 row)

rt4=# SELECT alias, description, token FROM ts_debug('');
 alias |  description  | token
---+---+
 blank | Space symbols | <
 email | Email address | f...@domain.com
 blank | Space symbols | >
(3 rows)

rt4=#

Footnote 2:

Content LIKE 'f...@domain.com'

0 results

Content LIKE 'domain.com'

0 results

Content LIKE 'domain'

0 results

Content LIKE 'another unique string in the ticket I am trying to hit'

1 result

On 10/2/2014 11:08 AM, k...@rice.edu wrote:
> On Thu, Oct 02, 2014 at 10:56:56AM -0400, Kevin Falcone wrote:
>> On Wed, Oct 01, 2014 at 03:50:43PM -0400, Jeff Blaine wrote:
>>> [ Similar, but unrelated to my other message from 10 minutes ago. ]
>>>
>>> It appears any '.' is interpreted as a word boundary with
>>> Pg full-text indexing turned on.
>>>
>>> Is that known to be true, or am I wrong?
>>>
>>> This breaks searches for FQDNs names in ticket contents.
>>>
>>> Searching for 'foobar' will hit foobar.org
>>>
>>> Searching for 'foobar.org' will not hit 'foobar.org'
>>
>> What FTS will match/return is dictated by your database and its
>> configuration.
>>
>> Have you reviewed the Postgres full text search documentation for your
>> release of Pg?
>>
>> http://www.postgresql.org/docs/8.4/static/textsearch.html
>>
>> -kevin
> 
> 
> Wow! PostgreSQL 8.4, 4 major releases back! I cannot be certain that I
> am recalling this correctly, but the default parser in older versions
> of PostgreSQL did have that behavior. I do not know when they made the
> change to fix it. What do you get when you run:
> 
> rt3=# select plainto_tsquery('rice.edu');
>  plainto_tsquery 
> -
>  'rice.edu'
> (1 row)
> 
> I seem to recall that in the older version when I saw this issue, it
> returned:
> 
>  plainto_tsquery
> -
>  'rice' & 'edu'
> 
> You may be able to make a custom config for your text search using
> the definitions from the current release. I just ended up searching
> for 'rice' instead of 'rice.edu', for example.
> 
> Regards,
> Ken
> 

-- 
Jeff Blaine
kickflop.net
PGP/GnuPG Key ID: 0x0C8EDD02


Re: [rt-users] Pg FTS query works, RT search returns 0 results ( was: '.' as delimiter/boundary breaks domain name searches)

2015-08-31 Thread Bill Cole

On 31 Aug 2015, at 9:39, Jeff Blaine wrote:


I'm reviving this one time in case anyone has further ideas.

* PostgreSQL 8.4.20 (RHEL 6.6) with FTS does the right
thing when parsing an email address[1]


I question that.

I know that with Pg 9.0 the FTS indexer does arguably "right" things in 
parsing email addresses, hostnames, and IP addresses BUT that behavior 
effectively hides the octets inside an IP, the host and domain name 
elements in a hostname, and the local and domain parts of an email 
address. For our business (customized hosting & related services) this 
made the indexing do more harm than good. We have adequate capacity (and 
suitable config) on our DB server to handle most of the searches we need 
to do in reasonable time without the indexing, so we disabled it.