[rt-users] Making "make initdb" idempotent?

[Craig Ringer]

Hi all

I'm in the process of packing up various small bits of RT code for our
RT install into an extension that can be properly versioned and tracked.

There's just one frustrating barrier to this: RT's extension system
provides a "make initdb", but no way to make the application of the
initial data provided in etc/initialdata idempotent. If you run "make
initdb" twice, it duplicates everything, not just adding any new records.

Is this a problem anyone else has looked into? I'm considering teaching
"make initdb" to do a basic upsert: Lock the table in question in
EXCLUSIVE mode (PostgreSQL, allows SELECTs but nothing else in other
transactions), then do the usual portable two-command sequence:

UPDATE thetable
SET description = 'thedescription', ...
WHERE name = 'thename';

INSERT INTO thetable(name, description, ...)
SELECT 'thename', 'thedescription', ...
WHERE NOT EXISTS (SELECT 1 FROM thetable WHERE thetable.name = 'thename');


For other DBs, just do a "LOCK tablename;" (unless MySQL, etc, users
want to suggest an appropriate lock mode).

The problem with this is that the name isn't really meant to be a key,
for all sorts of reasons. It's user-visible, it's in natural language,
and it's translatable.

It'd be strongly preferable to add a new field to the initdb parameter
hash that provides a non-translatable internal text identifier for the
command of interest. Here's what I'm thinking of:

- Add a new nullable unique text column to scrips, scripactions, and
scripconditions named 'extension_identifier'.

- Have 'make initdb' check for a hash param 'ExtensionIdentifier' in
each row. If none is present, behave exactly as now, leaving the
extension_identifier column NULL.

- If the ExtensionIdentifier key is found, Do an upsert with table lock
as described above for each row when we 'make initdb', but instead of
using the 'name' field, discriminate based on the 'extension_identifier'
column.




This would allow extensions to provide a unique identifier for their
scrips, scrip actions, scrip conditions, etc, that if used consistently
would let them make the initdb command idempotent, so it can be used
when an extension is updated, not just first installed.

Guidance for extension authors would suggest that the extension's name
be used to prefix the extension identifier so as to avoid clashes.

No support for deleting obsolete entries would be provided; if an entry
vanishes from the initialdata but was installed from a previous version,
it would not be touched in the DB. That's let extensions continue to
provide support for old actions, conditions, etc without exposing them
to new users.

By using the extension name and a text identifier the need to have a
central identifier registry is avoided; CPAN's Perl namespace registry
already serves the required purpose.

Thoughts/opinions?

Would the RT team consider accepting a patch implementing the above as a
change to RTxInitDB ?

If so, how would you deal with the addition of the new column to each of
the tables? Do it as part of the upgrade script for the next RT release
that needs an upgrade script anyway, and if it isn't present, ignore the
ExtensionIdentifier field in the initialdata for backward compatibility?
-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

[rt-users] Conditionally add new unprivileged users

[Al Twohill]

Hello all,

I'm currently learning rt - this thing is amazing and I wish I knew
about it earlier!

I'd like to be able to extend the user creation via email process, but
I'm not sure where to start.

Specifically, when someone emails r...@example.com and they don't yet
have a user account, I'd like to search through all my groups to see
if their domain name exists in a custom field.

If the group is found, then I'd like them to be added to that group,
and the ticket created.

If no group is found, I'd like rt to send them a message telling them
to contact an admin, and the user account would not be created.

I'm not asking how to code this functionality (I'll try and figure
that out myself), but I've no idea how I can hook into the account
creation process.

If anyone could give any pointers for me to get started that'd be wonderful.

I'm running rt 4.0.4 on Ubuntu 12.04.

Thanks,

Al

Re: [rt-users] 'Reply' rights - what am I missing?

[Kevin Falcone]

On Wed, Jun 19, 2013 at 02:07:20PM +0300, Boli wrote:
> I have a queue that my privileged users are able to reply to, however I
> don't want them to be able to reply - only comment.
> 
> - There are no 'user' rights set for anyone anywhere.
> - The 'group' rights for the queue
> (tools->config->queues->QUEUE->groupRights) do not allow 'Reply to Tickets'
> There are no global group rights (tools->config->global->group
> rights)(except relating to saved searches)
> 
> Why can my users still reply to tickets? What am I missing?

Do they have ModifyTicket?

-kevin


pgpFyxrN3j3mU.pgp
Description: PGP signature

Re: [rt-users] Problems with Perl modules on CentOS

[Ram]

Date: Thu, 20 Jun 2013 10:26:21 +0700

