Re: [rt-users] RT 4.4.0 ShowHistory -> Scroll problem with French GUI

2016-06-17 Thread Emmanuel Lacour
Le 16/06/2016 à 19:54, Dustin Graves a écrit :
> Hi Guys,
> 
> Thanks for the fix, Emmanuel. We ended up doing it a little differently
> though with the JS I18N engine. You can see the
> branch 4.4/fix-history-scroll-js for the details. We are planning on
> merging the fix into 4.4.1.
> 

nice :)

(I lack JS knowledge :()

Do you think you have time to review some of my latest small patches
before 4.4.1:

https://issues.bestpractical.com/Search/Results.html?Format=%27+++%3Cb%3E%3Ca+href%3D%22%2FTicket%2FDisplay.html%3Fid%3D__id__%22%3E__id__%3C%2Fa%3E%3C%2Fb%3E%2FTITLE%3A%23%27%2C%0A%27%3Cb%3E%3Ca+href%3D%22%2FTicket%2FDisplay.html%3Fid%3D__id__%22%3E__Subject__%3C%2Fa%3E%3C%2Fb%3E%2FTITLE%3ASubject%27=ASC|ASC|ASC|ASC=id|||==Status+%3D+%27in-review%27+AND+Requestor.EmailAddress+%3D+%27elacour%40easter-eggs.com%27=100=new=
-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016


[rt-users] db upgrade - [error]: Condition 'On Forward Transaction' not found

2016-06-17 Thread Felix Defrance
Hi rt-users !

I have recently upgraded our RT from version 4.0.7 to 4.4.0.

I have used the rt-setup-database like this:

rt-setup-database --action upgrade --force --skip-create --upgrade-from
4.0.6 --upgrade-to 4.3.13

Some errors/warning was solved by executing  some 'insert' actions after
this first execution.

(i.e rt-setup-database --action insert --datafile
etc/upgrade/4.1.20/content --skip-create)

But for the 4.1.20 version, I have got two errors :

Processing 4.1.20

Now inserting data.
[21010] [Thu Jun 16 08:55:09 2016] [error]: Condition 'On Forward
Transaction' not found (/home/rt/rt/sbin/../lib/RT/Handle.pm:1360)
Trace begun at /home/rt/rt/sbin/../lib/RT.pm line 304
Log::Dispatch::__ANON__('Log::Dispatch=HASH(0x5d405e8)', 'Condition \'On
Forward Transaction\' not found') called at
/home/rt/rt/sbin/../lib/RT/Handle.pm line 1360
RT::Handle::InsertData('RT::Handle=HASH(0x61140c0)',
'./etc/upgrade/4.1.20/content', undef) called at
/home/rt/rt/sbin/rt-setup-database line 390
main::__ANON__ at /home/rt/rt/sbin/rt-setup-database line 403
main::action_insert('skip-create', 1, 'force', 1, 'backcompat',
'ARRAY(0x25d5b68)', 'action', 'upgrade', 'package', 'RT', 'datafile',
undef, 'datadir', './etc/upgrade/4.1.20', 'upgrade-from', 4.0.6,
'upgrade-to', 4.3.13) called at /home/rt/rt/sbin/rt-setup-database line 571
main::action_upgrade('package', 'RT', 'force', 1, 'action', 'upgrade',
'skip-create', 1, 'upgrade-to', 4.3.13, 'upgrade-from', 4.0.6) called at
/home/rt/rt/sbin/rt-setup-database line 210
[21010] [Thu Jun 16 08:55:09 2016] [error]: Condition 'On Forward
Ticket' not found (/home/rt/rt/sbin/../lib/RT/Handle.pm:1360)
Trace begun at /home/rt/rt/sbin/../lib/RT.pm line 304
Log::Dispatch::__ANON__('Log::Dispatch=HASH(0x5d405e8)', 'Condition \'On
Forward Ticket\' not found') called at
/home/rt/rt/sbin/../lib/RT/Handle.pm line 1360
RT::Handle::InsertData('RT::Handle=HASH(0x61140c0)',
'./etc/upgrade/4.1.20/content', undef) called at
/home/rt/rt/sbin/rt-setup-database line 390
main::__ANON__ at /home/rt/rt/sbin/rt-setup-database line 403
main::action_insert('skip-create', 1, 'force', 1, 'backcompat',
'ARRAY(0x25d5b68)', 'action', 'upgrade', 'package', 'RT', 'datafile',
undef, 'datadir', './etc/upgrade/4.1.20', 'upgrade-from', 4.0.6,
'upgrade-to', 4.3.13) called at /home/rt/rt/sbin/rt-setup-database line 571
main::action_upgrade('package', 'RT', 'force', 1, 'action', 'upgrade',
'skip-create', 1, 'upgrade-to', 4.3.13, 'upgrade-from', 4.0.6) called at
/home/rt/rt/sbin/rt-setup-database line 210


I don't know why the upgrade fail at the creation of these scrip.

In the web interface "Admin > Scrips" I have got nothing about "On
Forward Transaction" or "On Forward Ticket"

Thanks for the help,

-- 
Félix Defrance
PGP: 0x0F04DC57

-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016


Re: [rt-users] 4.2.12 & External Storage plugin errors

2016-06-17 Thread benjamin baugnies
I found the source of some of the issues:

Some files not being externalized -> Hardcoded threshold of 10Mb under
which images are not moved (this now a documented parameter in 4.4.0)
Files not available from web interface -> www-data apparently requires
execute permission on the directory to retrieve the files.


Didn't find the source of the segfaults, but its not an issue in 4.4.0



On 04/27/2016 11:08 AM, benjamin baugnies wrote:
> Hello,
>
> I'm currently working on a new installation of RT 4.2.12 on Ubuntu
> 14.04. The install was done using the standard instructions and the
> basics works. We were able to install several plugins including RT-IR
> 3.2.0 and everything worked fine.
>
> Now, I'm trying to use the External Storage plugin
> (https://metacpan.org/pod/RT::Extension::ExternalStorage), but I can't
> seem to get it to work consistently.
> The "extract-attachments" script does its job (the db is changed and the
> files are stored on disk), but in most cases the attachments are no
> longer accessible from the website. When testing with .docx documents
> for example, we usually get empty documents, or documents containing
> only "unknown encoding type: external". There were also many files which
> should have been moved but weren't (pictures, .html, and .csv files).
>
> More importantly, while the first Apache2 restart after the installation
> works (most of the time), I eventually get a segmentation fault and
> cannot start Apache again until the plugin is disabled:
> =
> Segmentation fault (core dumped)
> Action 'start' failed.
> The Apache error log may have more information.
> =
>
> The Apache log contains no information about the incident, and syslog
> only contains:
> /usr/sbin/apach[3785]: segfault at c ip b72791a1 sp bfa3b0d0 error 4 in
> libperl.so.5.18.2[b720e000+18d000]
>
>
>
> After failing with my current config, I tried using the plugin with the
> simplest configuration possible:
> =
> Set( $rtname, 'example.com');
>
> Set(%ExternalStorage,
> Type => 'Disk',
> Path => '/opt/rt4/var/attachments',
> );
> Plugin('RT::Extension::ExternalStorage');
> 1;
> =
> This still didn't work.
>
> I've also made sure www-data has read and write access to the
> attachments folder.
>
>
> Is there an issue with the plugin? Is it a problem with the version of
> RT we are using?
> Or am I just doing something wrong?
>
> Regards,
>


-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016


Re: [rt-users] Stalled tickets - Open on comment/reply?

2016-06-17 Thread Joel Bergmark
Hi,

You are right, thanks for the input.

I'm trying to set up a custom Lifecycle that I want to use in a few Queues, but 
seemingly I cant manage to get the configuration to be activated (Still only 
have the option Default, in the lifecycle dropdown.

Here is the config, from RT_SiteConfig.pm, server is rebooted after config 
change, is there something wrong with this or is it something changed in RT 
4.4.0?

Set(%Lifecycles, Kundservice => {
initial => [qw(new)], # loc_qw
active  => [qw(open)], # loc_qw
inactive=> [qw(stalled resolved rejected deleted)], # loc_qw
},
transitions => {
""   => [qw(new open resolved)],

# from   => [ to list ],
new  => [qw(open stalled resolved rejected deleted)],
open => [qw(new  stalled resolved rejected deleted)],
stalled  => [qw(new open rejected resolved deleted)],
resolved => [qw(new open stalled  rejected deleted)],
rejected => [qw(new open stalled resolved  deleted)],
deleted  => [qw(new open stalled rejected resolved)],
},
);

Thanks

Från: Zoey Schutt [mailto:z...@braincoral.io]
Skickat: den 16 maj 2016 14:46
Till: Joel Bergmark ; rt-users@lists.bestpractical.com
Ämne: Re: Stalled tickets - Open on comment/reply?


Hi Joel,



There is indeed a scrip that auto-changes the status of inactive tickets back 
to active when a customer replies. However, stalled is not considered an 
inactive status in the default life cycle. Feel free to correct me if I'm 
wrong, but due to this the built-in scrip will not change the status to open 
when a ticket gets updated while in stalled status.



Below is a portion of the default lifecycle, anything in inactive will cause 
the ticket's status to be updated.


default => {
initial => [qw(new)], # loc_qw
active  => [qw(open stalled)], # loc_qw
inactive=> [qw(resolved rejected deleted)], # loc_qw

Regards,



Zoey Schutt

Braincoral Technology, LLC


From: rt-users 
>
 on behalf of Joel Bergmark >
Sent: Thursday, May 12, 2016 2:30:01 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Stalled tickets - Open on comment/reply?

Perhaps this is not a bug, but stalled tickets that gets updated via email from 
external parties, didn't this previously change the status of the ticket to 
Open?

In RT 4.4 it seems not to work, and cant seem to make it work with custom scrip 
either (due to lack of perl skills).

Is this a bug or supposed to work in this way?

Regards
-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016


[rt-users] [rt-announce] New site for the RT Wiki

2016-06-17 Thread Jim Brandt

Hello RT Users,

Best Practical is moving the RT wiki to a new hosting site!

If you've used the RT community wiki over the years, you may have 
noticed the ads have increased quite a bit on Wikia. To make sure RT 
users have a productive environment to share their RT knowledge, we're 
moving to our own hosted wiki so you can focus just on reading about and 
sharing RT knowledge.


We need your help to complete the cut-over.

The new wiki is now available here:

https://rt-wiki.bestpractical.com

We have copied over all of the great content from the current wiki and 
now we'd like you to check the new site and confirm the content has been 
copied correctly. Also, we're unable to move the accounts, so we'd like 
you to sign up for a new account and try editing some pages.


Our plan is to welcome feedback for the next 2 weeks and fix any issues 
you discover. Assuming there are no major issues, on Wednesday, June 29, 
we're targeting a cut-over where we'll make the new wiki the primary RT 
wiki. Shortly after that, we'll work on turning off the version on Wikia.


You can see current changes and issues, and add new ones, here:

https://rt-wiki.bestpractical.com/index.php?title=Wikia_Move

Or send email to us at feedb...@bestpractical.com

We hope you like the new wiki site and as always, thanks for your help 
and support for RT!


Best Practical
___
rt-announce mailing list
rt-annou...@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce
-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016


Re: [rt-users] Reproducible RT Configuration management

2016-06-17 Thread Brian Duggan
We've built a set of Ansible playbooks around this role:

https://github.com/bcduggan/ansible-rt

The role doesn't depend on any other roles - it sets up
MariaDB and Apache itself. It assumes CentOS 7.x and can configure
SELinux, install multiple versions of RT 4.2.x. I'm going to add support
for installing different Perl versions. Right now, it just installs
5.10.1 through perlbrew.

Ansible best practices seem to assume that "one-shot" functions like
upgrading RT, exporting configuration, importing configuration, and
installing extras like RT extensions belong in playbooks. I would like
to find a way of shoehorning those functions into this role.

Brian

James A. Peltier writes:

> We script the base install including the setup of the base PERL/CPAN stuff, 
> the installation of the base RT base system using the typical make + make 
> install and then we run scripts to populate the RT database using scripts.  
> We have chosen _not_ to alter the base initial data file because we don't 
> want to have to keep track of any changes that may happen from version to 
> version.
>
> Since the database is provided by our database group we initialize the 
> database in the following way
>
>/opt/rt4/sbin/rt-setup-database --dba-password=$RT_DB_PASS --action init 
> --skip-create
>
> This creates the database shell with just the default content to get a 
> functioning RT install.  We then enable full text searching using
>
>   /opt/rt4/sbin/rt-setup-fulltext-index --dba ${RT_DB_USER} --dba-password 
> ${RT_DB_PASS} --table=AttachmentsIndex --column=ContentIndex --index-type=GIN
>
> followed by installing any plugins that we need to install using a git 
> checkout + make + make install + make initdb (if required).  We version 
> control all the configuration files and drop them into place when needed.
>
> So far this has allowed us to get a fully reproducible base installation of 
> RT.  We then apply our scripts to add custom fields, populate their values, 
> make changes to initial data configurations such as default templates and 
> scrips, etc.
>
> This makes for an easy way to create the base RT with all our customizations. 
>  We only run this if we're running tests to ensure that starting from scratch 
> still works as expected, otherwise we make a backup of the database and just 
> restore that because it's _so much faster_.
>
> - Original Message -
> | 
> | Hi,
> | 
> | I've had a look through the list archives and seen a couple of mentions
> | of this but nothing recent and thought I'd ask again in case there is
> | something new out there.
> | 
> | What are people doing to manage reproducable deployments of RT other
> | than just dumping the database of a production machine and loading on a
> | development one.
> | 
> | I am using puppet currently to deploy RT.
> | 
> | Puppet does a good job of getting RT installed and running.
> | 
> | I am struggling with how to manage the RT configuration itself, the
> | stuff that is done from within the web interface or from initialdata
> | using rt-setup-database.
> | 
> | We use vagrant for the development environment and the ideal situation
> | is that running "vagrant up" will bring up a copy of RT running the
> | latest config.
> | 
> | I want all changes on the production machines done not by the web
> | interface but in some sort of reproducable way.
> | 
> | What I have so far is a hacked up solution using a custom script to call
> | rt_setup_database and using my own custom fragments to init the data.
> | 
> | The main issue here is I wanted it to be idempotent so if called from
> | puppet no harm is done if it has already made the change.
> | 
> | So far I'm doing ugly things like using the @Init section to check if a
> | particular change exists in the database already and not making it if it
> | does.  This also prevents adding multiple entries for things when the
> | code is run multiple times.
> | 
> | My solution is working although it feels clunky.
> | 
> | I guess one better option would be a full puppet implementation modeling all
> | of
> | Rt's configuration.  That just felt like a job far too big to tackle :(.
> | 
> | Does anyone have any suggestions or stories of how they are managing
> | this situation?
> | 
> | Kind regards
> | Bart
> | --
> | 
> | Bart Bunting - URSYS
> | PH: 02 87452811
> | Mbl: 0409560005
> | -
> | RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
> | * Los Angeles - September, 2016
> | 

-- 
Brian [he/him/his]
Composed in Emacs
-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016


Re: [rt-users] Reproducible RT Configuration management

2016-06-17 Thread Bart Bunting
Hi,

Sorry for the slow reply.

That is more or less what I have using puppet scripts.

The question I am struggling with is that if we are to write scripts
every time a change is required, e.g. an admin cc is added to a queue
etc it is a time consuming process and I am questioning the effort
involved

I had hoped that rt-dump-metadata would be a useful tool to assist in
seeing which changes had been made by hand and then either used to
update the initialdata or create scripts to ensure the database was
consistent.

It appears that there are bugs in rt-dump-metadata.

When anything to do with a custom field is changed in the UI
rt-dump-metadata subsequently bombs out:

./sbin/rt-dump-metadata
[3047] [Sat Jun 18 01:34:29 2016] [critical]: RT::CustomField::AppliedTo 
Unimplemented in main. (./sbin/rt-dump-metadata line 187)  
(/opt/rt4/sbin/../lib/RT.pm:390)
RT::CustomField::AppliedTo Unimplemented in main. (./sbin/rt-dump-metadata line 
187) 
.   

I guess this is a question for the Bestpractical folks is
rt-dump-metadata going to be supported ongoing or is it something that
isn't really best practice to use any more?

The git log suggests it hasn't been worked on much recently but then
again it could just mean there haven't been any recent issues found.

Any advice most welcome.


Kind regards

Bart

"James A. Peltier"  writes:

> We script the base install including the setup of the base PERL/CPAN stuff, 
> the installation of the base RT base system using the typical make + make 
> install and then we run scripts to populate the RT database using scripts.  
> We have chosen _not_ to alter the base initial data file because we don't 
> want to have to keep track of any changes that may happen from version to 
> version.
>
> Since the database is provided by our database group we initialize the 
> database in the following way
>
>/opt/rt4/sbin/rt-setup-database --dba-password=$RT_DB_PASS --action init 
> --skip-create
>
> This creates the database shell with just the default content to get a 
> functioning RT install.  We then enable full text searching using
>
>   /opt/rt4/sbin/rt-setup-fulltext-index --dba ${RT_DB_USER} --dba-password 
> ${RT_DB_PASS} --table=AttachmentsIndex --column=ContentIndex --index-type=GIN
>
> followed by installing any plugins that we need to install using a git 
> checkout + make + make install + make initdb (if required).  We version 
> control all the configuration files and drop them into place when needed.
>
> So far this has allowed us to get a fully reproducible base installation of 
> RT.  We then apply our scripts to add custom fields, populate their values, 
> make changes to initial data configurations such as default templates and 
> scrips, etc.
>
> This makes for an easy way to create the base RT with all our customizations. 
>  We only run this if we're running tests to ensure that starting from scratch 
> still works as expected, otherwise we make a backup of the database and just 
> restore that because it's _so much faster_.
>
> - Original Message -
> | 
> | Hi,
> | 
> | I've had a look through the list archives and seen a couple of mentions
> | of this but nothing recent and thought I'd ask again in case there is
> | something new out there.
> | 
> | What are people doing to manage reproducable deployments of RT other
> | than just dumping the database of a production machine and loading on a
> | development one.
> | 
> | I am using puppet currently to deploy RT.
> | 
> | Puppet does a good job of getting RT installed and running.
> | 
> | I am struggling with how to manage the RT configuration itself, the
> | stuff that is done from within the web interface or from initialdata
> | using rt-setup-database.
> | 
> | We use vagrant for the development environment and the ideal situation
> | is that running "vagrant up" will bring up a copy of RT running the
> | latest config.
> | 
> | I want all changes on the production machines done not by the web
> | interface but in some sort of reproducable way.
> | 
> | What I have so far is a hacked up solution using a custom script to call
> | rt_setup_database and using my own custom fragments to init the data.
> | 
> | The main issue here is I wanted it to be idempotent so if called from
> | puppet no harm is done if it has already made the change.
> | 
> | So far I'm doing ugly things like using the @Init section to check if a
> | particular change exists in the database already and not making it if it
> | does.  This also prevents adding multiple entries for things when the
> | code is run multiple times.
> | 
> | My solution is working although it feels clunky.
> | 
> | I guess one better option would be a full puppet implementation modeling all
> | of
> | Rt's configuration.  That just felt like a job far too big to tackle :(.
> | 
> | Does anyone have any suggestions or stories of how they are managing
> | this situation?
> | 
> | Kind regards
> | Bart
> | --
> | 
> | Bart Bunting - 

[rt-users] Anyone know how to create a clickable link like this?

2016-06-17 Thread Mike Johnson
So, easy to create a link in the emails triggered by scrips... but, I see
Zendesk(another ticketing system) that I interact with for another software
we run onsite sends emails that show up in GMail with this cool little
button...

[image: Inline image 1]

Anyone know what creates this and has anyone tried making something like
this within RT templates?

-- 
Mike Johnson
Datatel Programmer/Analyst
Northern Ontario School of Medicine
955 Oliver Road
Thunder Bay, ON   P7B 5E1
Phone: (807) 766-7331
Email: mike.john...@nosm.ca
-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016


Re: [rt-users] Anyone know how to create a clickable link like this?

2016-06-17 Thread Dustin Graves
Hi Mike,

This is a pretty neat idea. I looked into it a bit and it seems to be what 
Gmail calls a ‘Go-To Action’ 
https://developers.google.com/gmail/markup/reference/go-to-action 


I couldn’t get it to work in my first pass, but Gmail was also flagging my test 
RT as spam so I don’t know if that has something to do with the link not 
showing up.

I’ll play around with it a little more when I get the chance.

Thank you,
Dustin

> On Jun 17, 2016, at 11:15 AM, Mike Johnson  wrote:
> 
> So, easy to create a link in the emails triggered by scrips... but, I see 
> Zendesk(another ticketing system) that I interact with for another software 
> we run onsite sends emails that show up in GMail with this cool little 
> button...
> 
> 
> 
> Anyone know what creates this and has anyone tried making something like this 
> within RT templates?
> 
> -- 
> Mike Johnson
> Datatel Programmer/Analyst
> Northern Ontario School of Medicine
> 955 Oliver Road
> Thunder Bay, ON   P7B 5E1
> Phone: (807) 766-7331
> Email: mike.john...@nosm.ca -
> RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
> * Los Angeles - September, 2016

-
RT 4.4 and RTIR Training Sessions https://bestpractical.com/training
* Los Angeles - September, 2016