Re: [rt-users] Upgrade fail
Upgrading in stages did solve the problem. I downloaded version 3.9.7 which is the version Lifecycle was introduced. Upgrading using this version and then upgrading using the latest version of the code completed without errors. From the log I believe I am now on 4.2.10. I'll back up and restore the unupgraded database to reproduce the complete error message. ~Joshua On Fri, Feb 6, 2015 at 2:02 PM, Alex Vandiver ale...@bestpractical.com wrote: On Fri, 6 Feb 2015 13:44:06 -0500 Joshua Lansford joshua.lansf...@laserlinc.com wrote: Ok. So I have done some additional investigation and here is what I have found. The new Queues table has two new fields named Lifecycle and SubjectTag. Lifecycle field is accessed in the RT::Init which is called at the top of action_insert before it can do the insert portion of the first upgrade step... I think. It is looking like the code is assuming stuff about the database structure which isn't true just in trying to set up to do the upgrade steps. Please show the complete output of 'make upgrade-database', not just a small snippet. I suppose this means I am trying to jump too many versions at once and I need to do an intermediate upgrade at an intermediate step. Probably at the version which introduces these columns. If that version couldn't have upgraded everyone would have gotten stuck. It shouldn't be necessary to to the upgrade in multiple steps. - Alex
Re: [rt-users] Upgrade fail
On Fri, 6 Feb 2015 13:44:06 -0500 Joshua Lansford joshua.lansf...@laserlinc.com wrote: Ok. So I have done some additional investigation and here is what I have found. The new Queues table has two new fields named Lifecycle and SubjectTag. Lifecycle field is accessed in the RT::Init which is called at the top of action_insert before it can do the insert portion of the first upgrade step... I think. It is looking like the code is assuming stuff about the database structure which isn't true just in trying to set up to do the upgrade steps. Please show the complete output of 'make upgrade-database', not just a small snippet. I suppose this means I am trying to jump too many versions at once and I need to do an intermediate upgrade at an intermediate step. Probably at the version which introduces these columns. If that version couldn't have upgraded everyone would have gotten stuck. It shouldn't be necessary to to the upgrade in multiple steps. - Alex
Re: [rt-users] Queue Admin, not RT Admin
On 5 Feb 2015, at 10:07, Lewis, Valerie wrote: I have recently become one of the campus administrators for our RT system. As a result, I am fielding a lot of requests from staff for privledges to different queues. One in particular is a director within IT wanting to be admin for queues that pertain to his department. I have gone into the queue and went to modify user rights for queue and gave him all of the rights under Rights for Administrators. However, he not able to utilize any of those rights within his queues. I don't want him to be an overall administrator, just over his queues. Am I missing something big? I haven't found any explanation of this online anywhere. Any help would be greatly appreciated. Possibly: At the bottom of /Admin/Global/UserRights.html = Rights for Administrators the Show Admin Menu right is critical. That's assuming you're using 4.2.x. In older versions you may see it called ShowConfigTab. And yes, there is no good comprehensive documentation for RT rights. There is some useful info in the Wikia site, some useful info in the docs at Best Practical, in both cases including bits and pieces lurking in pages where you'll never find them without reading just about everything. The Rights system is also counter-intuitive, as a virtue of it being logically rigorous and extremely fine-grained. It helps in working out where a Rights problem is to think carefully about the specific mode of I can't do $x the user is running into. For example, the general he not able to utilize any of those rights description is vague enough that my guess about the ShowConfigTab right could be entirely wrong. You can *usually* find where you need to check Yet Another Right by figuring out what part of the UI the user doesn't see, because RT usually will not show the UI to do something that a user isn't allowed to do.
Re: [rt-users] Problem with attachments
Both templates contain RT-Send-Attachment: yes as second row. Yesterday I did some more experiments, unfortunately without success. Cris On 04/02/2015 20:03, Alex Vandiver wrote: On Wed, 4 Feb 2015 18:26:36 + Guadagnino Cristiano guadagnino.cristi...@creval.it wrote: Thank you Alex, so basically my test is correct and my problem is not solved. Back to the drawing board :-( Let's see if I can give some more detail, to help you in helping me :-) Those two mails are sent by different scrips. Check that the template for the latter scrip has RT-Send-Attachment: yes in the headers section. - Alex
[rt-users] Upgrade fail
Hello. I am trying to upgrade from 3.8.11 to stable and make upgrade-database is bombing. The error message is = 9449] [Thu Feb 5 19:23:36 2015] [critical]: DBD::mysql::db selectcol_arrayref failed: Unknown column 'main.Lifecycle' in 'field list' at /usr/local/share/perl/5.18.2/DBIx/SearchBuilder.pm line 635. (/home/user/temp/rt/sbin/../lib/RT.pm:388) DBD::mysql::db selectcol_arrayref failed: Unknown column 'main.Lifecycle' in 'field list' at /usr/local/share/perl/5.18.2/DBIx/SearchBuilder.pm line 635. make: *** [upgrade-database] Error 255 = I setup a fresh vm for this job to test. I was able to set up RT from stable just fine without an upgrade. So then I dropped that rt4 database, deleted the /opt/rt4 install folder, dumped the rtdb old database to a sql file. Copied the sql dump over to the vm. Imported it as rt4. Did make upgrade to recreate the rt4 folder. Configured the database user and password in RT_SiteConfig.pm. Granted permissions to the rt4 user with that password to the rt4 folder and hit make upgrade-database. After giving the root mysql password the above error is presented. Assistance at this point would be appreciated. Let me know what additional information I can provide. Thank you, ~Joshua
Re: [rt-users] Problem with attachments
On 02/06/2015 06:32 AM, Guadagnino Cristiano wrote: Both templates contain RT-Send-Attachment: yes as second row. Yesterday I did some more experiments, unfortunately without success. Cris On 04/02/2015 20:03, Alex Vandiver wrote: On Wed, 4 Feb 2015 18:26:36 + Guadagnino Cristiano guadagnino.cristi...@creval.it wrote: Thank you Alex, so basically my test is correct and my problem is not solved. Back to the drawing board :-( Let's see if I can give some more detail, to help you in helping me :-) Those two mails are sent by different scrips. Check that the template for the latter scrip has RT-Send-Attachment: yes in the headers section. - Alex Magic headers need to be in the first paragraph. If the first line is blank remove it. Make sure there is a blank line after RT-Send-Attachment and before the main template.
Re: [rt-users] Problem with attachments
Jeff, thank you for your reply. My templates have not been varied in the last couple of years. Anyway, here is my correspondence template (which is working): Content-Type: text/html RT-Attach-Message: yes From: { my $u = $Transaction-CreatorObj; my $a = $Ticket-QueueObj-CorrespondAddress; $a = $Ticket-QueueObj-CommentAddress if ( $Transaction-Type eq 'Comment' ); my $res = $u-RealName || $u-Name; $res .= .$a . ; $res; } {$Transaction-Content()} And here is (part of) my resolved template, which suddenly is not working anymore (i.e. files are not attached): Content-Type: text/html RT-Attach-Message: yes Subject: {$Ticket-Subject} h2Risoluzione:/h2/a p { my $Transactions = $Ticket-Transactions; $Transactions-Limit( FIELD = 'Type', VALUE = 'Comment' ); $Transactions-OrderByCols ( { FIELD = 'Created', ORDER = 'DESC' }, { FIELD = 'id', ORDER = 'DESC' }, ); my $resolution_comment; my $CommentObj = $Transactions-First; if( $CommentObj $CommentObj-id ) { $resolution_comment = $CommentObj-Content; } $resolution_comment; } (...) Thank you in advance. Cris On 06/02/2015 13:06, Jeff Voskamp wrote: Magic headers need to be in the first paragraph. If the first line is blank remove it. Make sure there is a blank line after RT-Send-Attachment and before the main template.
Re: [rt-users] use customFields extracted by ExtractCustomFieldValues in creation mail
Arnaud, You need to make sure the scrips are running in the right sequence. You do this by setting the execution to transaction batch and give them names that ensure the correct sequence. Kenn Sent from my Windows PhoneFrom: Arnaud Abélard Sent: 2/6/2015 8:29 AM To: rt-users@lists.bestpractical.com Subject: [rt-users] use customFields extracted by ExtractCustomFieldValues in creation mail Hello, I have a working instance of RT 4.2.9. Everything has been running as expected for years (started with RT 3.8). I have a few queues that use custom fields. Upon the creation of a new ticket, a mail is sent to the queue administrator with the list of the queue's custom fields and their value and the body of the ticket. This works well when the ticket is created from RT. Now, I have been trying to use the ExtractCustomFieldValues extension to extract my custom fields from an email. That actually works. The custom fields are set properly in the ticket but in the mail sent to the queue admins, the custom fields value are missing. In my template (which works fine when the ticket is created from RT) I used the following code: { my $res = ; my $customFields = $Ticket-QueueObj-TicketCustomFields(); while ( my $customField = $customFields-Next) { $res.= $customField-Name.: .$Ticket-FirstCustomFieldValue($customField-Name).\n; } $res; } I am also sure that my extractCustomField scrip is being executed _before_ my oncreation scrip (scrip #50 is my extractcustomvalue scrip and scrip #15 my oncreation sent mail to queue admins: Feb 6 17:14:21 rt4 RT: [19913] Committing scrip #50 on txn #90275 of ticket #3782 (/opt/rt4/sbin/../lib/RT/Scrips.pm:306) ... Feb 6 17:14:21 rt4 RT: [19913] CustomFieldValue (Numéro de porte,123) added: 5355 Numéro de porte 123 added ... Feb 6 17:14:21 rt4 RT: [19913] CustomFieldValue (UMR,915) added: 5356 UMR 915 added ... Feb 6 17:14:21 rt4 RT: [19913] CustomFieldValue (Numéro de téléphone,123) added: 5357 Numéro de téléphone 123 added ... Feb 6 17:14:21 rt4 RT: [19913] Committing scrip #15 on txn #90275 of ticket #3782 (/opt/rt4/sbin/../lib/RT/Scrips.pm:306) Feb 6 17:14:21 rt4 RT: [19913] Calling SetRecipientDigests for transaction RT::Transaction=HASH(0x7f91d5eadf40), id 90275 (/opt/rt4/sbin/../lib/RT/Action/SendEmail.pm:623) ... The log confirms the customfield are set before the mail is sent so why aren't the values set when queried from my template? Thanks in advance, Arnaud Abélard -- Arnaud Abélard (jabber: arnaud.abel...@univ-nantes.fr) Administrateur Système - Responsable Services Web Direction des Systèmes d'Informations Université de Nantes - ne pas utiliser: trapem...@univ-nantes.fr
[rt-users] use customFields extracted by ExtractCustomFieldValues in creation mail
Hello, I have a working instance of RT 4.2.9. Everything has been running as expected for years (started with RT 3.8). I have a few queues that use custom fields. Upon the creation of a new ticket, a mail is sent to the queue administrator with the list of the queue's custom fields and their value and the body of the ticket. This works well when the ticket is created from RT. Now, I have been trying to use the ExtractCustomFieldValues extension to extract my custom fields from an email. That actually works. The custom fields are set properly in the ticket but in the mail sent to the queue admins, the custom fields value are missing. In my template (which works fine when the ticket is created from RT) I used the following code: { my $res = ; my $customFields = $Ticket-QueueObj-TicketCustomFields(); while ( my $customField = $customFields-Next) { $res.= $customField-Name.: .$Ticket-FirstCustomFieldValue($customField-Name).\n; } $res; } I am also sure that my extractCustomField scrip is being executed _before_ my oncreation scrip (scrip #50 is my extractcustomvalue scrip and scrip #15 my oncreation sent mail to queue admins: Feb 6 17:14:21 rt4 RT: [19913] Committing scrip #50 on txn #90275 of ticket #3782 (/opt/rt4/sbin/../lib/RT/Scrips.pm:306) ... Feb 6 17:14:21 rt4 RT: [19913] CustomFieldValue (Numéro de porte,123) added: 5355 Numéro de porte 123 added ... Feb 6 17:14:21 rt4 RT: [19913] CustomFieldValue (UMR,915) added: 5356 UMR 915 added ... Feb 6 17:14:21 rt4 RT: [19913] CustomFieldValue (Numéro de téléphone,123) added: 5357 Numéro de téléphone 123 added ... Feb 6 17:14:21 rt4 RT: [19913] Committing scrip #15 on txn #90275 of ticket #3782 (/opt/rt4/sbin/../lib/RT/Scrips.pm:306) Feb 6 17:14:21 rt4 RT: [19913] Calling SetRecipientDigests for transaction RT::Transaction=HASH(0x7f91d5eadf40), id 90275 (/opt/rt4/sbin/../lib/RT/Action/SendEmail.pm:623) ... The log confirms the customfield are set before the mail is sent so why aren't the values set when queried from my template? Thanks in advance, Arnaud Abélard -- Arnaud Abélard (jabber: arnaud.abel...@univ-nantes.fr) Administrateur Système - Responsable Services Web Direction des Systèmes d'Informations Université de Nantes - ne pas utiliser: trapem...@univ-nantes.fr
Re: [rt-users] Upgrade fail
Ok. So I have done some additional investigation and here is what I have found. The new Queues table has two new fields named Lifecycle and SubjectTag. Lifecycle field is accessed in the RT::Init which is called at the top of action_insert before it can do the insert portion of the first upgrade step... I think. It is looking like the code is assuming stuff about the database structure which isn't true just in trying to set up to do the upgrade steps. I suppose this means I am trying to jump too many versions at once and I need to do an intermediate upgrade at an intermediate step. Probably at the version which introduces these columns. If that version couldn't have upgraded everyone would have gotten stuck. Sound plausible? ~Joshua On Fri, Feb 6, 2015 at 7:05 AM, Joshua Lansford joshua.lansf...@laserlinc.com wrote: Hello. I am trying to upgrade from 3.8.11 to stable and make upgrade-database is bombing. The error message is = 9449] [Thu Feb 5 19:23:36 2015] [critical]: DBD::mysql::db selectcol_arrayref failed: Unknown column 'main.Lifecycle' in 'field list' at /usr/local/share/perl/5.18.2/DBIx/SearchBuilder.pm line 635. (/home/user/temp/rt/sbin/../lib/RT.pm:388) DBD::mysql::db selectcol_arrayref failed: Unknown column 'main.Lifecycle' in 'field list' at /usr/local/share/perl/5.18.2/DBIx/SearchBuilder.pm line 635. make: *** [upgrade-database] Error 255 = I setup a fresh vm for this job to test. I was able to set up RT from stable just fine without an upgrade. So then I dropped that rt4 database, deleted the /opt/rt4 install folder, dumped the rtdb old database to a sql file. Copied the sql dump over to the vm. Imported it as rt4. Did make upgrade to recreate the rt4 folder. Configured the database user and password in RT_SiteConfig.pm. Granted permissions to the rt4 user with that password to the rt4 folder and hit make upgrade-database. After giving the root mysql password the above error is presented. Assistance at this point would be appreciated. Let me know what additional information I can provide. Thank you, ~Joshua