> From: Johnny Rose Carlsen 
> Dear List,
>
> I have been running a few RT 3/4 systems on CentOS 5/6 for the last 3
> years and have had many issues maintaining them.
>
> A lot of the required Perl modules used by RT are not provided by the
> standard CentOS repositories (including EPEL and RPMForge), which means
> they will get installed using CPAN.
>
> Some of the modules from CPAN then requires newer versions of modules
> that was installed by RPM. So in some situations I end up with a module
> being managed by both CPAN and RPM (CPAN for the newest version, RPM
> because of other RPM dependencies).
>
> Everything usually ends up working somehow, but only until it is time to
> update the server (yum update) or RT - which causes everything to break.
>
> I have read the wiki about how other people handle RT on CentOS, but I
> can't see any guides who actually solves this problem.
>
> Am I missing something? or should I just be using a different distribution?
>
> Which distribution seems to work best with RT? - I'd like to completely
> avoid installing stuff using CPAN.


I run rt4 on centos. IMO the best way to handle it is to use CPAN in a
pre-production environment and have it install into a local user folder and
that tar up that folder and stuff it into production. The install only the
base perl modules for our distro using packages - all the RT specific stuff
is pulled in via CPAN. The reasons for this decision included:
-some modules need to be complied and as a matter of policy we don't put
compilers on production boxes
-we run multiple vhosts and they might have different perl dependencies
-we could not find all the CPAN modules we needed packaged already

To go down this path you will have to set envs accordingly for httpd, any
cron-jobs, as well as any user accounts where you want to use the RT
command-line tools.

In the httpd conf for my rt4 vhost I have:

SetEnv  PERL5LIB /srv/httpd/
example.com/perl/lib:/srv/httpd/example.com/perl/lib/perl5

FastCgiServer
/srv/httpd/example.com/rt-4.0.2/sbin/rt-server.fcgi-processes 5
-idle-timeout 300 -initial-env PERL5LIB=/srv/httpd/
example.com/perl/lib:/srv/httpd/example.com/perl/lib/perl5


In the crontab for the user that runs rt cron jobs (e.g.rt-email-digest)
one of the first lines is:
PERL5LIB=/srv/httpd/
example.com/perl/lib:/srv/httpd/example.com/perl/lib/perl5

In the env for any user that wants to run rt tools (like rt and
rt-shredder):
PERL5LIB=/srv/httpd/
example.com/perl/lib:/srv/httpd/example.com/perl/lib/perl5

You will have to configure CPAN to install into the private dir - see
http://www.perlmonks.org/?node_id=630026

cheers
ram

Re: [rt-users] Notify owners of new ticket not working

[Barnes, Andrew (barnesaw)]

On 6/19/13 1:00 PM, "Cena, Stephen (ext. 300)"  wrote:

>Ah; then it looks like it's a bug in the plug-in itself. It is in fact
>notifying the potential owners of a ticket, whether an Owner is
>specified or not. This isn't bad. I could just create a custom Template
>that would rework the email to let everyone know who has the ticket.
>
>Does anyone have a custom Scrip they use when a ticket is created, and
>no owner is specified that all potential owners get notified? I also
>need to look at the Perl modules someone recommended earlier, but I
>thought this plug-in might do the trick.



My (working) custom condition:
###
## Custom condition for OnCreate
## Only applies if no owner is set
###

return undef unless ( ($self->TransactionObj->Type eq "Create") &&
( $self->TicketObj->Owner == $RT::Nobody->id ) );
return 1;





Drew Barnes
Software Applications Developer
University of Cincinnati Blue Ash College
Information Technology Department


smime.p7s
Description: S/MIME cryptographic signature

Re: [rt-users] Unable to configure "open" queue

[Joop]

Christian B. Wiik wrote:
On Thu, Jun 20, 2013 at 9:45 AM, Joop > wrote:


As a test could you add Create Tickets to the global Everyone
group and then try. RT Essentials (the book) has an example of
that and for me it has worked several times in the past.
Restricting Create Ticket to only certain queues will work but try
to get the general one working first.
Thinking about general, what does your /etc/aliases look like, or
how/where does you mail end up in RT?
My setup is that mail send to supp...@domain.nl
 will go to the General queue which is
created as part of initdb and things like support-a...@domain.nl
 will go directly to the app1
queue. I'm suspecting that you have added Create Ticket to your
Testing queue but that by default your mta is trying to use the
General queue to create tickets which doesn't have Create Ticket.


Hi and thanks for reply Joop.

I already have "Create tickets" enabled under global group rights -> 
Everyone -> General rights.


My /etc/aliases is currently set to:
support: "|/opt/rt4/bin/rt-mailgate --queue Testing 
--action correspond --url http://localhost/rt/";


My RT was set up running 4.0.10, but I have now upgraded to 4.0.13 and 
get the same results.


Those settings should work. There are no other errors/info in the rt.log 
or apache error.log just above the permission denied?
You could feed rt-mailgate a mail message from the commandline and see 
what error it spits out. Wild guess, why use localhost/rt instead of 
fqdn/rt ?


Joop

Re: [rt-users] When linking an article to a ticket, some noise is display

[Ruslan Zakirov]

It is controlled with checkboxes in settings for the class.

Ruslan from phone.
20.06.2013 12:07 пользователь "My Firstname My Lastname" 
написал:

> Hello all,
>
> I configured some articles with custom fields in my RT4 instance.
> When I link an article to a ticket, I see somme characters like:
>
> #2: Canned Response 1
> -
> Body:
> 
> Test 1234
> On Tue Jun 18 08:41:28 2013, ...@x.com wrote:
> > Hello, I need your help.
>
> Is there a possibility to delete the "#2: Canned Response 1" and the
> "body: " ?
> It doesn't appear "Professional" in front of the customers...
>
> Thanks for your help
>
> Phi.
>

[rt-users] When linking an article to a ticket, some noise is display

[My Firstname My Lastname]

Hello all,

I configured some articles with custom fields in my RT4 instance.
When I link an article to a ticket, I see somme characters like:

#2: Canned Response 1
-
Body:

Test 1234
On Tue Jun 18 08:41:28 2013, ...@x.com wrote:
> Hello, I need your help.

Is there a possibility to delete the "#2: Canned Response 1" and the "body:
" ?
It doesn't appear "Professional" in front of the customers...

Thanks for your help

Phi.

Re: [rt-users] Unable to configure "open" queue

[Christian B. Wiik]

On Thu, Jun 20, 2013 at 9:45 AM, Joop  wrote:

> As a test could you add Create Tickets to the global Everyone group and
> then try. RT Essentials (the book) has an example of that and for me it has
> worked several times in the past. Restricting Create Ticket to only certain
> queues will work but try to get the general one working first.
> Thinking about general, what does your /etc/aliases look like, or
> how/where does you mail end up in RT?
> My setup is that mail send to supp...@domain.nl will go to the General
> queue which is created as part of initdb and things like
> support-a...@domain.nl will go directly to the app1 queue. I'm suspecting
> that you have added Create Ticket to your Testing queue but that by default
> your mta is trying to use the General queue to create tickets which doesn't
> have Create Ticket.
>

Hi and thanks for reply Joop.

I already have "Create tickets" enabled under global group rights ->
Everyone -> General rights.

My /etc/aliases is currently set to:
support: "|/opt/rt4/bin/rt-mailgate --queue Testing --action
correspond --url http://localhost/rt/";

My RT was set up running 4.0.10, but I have now upgraded to 4.0.13 and get
the same results.

-- 
Regards
Christian

Re: [rt-users] Passing Today's date to a custom field through Template

[Emmanuel Lacour]

On 19/06/2013 22:18, Daniel Tinoco-Silva wrote:



 > Start Date: { $Ticket->CreatedAsString }



this syntax should work (not tested):

Starts: { $Ticket->ISO }

look here for available fields:

http://www.bestpractical.com/rt/docs/4.0/RT/Action/CreateTickets.html#Acceptable-Fields

Re: [rt-users] Unable to configure "open" queue

[Joop]

Christian B. Wiik wrote:

Hi.

We are a small company that got recommended this nice piece of 
software, but have stranded on a small issue: We are unable to 
configure a "open" queue, that allows everyone to create a ticket 
through incoming email.


Whatever we try we get the following two lines in syslog:
Ticket creation failed: Test 20: No permission to create tickets in 
the queue 'Testing' (/opt/rt4/sbin/../lib/RT/Interface/Email.pm:248)
Could not record email: Ticket creation failed: No permission to 
create tickets in the queue 'Testing' 
(/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway

:75)

Tried this on both the stock "Support" queue, and now with a brand new 
"Testing" queue.


The setting I would suspect should change this, is queues->group 
rights->All, and then allowing "Create tickets" under "General 
rights", but I have also tried allowing this a dozen other places 
without luck :-(


As a test could you add Create Tickets to the global Everyone group and 
then try. RT Essentials (the book) has an example of that and for me it 
has worked several times in the past. Restricting Create Ticket to only 
certain queues will work but try to get the general one working first.
Thinking about general, what does your /etc/aliases look like, or 
how/where does you mail end up in RT?
My setup is that mail send to supp...@domain.nl will go to the General 
queue which is created as part of initdb and things like 
support-a...@domain.nl will go directly to the app1 queue. I'm 
suspecting that you have added Create Ticket to your Testing queue but 
that by default your mta is trying to use the General queue to create 
tickets which doesn't have Create Ticket.


Regards,

Joop

[rt-users] Unable to configure "open" queue

[Christian B. Wiik]

Hi.

We are a small company that got recommended this nice piece of software,
but have stranded on a small issue: We are unable to configure a "open"
queue, that allows everyone to create a ticket through incoming email.

Whatever we try we get the following two lines in syslog:
Ticket creation failed: Test 20: No permission to create tickets in the
queue 'Testing' (/opt/rt4/sbin/../lib/RT/Interface/Email.pm:248)
Could not record email: Ticket creation failed: No permission to create
tickets in the queue 'Testing'
(/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway
:75)

Tried this on both the stock "Support" queue, and now with a brand new
"Testing" queue.

The setting I would suspect should change this, is queues->group
rights->All, and then allowing "Create tickets" under "General rights", but
I have also tried allowing this a dozen other places without luck :-(

Any help is appreciated.

Regards
-- 
Christian B. Wiik