Re: [rt-users] RT::Extension::Assets - missing Wikitext area and Select date widgets on Bulk Update
On Thu, 2014-04-10 at 12:32 +1200, Kevin Buckley wrote: Bingo! Will give that a go: thanks. Please keep all replies on-list. Can I also assume that the 4.2.3 plus patch additions would cure what I've seen in the log, since trying to add in in the RT::Extension::Assets::Import::CSV module, namely the three criticals [3757] [Thu Apr 10 00:14:11 2014] [info]: Successful login for root from 127.0.0.1 (/opt/rt4/sbin/../lib/RT/Interface/Web.pm:819) [3755] [Thu Apr 10 00:14:38 2014] [critical]: Unknown CustomField type: Wikitext (/opt/rt4/share/html/Elements/BulkCustomFields:81) [3755] [Thu Apr 10 00:14:38 2014] [critical]: Unknown CustomField type: Date (/opt/rt4/share/html/Elements/BulkCustomFields:81) [3755] [Thu Apr 10 00:14:38 2014] [critical]: Unknown CustomField type: Date (/opt/rt4/share/html/Elements/BulkCustomFields:81) which I don't get without the CSV import model in ? The CSV import module is totally unrelated to those warnings. Those warnings show up on the bulk page of any search (of tickets or assets) which contains Wikitext or Date CFs. But yes, running 4.2.3 plus the patch I linked will quiet those warnings. - Alex -- RT Training - Dallas May 20-21 http://bestpractical.com/training
[rt-users] [rt-announce] RT 3.8 reaches End-of-Life
As previously announced, the 3.8 series of RT has now reached end-of-life, and is no longer supported by Best Practical. This also ends support for RTFM, as well as RTIR 2.4 and 2.6, as those products depended on RT 3.8. Best Practical continues to support the RT 4.0 (maintenance) series, as well as RT 4.2 (stable). RTFM was integrated into RT 4.0 as Articles, and is thus forward-compatible. RTIR 3.0 is available for RT 4.0, and we expect release candidates for RTIR 3.2 (compatible with RT 4.2) to be available shortly. If you are currently still running RT 3.8 (or earlier!) and would like help with your upgrade, you can get in touch with us at sa...@bestpractical.com for professional assistance. - Alex, for Best Practical ___ rt-announce mailing list rt-annou...@lists.bestpractical.com http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce -- RT Training - Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] RT.Articles table doesn't exist
On Tue, 2014-04-01 at 14:04 +, GARCIA PEREZ, Alberto (Alberto)** CTR ** wrote: After upgrading my RT from 3.6.6 to 4.0.4 the rt.log displays the next warning: Why upgrade to 4.0.4, which has published security vulnerabilities, rather than 4.0.19? [Tue Apr 1 13:43:24 2014] [warning]: DBD::mysql::st execute failed: Table 'rt4.Articles' doesn't exist at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 589. (/usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm:589) This implies you didn't run the database upgrade steps like the README tells you to. You will have much bigger problems than merely missing the Articles table; since you're on MySQL and coming up from before 3.8, by skipping upgade steps, your Attachments table may be corrupted. Please re-read step 6b of the README [1], as well as UPGRADING.mysql [2]. - Alex [1] http://bestpractical.com/docs/rt/4.0/README.html [2] http://bestpractical.com/docs/rt/4.0/UPGRADING.mysql.html [Tue Apr 1 13:43:24 2014] [warning]: RT::Handle=HASH(0x7fc31873b970) couldn't execute the query 'SELECT COUNT(DISTINCT main.id) FROM Articles main JOIN Classes Classes_1 ON ( Classes_1.id = main.Class ) JOIN ObjectClasses ObjectClasses_2 ON ( ObjectClasses_2.Class = main.Class ) WHERE (Classes_1.HotList = '1') AND ( ( ObjectClasses_2.ObjectId = '21' AND ObjectClasses_2.ObjectType = 'RT::Queue' ) OR ( ObjectClasses_2.ObjectId = '0' AND ObjectClasses_2.ObjectType = 'RT::System' ) ) ' at /usr/local/share/perl/5.14.2/DBIx/SearchBuilder/Handle.pm line 602. I have searched for the Articles table in the DB but it doesn't exist. Can anybody help me with this issue? How can I create this table? Regards. Alberto García Pérez alberto.garcia_pe...@alcatel-lucent.com UCM TEAM -- RT Training - Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Upgrade
On Wed, 2014-03-26 at 13:08 +, Bryon Baker wrote: Where can I find instructions on how to apply this patch? GET https://github.com/bestpractical/rt/commit/7d100f10.patch | patch -p1 -d /opt/rt4 Clear your Mason cache and restart Apache. - Alex -- RT Training - Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] RT::Authen::ExternalAuth + mod_ssl = core dump
On Thu, 2014-03-27 at 16:01 -0500, Dewhirst, Rob wrote: I can get RT up and running just fine using LDAP with RT::Authen::ExternalAuth. But as soon as I shut down the server and install mod_ssl, apache won't restart, segfaults. What version of RT and Apache? I presume you're running with a mod_perl deployment? - Alex -- RT Training - Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] RT::Authen::ExternalAuth + mod_ssl = core dump
On Thu, 2014-03-27 at 16:42 -0500, Dewhirst, Rob wrote: RT 4.0.19 (because of RTIR) mod_perl Interesting; we've seen another report of this previously, but I've been unable to replicate it. It's presumably caused by a disagreement of mod_ssl with the SSL libraries that perl uses for LDAPS support -- and since mod_perl is in use, those two exist in the same process, and their disagreements lead to coredumps. We addressed a similar problem with mod_ssl and TLS connections to Postgres early in the 4.0 series. The simple work-around is to switch from mod_perl to one of the fastcgi deployment strategies, which separates the mod_ssl OpenSSL stack from perl's LDAPS OpenSSL stack, allowing them to play well together. However, I'd love to have a simple replication strategy to help track this down and fix it. How stock an RT install is this? I presume you're running with the standard Apache and mod_perl installs from RPMs? Can you provide your RT::Authen::ExternalAuth configuration? - Alex -- RT Training - Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Upgrade
On Wed, 2014-03-26 at 02:20 +, Bryon Baker wrote: I just upgrade from 4.2.0 to 4.2.3 I thought this was going to fix the auto fill for email addresses when forwarding messages. Was this not true? Did I miss something? This is not true. I don't believe we've ever said that 4.2.3 does that. The branch is still pending review. You can apply the patch to your local instance if you'd like: https://github.com/bestpractical/rt/commit/7d100f10.patch - Alex -- RT Training - Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Need help with Error Message
On Mon, 2014-03-24 at 20:48 +, Bryon Baker wrote: When replying from the transaction section of a ticket we get the following exception thrown in the error log. [snip] This was fixed in RT 4.2.2. The error will still occur in your logs, and the outgoing email will not have a text/plain part, but the mail will at least be sent -- unlike in 4.2.0 and 4.2.1. - Alex -- RT Training - Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Multiple attachments for unprivileged users?
On Thu, 2014-03-20 at 11:31 +0100, Jan Niezbędny wrote: [snip] Keep replies on-list. It works but only when unpriviliged user make new ticket by sending email. It's realy impossible to add button Add more files for unprivileged users in RT v4.0.4 because at this moment i can't upgrade RT to v4.2 Apparently I mis-spoke, and it's in 4.0.12 and above as well. If you're still running 4.0.4, we strongly recommend upgrading, as there have been three security releases since 4.0.4. As always, upgrading within a stable series is always meant to be mostly painless: http://bestpractical.com/rt/release-policy.html - Alex -- RT Training - Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Callback with no TicketObject arg, guidance needed
On Thu, 2014-03-20 at 17:28 -0400, Jeff Blaine wrote:
if (! $showchildren) {
# In theory, this should exclude all fields in @childfields
$CustomFields-Limit(FIELD = 'Name', OPERATOR = '!=', VALUE =
'$_', ENTRYAGGREGATOR = 'AND', CASESENSITIVE = 0) for (@childfields);
}
Perl only interpolates variables in double quotes, not single quotes.
You want « VALUE = $_ »
or « VALUE = $_ »
not « VALUE = '$_' »
- Alex
--
RT Training - Dallas May 20-21
http://bestpractical.com/training
Re: [rt-users] Callback with no TicketObject arg, guidance needed
On Tue, 2014-03-18 at 15:55 -0400, Jeff Blaine wrote:
This callback in share/html/Elements/EditCustomFields does not pass
$TicketObj (and it could, but was ommitted, perhaps on purpose?):
%INIT
...
$m-callback( %ARGS, CallbackName = 'MassageCustomFields',
CustomFields = $CustomFields );
...
/%INIT
In my MassageCustomFields callback code (per above), I am trying to
determine if a certain CF has a value of /no/i
Given the arguments available to me in the callback, I am not sure how
to do that. All of my work in the past has involved method calls on
$TicketObj.
Debug-printing the contents of %ARGS from inside the MassageCustomFields
callback, I see that ARGS{'Object'} = 'RT::Ticket=HASH(0x7f0b5b540db8)
Just use that as my $TicketObj? Is that sane/safe?
Yes -- ish. Note that custom fields can exist on things that aren't
tickets, and Elements/EditCustomFields is also used for them. All
that's promised is that $Object ISA RT::Record, so you should check
$Object-isa(RT::Ticket) before you carry on.
Additionally, if my intention is to ultimately use MassageCustomFields
to modify $CustomFields, isn't that going to fail due to the callback
not being passed a hash _reference_ ?
$CustomFields is an object (which are references). So if you modify the
object (by calling -Limit on it, for instance) those changes are
preserved in the calling site. You can't say $CustomFields =
RT::CustomFields-new(...), but you can $CustomFields-CleanSlate and
then re-add arbitrary limits.
- Alex
--
RT Training - Dallas May 20-21
http://bestpractical.com/training
Re: [rt-users] Multiple attachments for unprivileged users?
On Wed, 2014-03-19 at 17:51 +0100, Jan Niezbędny wrote: At this moment unprivilged users making a new ticket by web interface can only add one attachment. Is it possible to change it in such way that they can added a multiple attachments? RT 4.2 includes that functionality. - Alex -- RT Training - Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Callback with no TicketObject arg, guidance needed
On Wed, 2014-03-19 at 11:57 -0400, Jeff Blaine wrote: Follow-up question if I may: How might I exclude fields X, Y, Z from $CustomFields in my callback? # Repeat for each name to exclude: $CustomFields-Limit( FIELD= 'Name', OPERATOR = '!=', VALUE= 'SomeNameToExclude', ENTRYAGGREGATOR = 'AND', ); I'm not familiar with Limit (and hopefully its friends). Should I just perldoc these files where 'sub Limit ' is found and start digging around for comprehension? Limit comes from DBIx::SearchBuilder - https://metacpan.org/pod/DBIx::SearchBuilder#Limit - Alex -- RT Training - Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Full text search/index - Migrate to Postgres or MySQL + Sphinx?
On Thu, 2014-03-13 at 14:47 +, Mark Goodge wrote: I know that RT uses InnoDB by default but there should be no reason why the table you want to search can't be converted to MyISAM. There's a very straightforward reason why RT uses InnoDB: database-level transactions. Converting the Attachments table to MyISAM would break a notable number of internals. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] rt-serializer and rt-importer
On Tue, 2014-03-11 at 08:51 -0700, Tim Gustafson wrote: And one last follow-up about this: here are my import statistics. The importer used up to about 800MB of RAM, so better than the serializer, but still pretty high. Both of those (6G for serializing, and 800M for importing) are definitely higher than I'd expect. If you're on 4.2.2, then you have the fixes to explicitly turn off the caching layer. If you're interested in poking further, doing some analysis of the in-memory objects to determine what's leaking would be helpful. Instrumenting the main loop of either of the serializer or importer with Devel::Gladiator::arena_ref_counts to look for what sorts of objects are leaking might be instructive. Also, 108 hours seems like a long time to import records that took only 4 hours to export, and this is on a pretty high-end MySQL server. Is there any way to speed things up a bit? Yeesh, that's pretty bad. I'd try running under Devel::NYTProf to see where the hotspots are -- I don't have any off-the-cuff suggestions. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Problems, with extension Assets.
On Tue, 2014-03-11 at 09:44 +0100, Emmanuel Lacour wrote: I am using Debian 7.3, with request tracker 4.2.3 built from source. I am also using the external auth extension, so i can use our Active Directory database for authentication. Does it work if you temporarily disable RT::Authen::ExternalAuth? It seems to be related to this bug: http://issues.bestpractical.com/Ticket/Display.html?id=28488 That bug was resolved in 4.2.3. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] New UX for RT: REST 2.0, json, and what?
On Thu, 2014-03-06 at 17:21 +0100, akos.to...@docca.hu wrote: This is some kind of request for comment. Please, feel free to give us advice, support, ideas. If you have similar effort, if you know any solution that makes this problems causeless, let us know please! Best Practical is always interested in contributions from the community which improve the product. As it happens, our focus for RT 4.4 is planned to include a concentration on the UI, as well as a rewrite of the REST API. For RT 4.2, we held to our previous restrictions that the entirety of the UI needed to be accessible to users without JS enabled. With JS-based UIs sufficiently prevalent now, it is our intent with RT 4.4 that JS will be a required part of the UI. That being said, we do not intend to write the entirety of the UI in JS, as a thin wrapper around back-end APIs. Such a rewrite would be extremely time-intensive, and unlikely to be able to duplicate all of the features of the current server-side templating solution. However, we're quite interested in improving the REST API. The 1.0 REST API was written well before the advent of JSON, and indeed before the concept of REST APIs had begun to be commonplace -- as such, it has a number of very odd design decisions that hinder extensibility. Because of this, we are uninterested in expanding on it, but are more focused on providing a new implementation which is based on modern assumptions of how REST APIs should function. We currently have an initial sketch of a REST 2.0 already partially completed, with the aim to release it as an extension for RT 4.2, in core in RT 4.4, and remove REST 1.0 thereafter. It is now published at https://github.com/bestpractical/rtx-rest -- it also requires the RT branch https://github.com/bestpractical/rt/tree/4.2/support-rest-v2 Bear in mind that this is highly experimental; we do _not_ suggest its use apart from developers working on it. It is in no way production-ready. As we are aware it is lacking in features, pull requests or patches welcome; simple bug reports are not helpful at this juncture. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Assets 1.0 Question - Ticket to asset linking
On Wed, 2014-03-05 at 11:27 -0600, Schincke, Keith wrote: Is there a way to link and existing ticket with an asset? It does not appear that new tickets created via email or a web form can be linked to an asset. You can add links via the Links page of tickets, using asset:42 to link to Asset #42. You may also be interested in setting @AssetQueues, which will add a quick Link to asset: box on tickets in those queues; see http://bestpractical.com/docs/assets/latest/Assets_Config.html#AssetQueues - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Assets 1.0 - reports
On Wed, 2014-03-05 at 11:27 -0600, Schincke, Keith wrote: I am looking at the Assets 1.0 module and there does not seem to be a way to save an asset search or export the data to an XLS or CSV format. Development of a CSV export has already been sponsored by Reed, can be found on a branch at https://github.com/bestpractical/rt-extension-assets/tree/1.1/csv and will be included in Assets 1.1. Could the asset search be derived from the ticket search and inherit the features and functionality already provided? Generalizing TicketSQL to work on Assets was out of scope for the original project, as is it unfortunately not as straightforward as you imply. If you're interested in sponsoring development, it's a feature that we'd be interested in adding. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Drop-down menu for Owner field disappeared
On Tue, 2014-03-04 at 17:05 -0600, Tim Wilson wrote: RT suddenly stopped showing a drop-down menu for the Owner field today. It's just a regular text box now. You can still type in it, and the autocomplete works, but the drop-down is gone. We're running 4.2.0. There's no difference in behavior in different browsers. Any suggestions? For performance reasons, RT 4.2 switches to an autocomplete box once the number of possible owners grows beyond 50. If it did so suddenly, it's a fair bet that someone handed out OwnTicket too broadly, and the autocompleter is saving you from a drop-down that would otherwise contain, say, all users in your system. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
[rt-users] [rt-announce] Assets 1.0 released
Assets 1.0 -- 2014-02-27 We are very happy to announce the first version of RT::Extension::Assets, an asset tracking extension for RT 4.2.1 and above. The extension leverages RT's custom field architecture, making it a very flexible platform for tracking whatever type of asset data you need to record. It also comes with some roles and rights to allow you to assign assets and manage access permissions. http://download.bestpractical.com/pub/rt/release/RT-Extension-Assets-1.0.tar.gz http://download.bestpractical.com/pub/rt/release/RT-Extension-Assets-1.0.tar.gz.asc SHA1 sums 8a57147608d5fd70c2148b69ead439a20358ae7a RT-Extension-Assets-1.0.tar.gz c8b3e057ceef5f91069e8d4cfc4bf93cff036b41 RT-Extension-Assets-1.0.tar.gz.asc - Alex ___ rt-announce mailing list rt-annou...@lists.bestpractical.com http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
[rt-users] [rt-announce] RT 4.2.3 released
RT 4.2.3 -- 2014-02-20 -- We are chuffed to announce that RT 4.2.3 is now available. http://download.bestpractical.com/pub/rt/release/rt-4.2.3.tar.gz http://download.bestpractical.com/pub/rt/release/rt-4.2.3.tar.gz.asc SHA1 sums e9e48c0a6d6b005e15c2f65c7919f70b086e5569 rt-4.2.3.tar.gz e0cb3cc5f6146aca29c4dd17684b5c47bc49c47f rt-4.2.3.tar.gz.asc This release is primarily a bugfix release; notable changes include: Administrator tasks * Avoid starting a FastCGI process manager in the common case of the FastCGI process being started by the webserver, and communicating over STDIN. This restores the behavior from 4.0, where the process name is the full path to rt-server.fcgi, and not the static string perl-fcgi-pm or perl-fcgi. * Automatically clean out Mason cache when updated HTML is installed during upgrades; this should prevent a common class of errors. * Fix paths in rt-importer when importing from a serialized dump which was written to an absolute path. * Additional optional upgrade script for users upgrading from RT 3.8 who previously used RT::Extension::CustomField::Checkbox. * Pass characters, not bytes, to _EncodeLOB during de-serialization; this prevents invalid UTF-8 from a serialized dump from entering the new database. * Catch and warn of additional common misconfigurations of GPG/SMIME integration. * Prevent a possible infinite loop in rt-validator --resolve if Principal records were missing; default to forcing their creation. Localization * Localization updates from Launchpad. General user UI * Date and DateTime customfields now pass mandatory validation if unchanged. * 1970-01-01 is now treated as unset for purposes of Date and DateTime validation. * Add Date and DateTime fields to bulk update. * Don't conduct a user search if no string was entered. * Signal if a user is disabled at the top of User Summary pages. * Resolve regression in 4.2, which caused warnings during ticket creation when transaction custom fields were applied. * Respect transaction squelching during GPG/SMIME signing and encryption. Lack of public key for a squelched user will no longer trigger errors, for instance. * Resolve regression in 4.2, where the recipient squelching checkboxes did not properly synchronize state between users who appeared multiple times. * Adjust the bottom edge of rolled-up tabs in ticket pages. * Sort data groupings in charts numerically, not ASCIIbetically, if they all appear to be numbers. * Ensure that Sidebar / Body panes in dashboard configuration display in a consistent order on perl 5.18 and above. * For strict DOM compliance, move a name attribute on div to data-name. * Prevent Can't call method DependsOn on an undefined value error in bulk update if tickets were deleted. * Show links to tickets which are not readable by the user as numbers, not as blank titles. * Add a ticket-active class, as well as the current status as a class, to ticket links on ticket display page. * Fix a regression in 4.2 which caused an error when a user with only limited rights (Watch or WatchAsAdminCc) removed themselves as a watcher from a ticket or queue. * Allow SeeCustomField on a single queue to show its custom fields during search if the search is limited to that queue. Documentation * Remove obsolete wording mentioning CPAN 1.84, which we guaranteed to already have a more recent version of, by way of perl 5.10.1. * Correct reminders documentation to suggest RT::Action::Notify, not RT::Action::SendEmail. * Documentation on writing extensions for RT. Admin interface * Fix Queue and QueueId columns in admin Scrips listing to emulate their display in 4.0. * Additional ModifyDropdownLimit in SelectOwnerDropdown to allow sites to increase the previously-hardcoded limit of 50 users in the drop-down before it switched to autocompletion. * Correctly style warnings about Articles needing configuration. * Resolve regression in 4.2 in admin interface, where the current group and rights tab is not preserved across rights submission. * Show static content roots in System Configuration, alongside Mason content roots. * Catch and warn of template compilation errors, such as unbalanced braces. Database * Improve right-checking query plan (at least on PostgreSQL 9.3) by de-duplicating ACL equivalence objects, and using the RT::System's id. * Upgrade steps from RT 4.0 - 4.2 now DROP IF EXISTS tables and sequences before attempting to create them, except on Oracle. This resolves the common case of testing an upgrade before re-importing a backup atop it for the final upgrade, leaving the new tables still in place. * Fix a regression in 4.2 which caused rt-server to hold extra database handles open. For FastCGI processes, this was one extra per FastCGI process; for standalone servers, only one overall. Callbacks *
Re: [rt-users] RT-4.2.2 and RT-Assets
On Wed, 2014-02-19 at 09:09 +0100, Joop wrote: Joop wrote: Without touching CustomField Grouping I get an error when I click on CustomFields in the display page, 'No grouping specified' , while in rt-4.2.2 clicking on CustomFields will take you to the Basics page with the customfields ready to edit. Anything about this one? Fixed last night in f21a7f6, which led to discovering some UI properties which will require an RC2 later today. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Fedora 20 / Perl 5.18
On Wed, 2014-02-19 at 16:47 -0800, CLOSE Dave wrote: Anyway, Jok's solution did not solve the problem. But it did give me some more error messages to investigate. I discovered that the vendor_perl/RT directory content was quite old. I replaced it entirely with the files from the installation directory, restarted Apache, and now things seem to work. There are also copies of those files in /opt/rt4/lib/RT, but that is not in @INC for some reason. RT adds /opt/rt4/lib to its @INC path on startup; copying them into vendor_perl is unnecessary. In fact, you are only leaving a landmine for yourself in the future (as happened with the _Overlay files) by having copied them into vendor_perl. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] No __TimeLeft__ value in search result
On Tue, 2014-02-18 at 04:10 -0800, andkulb wrote: This is the time values for the ticket: Created: Tue Feb 18 13:28:25 2014 Starts: Tue Feb 18 13:28:25 2014 Started: Tue Feb 18 13:28:25 2014 Last Contact: Tue Feb 18 13:30:25 2014 Due: Wed Feb 19 00:00:00 2014 Still, the __TimeLeft__ field is always blank. What is the problem? TimeLeft is not a computed value between starts and due. It is a count of your estimate of the minutes/hours of work remaining on the ticket, which can be updated from the Basics page of the ticket. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] RT-Assets-Import-CSV surprises
On Sat, 2014-02-08 at 14:37 +0100, Joop wrote: Still trying out new things :-) Found another thing which I think is a shortcut in the documentation. [snip] Nowhere in the docs it is mentioned that you need to put CF. in front of CustomFields. Thanks for the catch. I've just released version 1.1 which fixes this. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] QueueSummaryByLifecycle warning
On Fri, 2014-02-14 at 10:54 +0100, Marko Cupać wrote: mysql select Name, Lifecycle from Queues; +---+---+ | Name | Lifecycle | +---+---+ | General | NULL | | ___Approvals | approvals | | Quality Dept. | default | +---+---+ 3 rows in set (0.00 sec) This points to having skipped the 4.0.9 upgrade step. You should check your upgrade history in Admin → Tools → System Configuration. - Alex -- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
Re: [rt-users] Error while trying rt-assets-import-csv
On Fri, 2014-02-07 at 14:16 +0100, Joop wrote: I installed a test instance of rt-4.2.2 (from source, on Centos-6.5, perl-5.10.1 x64) and installed the shiny new Assets extension and its import part but get the following error: Insecure dependency in require while running with -T switch at /usr/share/perl5/Pod/Perldoc.pm line 1548 when I run rt-assets-import-csv. Pardon my perl ignorance but how to fix this?? This is probably https://rt.perl.org/Public/Bug/Display.html?id=72550 Try upgrading Pod::Perldoc - Alex
Re: [rt-users] segmentation fault
On Wed, 2014-02-05 at 18:50 -0600, José Luis Gordillo Ruiz My RT 4.2 instance is not working properly. Sometimes it gets errors in creating tickets or sending mails. Logs show segmentation faults of httpd. On of the cores I could get shows that the segmentation happens in malloc This RT is running in a virtual machine. At the beginning, it had 512 MB of RAM and was very slow when several sessions were open. Then we increased the RAM to 1 GB. The speed is now good but this strange behavior started. While segfaults are not the form I'd generally expect the failure to take, this is likely still memory contention. What do your monitoring tools tell you about memory usage on the box? If you're also running your database server on the same machine, I'd expect 1G to definitely be insufficient. - Alex
Re: [rt-users] RT Upgrade going bad (4.0.8 - 4.2.2)
On Tue, 2014-02-04 at 14:08 +, Nick Fennell wrote:
So it’s mainly this I’m having issues with;
{{{
[6096] [Tue Feb 4 10:12:39 2014] [critical]: Can't use an undefined
value as a HASH reference at /tmp/rt-4.2.2/sbin/../lib/RT/Crypt.pm
line 237. (/tmp/rt-4.2.2/sbin/../lib/RT.pm:393)
Can't use an undefined value as a HASH reference
at /tmp/rt-4.2.2/sbin/../lib/RT/Crypt.pm line 237.
make: *** [upgrade-database] Error 255
}}}
This says that it's not finding the configuration value for either the %
GnuPG or the %SMIME configuration -- which are part of RT 4.2's core
RT_Config.pm file. To double-check, you did run 'make upgrade' prior to
'make upgrade-database', and your /tmp/rt-4.2.2/etc/RT_Config.pm does
contain the word SMIME?
- Alex
Re: [rt-users] RT 4.2.2 - inline images are not shown in tickets
On Tue, 2014-02-04 at 04:20 -0800, Alexey Bozrikov wrote: I have made a fresh install of RT 4.2.1 yesterday and noticed, that when I create a ticket using RT Web interface (rich text) and paste a screenshot or any other image to the editor, this image not being shown in either e-mail sent to requestor (tested with Outlook 2003 and Outlok 2010), or in ticket history. Sadly, RT does not support the inline image pasting functionality of CKEditor, since that requires running some of the server-side code of CKeditor which we do not support. Your best option is to use the Attach: box directly below the text entry area. - Alex
Re: [rt-users] REST call to retrieve list of groups
On Tue, 2014-02-04 at 11:21 +, Guadagnino Cristiano wrote: Hi all, I have found out that I can use this REST call: http://my.rt.site/REST/1.0/group/group_name to retrieve informations about a group (id, name, description, members). However, I cannot find a REST way to retrieve the list of groups defined on an RT instance. Is it possible? RT 4.2.2 adds a search endpoint for users and groups: rt ls -t groups id: group/1238 Name: RT hackers Description: RT hackers Disabled: 0 -- id: group/14255 Name: BPS Staff Description: Disabled: 0 [...] The endpoint is /REST/1.0/search/groups - Alex
Re: [rt-users] Problem with HTML tags appearing in correspondence
On Mon, 2014-02-03 at 14:22 -0800, Alexey Bozrikov wrote: I am attaching a diff -ur between upgrded and freshly installed RT 4.2.1, as I had exactly same issue when posting new tickets and replying to existing tickets from RT web interface. Our system has no customizations at all with exception to one custom field for the ticket (which I have disabled when I was testing on the upgraded system). Your differences are entirely in var/mason_data, aka the Mason cache. This confirms that you skipped the last bit of step (6b) in the README[1]: 6b) If you are UPGRADING from a previous installation: [...] Finally, clear the Mason cache dir: rm -fr /opt/rt4/var/mason_data/obj You may then start your web server again. - Alex [1] http://bestpractical.com/docs/rt/latest/README
Re: [rt-users] ShowCustomFields extremely slow.
On Thu, 2014-01-30 at 10:57 +0100, Michelle Sullivan wrote: Jan 28 02:11:09 to Jan 28 02:18:31 ... a full 7 minutes of being in ShowCustomFields there are just 100's (like more than 1900 of them) of statements like this: [snip] .. and no other queries... The start being immediately after: [snip] Which is a column_info() call in DBD::Pg Which is called from Fields() in DBIx::Searchbuilder .. Which I assume is being called in ShowCustomFields somewhere... Correct. It should also only run once per process, and be cached thereafter. The problem is network latency between the front ends and the backend DB... Running this on the same host returns in under a second. Yes. These queries aren't a notable performance hit on most servers. At worst case, they may take a second or two -- they certainly don't take upwards of _five minutes_. The latency is, as you've diagnosed, almost certainly the root cause of your problems. My frontends are on completely different networks (and indeed different data centers) from the database servers for security (mainly DDoS type) reasons [snip discussion of optimization of column_info()] RT simply isn't designed to operate in an environment where every query has tens to hundreds of ms of latency. Attempts to optimize this particular set of queries will merely cause the limiting factor to become some other set. While we're absolutely interested in patches that help decrease the number of queries that RT runs (as you've noted, there are several queries run multiple times), I expect you will find this to be a frustrating game of whack-a-mole. If at all possible, altering your network topology to remove the latency is most probably a more straightforward way to have a performant RT instance. - Alex
Re: [rt-users] ShowCustomFields extremely slow.
On Tue, 2014-01-28 at 03:30 +0100, Michelle Sullivan wrote: Ok so temporarily I set min_duration to 0 and logged everything, the log is here: The situation can be made much clearer by limiting to the postgres process IDs which are responding to queries from RT, namely 15537 and 15481. The longest statement duration is 1559.273ms, which is a _parse_ of a statement query, not even an execution. The next-longest query is DBD::Pg's query (which is only run once per process, FTR) at 02:11:09 to determine table information -- which takes nearly a full _second_ to return. On the largest Postgres installation which I have access to, this takes less than 100ms. I am not familiar with Bucardo as a replication strategy, so I can't comment on that. However, I strongly suspect that the answer lies amongst your replication tool and network topology. The symptoms do not match any failure modes that I'm familiar with in RT. You may wish to try simplifying your database configuration (temporarily install Pg on one of the front-ends) to see if that resolves any of the problems. - Alex
Re: [rt-users] Memory leak when merging tickets, RT 4.2.2
On Tue, 2014-01-28 at 16:23 +, Jonah Hirsch wrote: It seems to occur for any ticket. I tried it on our most innocuous queue and it still occurred. Removed all people from the ticket, no special things in the ticket, and it still causes its apache process to lock up the system. Do you have any extensions or customizations installed? Are there any errors in your error logs? - Alex
Re: [rt-users] Memory leak when merging tickets, RT 4.2.2
On Tue, 2014-01-28 at 19:18 +, Jonah Hirsch wrote: I just remembered that when upgrading I had some database upgrade errors. I checked the upgrade history in RT and saw that it failed upgrading the DB schema from 4.1.12 on. When I try to run /opt/rt4/sbin/rt-setup-database --action insert --datafile content From the /rt-4.2.2/etc/upgrade/4.1.12 directory I get the following including an error: The right way to try to resume the upgrade is /opt/rt4/sbin/rt-setup-database --action upgrade ...and enter 4.1.12 as the starting version. Now inserting data. [52450] [Tue Jan 28 19:16:07 2014] [debug]: Going to load 'content' data file (/opt/rt4/sbin/../lib/RT/Handle.pm:814) [52450] [Tue Jan 28 19:16:07 2014] [debug]: Creating ACL... (/opt/rt4/sbin/../lib/RT/Handle.pm:1017) [52450] [Tue Jan 28 19:16:07 2014] [critical]: Can't use an undefined value as a HASH reference at /opt/rt4/sbin/../lib/RT/System_Vendor.pm line 22, $handle line 1. (/opt/rt4/sbin/../lib/RT.pm:393) Can't use an undefined value as a HASH reference at /opt/rt4/sbin/../lib/RT/System_Vendor.pm line 22, $handle line 1. RT doesn't ship a System_Vendor.pm, so color me extremely suspicious. - Alex
Re: [rt-users] Memory leak when merging tickets, RT 4.2.2
On Tue, 2014-01-28 at 21:12 +, Jonah Hirsch wrote: I got the upgrades to run successfully, but I still get the memory issue when merging tickets. I noticed that System_Vendor.pm wasn't a stock RT file either, but I'm not sure where it came from. Here's its contents: That would be the third-party RTx::AssetTracker extension -- which as fas as I'm aware does not function on RT 4.2. If it's installed into /opt/rt4/lib/, it's also installed incorrectly, which will make removing it somewhat more difficult -- you should remove all *_Vendor.pm, *_Overlay.pm, and *_Local.pm files from /opt/rt4/lib/ - Alex
[rt-users] [rt-announce] Security vulnerability in RT
Versions of RT between 4.2.0 and 4.2.2 (inclusive) are vulnerable to a denial-of-service attack via the email gateway; any installation which accepts mail from untrusted sources is vulnerable, regardless of the permissions configuration inside RT. This vulnerability is assigned CVE-2014-1474. This vulnerability is caused by poor parsing performance in the Email::Address::List module, which RT depends on. We recommend that affected users upgrade their version of Email::Address::List to v0.02 or above, which resolves the issue. Due to a communications mishap, the release on CPAN will temporarily appear as unauthorized, and the command-line 'cpan' client will hence not install it. We expect this to be resolved shortly; in the meantime, the release is also available from our server: http://download.bestpractical.com/mirror/Email-Address-List-0.03.tar.gz http://download.bestpractical.com/mirror/Email-Address-List-0.03.tar.gz.sig f2e0c90b6ab9aecba9ebe0dd0e2645ece8aabd6d Email-Address-List-0.03.tar.gz 5e1f83e5e8ff2fde22a1a25aaee488d84f810389 Email-Address-List-0.03.tar.gz.sig After extracting the contents, the module can be installed by running: perl Makefile.PL make make install The first step should be sure to use the same perl that RT runs using. If you are unsure, the first line of /opt/rt4/sbin/standalone_httpd should contain the full path to the relevant perl binary. The last step will likely need to be run with root permissions. After this process, you should restart your webserver. If you need help resolving this issue locally, we will provide discounted pricing for single-incident support; please contact us at sa...@bestpractical.com for more information. signature.asc Description: This is a digitally signed message part ___ rt-announce mailing list rt-annou...@lists.bestpractical.com http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce
Re: [rt-users] REST mail-gateway using 100% cpu
On Wed, 2014-01-22 at 08:33 -0800, andriuss wrote: Glad to hear that. Waiting for the fix. Please see the just-announced CVE-2014-1474, and http://download.bestpractical.com/mirror/Email-Address-List-0.03.tar.gz which resolves the issue. - Alex
Re: [rt-users] REST mail-gateway using 100% cpu
On Fri, 2014-01-24 at 20:00 +0100, Arkadiusz Miśkiewicz wrote: It will be re-queued and tried again when it fails to submit to RT, so it'll be somewhere in your queues I find it to not always be true. For example when our mysql died then rt- mailgate didn't return any error BUT rt itself created bounces with Ticket creation failed: Mail delivery failed: returning message to sender. I can't replicate this. When RT has no database connection, RT produces a server error, and as such rt-mailgate returns status 75, which is temporary failure, keep in queue and try again later. So this means customers messages were lost (we fortunately recovered these from other sources), not requeued obviously and customers were scared with Ticket could not be created due to an internal error mail bodies. I would even mark this as a important bug (as loosing messages is important) but well... It is absolutely an important bug -- RT should not lose incoming email. If you can replicate it, please submit the replication strategy as a bug to rt-b...@bestpractical.com - Alex
Re: [rt-users] ShowCustomFields extremely slow.
On Mon, 2014-01-27 at 10:06 +0100, Michelle Sullivan wrote:
After upgrade to v4.0.17 from 3.x loading tickets is extremely slow..
can anyone give me any clues please...?
What version were you upgrading from? What database backend are you
using?
Profiler shows this for a load of a single ticket:
/Ticket/Display.html BEGINS {{{
/autohandler {{{
/Elements/SetupSessionCookie {{{
/Elements/SetupSessionCookie }}} 0.2310
The fact that even cookie setup takes a quarter of a second is
problematic, and suggests that your database badly needs tuning.
/Elements/ShowCustomFields {{{
/Elements/ShowCustomFields }}} 429.2604
Your database's slow query log will hopefully shed some light on the
query/queries that are being problematic.
/Elements/ShowUser {{{
/Elements/ShowUserConcise {{{
/Elements/ShowUserConcise }}} 0.0014
/Elements/ShowUser }}} 0.4606
The fact that displaying a user takes half a second is another sign that
your database accesses, in general, are being problematic.
- Alex
Re: [rt-users] Memory leak when merging tickets, RT 4.2.2
On Fri, 2014-01-24 at 17:43 +, Jonah Hirsch wrote: I just upgraded to RT 4.2.2 yesterday, and whenever a user merges a ticket, the responsible apache processes maxes out memory usage on the system and the system slows to a crawl until the OS kills the process, since the system is out of memory. Is this a known issue? Anyone have any thoughts on what I can do to try to solve this problem? This is the first I've heard of it. Does it occur for any ticket merge? Can you replicate it in a clean RT 4.2.2? - Alex
Re: [rt-users] clone ticket in RT 4.2
On Mon, 2014-01-27 at 21:13 +, Brent Wiese wrote: I saw under the “General User UI” fixes in 4.2.2: * Fix Clone ticket functionality with Select-multiple custom fields. I don’t see anything in my UI about cloning a ticket. This is actually a feature I’ve been desiring, but the old plugin to do it didn’t work in the 4.x branch. Am I missing something in the UI or is this a back-end thing that isn’t what I’m thinking/hoping it is? This refers to the (Create) links in the Links box. Clicking on that creates a new ticket, linked via whichever linking method you chose. It also picks up many properties of the original ticket, including custom fields[1]. Select-multiple CFs failed to get transferred correctly; that is what the release note refers to. - Alex [1] It also copies over Time Worked, which is often considered a bug. For backwards-compatibility, we've not changed this yet, but there's a branch to fix that for 4.4.
Re: [rt-users] REST mail-gateway using 100% cpu
On Tue, 2014-01-21 at 04:55 -0800, andriuss wrote: Sorry for my lack of knowledge. Still I think that RT, to be more precise, Email::Address:List module should reject this kind of header and not stuck in infinity regex loop. Absolutely. We intend to address this shortly. What I was able to get from mail sender, he was using Microsoft Outlook Web App. Interesting. - Alex
Re: [rt-users] REST mail-gateway using 100% cpu
On Sun, 2014-01-19 at 23:54 -0800, andriuss wrote: I don't think so. First point, correct me if I'm wrong - An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec' : It says, that you can't have the following syntax: Name Surname name@=?UTF-8?B?abc=?= ...are you attempting to claim that a From: header of =?UTF-8?B?ICJUb21hcyBNYXLEjWl1bGlvbmlzIiA8VG9tYXMuTWFyY2l1bGlvbmlzQGJp?= =?UTF-8?B?dGVzcGFydG5lcmlzLmx0Pg==?= is _not_ an example of an encoded-word appearing in some portion of an addr-spec? Like, the addr-spec that _should_ be written tomas.marciulio...@bitespartneris.lt ? I'd say that's an encoded word appearing in a portion where an addr-spec is expected. Regardless, see below. See http://tools.ietf.org/html/rfc2047#page-11, the examples section, where the following is said to be correct syntax, untill the encoded word is self contained: Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= No. That is entirely different. The subject field is not a structured header[1] -- it merely consists of *text[2]. As such, this follows rule (1) of [3]. The From field, however, is a structured header the full ABNF of which can be found in [4]. As such, you're not allowed to replace the entire content with an encoded-words. Per rule (3) of [3], phrase is the only place which an encoded-word is allowed to be found in a structured field. And phrase can only occur in one place in an address: specifically, before f...@example.com. I guarantee that no widely-used email client chooses to format addresses does encoding the way you're insinuating. RT is clearly _wrong_ to consume CPU time parsing it, but it would be almost more wrong to parse in the way you're implying. My mail client, for instance, rightly refuses to parse it at all, and leaves it as =?UTF-8?B??= when displaying, and indeed when attempting to reply to such a message. I am still morbidly curious to hear what software created that header. - Alex [1] http://tools.ietf.org/html/rfc822#section-3.1.2 [2] http://tools.ietf.org/html/rfc822#section-4.1 [3] http://tools.ietf.org/html/rfc2047#section-5 [4] http://tools.ietf.org/html/rfc2822#section-3.4
Re: [rt-users] REST mail-gateway using 100% cpu
On Thu, 2014-01-16 at 00:37 -0800, andriuss wrote: The situation become a little bit clearer: The failing mail header: From: =?UTF-8?B?ICJUb21hcyBNYXLEjWl1bGlvbmlzIiA8VG9tYXMuTWFyY2l1bGlvbmlzQGJp?= =?UTF-8?B?dGVzcGFydG5lcmlzLmx0Pg==?= But it should be the following (RT works just fine with that): From: =?UTF-8?B?VG9tYXMgTWFyxI1pdWxpb25pcw==?= tomas.marciulio...@bitespartneris.lt Clients mail program, probably encodes all the header, no matter that there are no non-ascii symbols in the second part of the header ( tomas.marciulio...@bitespartneris.lt); Encoding the entire header is definitely against the RFC. See the first point on http://tools.ietf.org/html/rfc2047#page-8 . What mail client? - Alex
[rt-users] [rt-announce] RT 4.0.19 released
RT 4.0.19 -- 2014-01-13
---
We are pleased to announce RT 4.0.19 is now available.
http://download.bestpractical.com/pub/rt/release/rt-4.0.19.tar.gz
http://download.bestpractical.com/pub/rt/release/rt-4.0.19.tar.gz.sig
SHA1 sums
ce7bae429ed56603fef9e7a46d976d1ea9ed1e14 rt-4.0.19.tar.gz
fefb23bb549f94e65e803de295e747f143384557 rt-4.0.19.tar.gz.sig
This release is primarily a bugfix release; of particular note is that
it contains schema changes for MySQL, the first notable such in the 4.0
series. Though the changes are limited, it is especially important to
take, and verify you can recover from, a database backup prior to
upgrading.
Other changes of note:
Documentation
* Add documentation for rt-crontool
* Clean up examples in Lifecycles documentation
* Document additional indexes that increase performance of Shredder
* Replace a suggested GnuPG option with one which is not deprecated
* Note that errors reported from the GnuPG infrastructure may be caused
by GnuPG not being configured, but having been automatically enabled.
Database
* On MySQL, alter the character set of all columns used to store email
addresses to UTF-8
* Ensure that invalid byte sequences that may have snuck into the
database previously (on earlier versions on MySQL, for instance) are
not blindly interpreted as UTF-8 when retrieved from the database.
As a result, invalid bytes will be returned from the API as the four
characters \xHH, where HH is the hexadecimal encoding of the byte.
* Ensure that all data containing non-ASCII is quoted-printable encoded
for PostgreSQL, instead of merely all data not claiming to be
text/plain
* Additional warnings prevention on Oracle; tests now pass cleanly
* Allow fully-automated database upgrades using --upgrade-from and
--upgrade-to options to rt-setup-database
* Clean out any remaining traces of RTFM that lingered in custom fields
and custom field values that were disabled at the time of the
previous upgrade step.
* Bullet-proof a 3.8 - 4.0 upgrade step for Scrips with no Condition
Email
* Set a transfer encoding on outgoing dashboards; this resolves issues
with long lines when using the Sendmail MTA.
* Cope with mangled and overly-quoted recipient headers occasionally
generated by Outlook.
General user UI
* When using the back button to return to a reply page with the rich
text editor, contents will no longer be doubly HTML-encoded
* Improve rendering on Internet Explorer 6
* Fix cascaded custom fields on Internet Explorer 8 and below.
* Support cascaded selects for all Select render types (dropdown,
select box, radio buttons, checkboxes)
* Minor rendering bugs with Charts placed on homepages and dashboards
* Add mark as seen functionality to SelfService ticket display pages
* Link the ModifyPeople page when the user has Watch or WatchAsAdminCc
* Whitelist show outgoing email and chart results from CSRF
protection
* RT 4.0.7 introduced a performance regression when building ticket
searches that query Links; switch back to a much better-indexed
query.
* Fix Clone ticket functionality with Select-multiple custom fields.
* Show the queue ID for the current queue in the ticket edit page, even
if the user does not have SeeQueue; this prevents the user from
accidentally changing the queue.
Query Builder
* Support CF.Foo in addition to CF.{Foo} and '__CF.{Foo}__' in format
strings. This follows the trend of allowing brace-less forms
whenever possible.
* Ensure that format strings from the Query Builder escape quotes
correctly, and correctly parse existing formats with quotes.
* Autocomplete CF values for custom fields of type Autocomplete in
the Query Builder.
* Warnings avoidance for searches with more than 1000 results.
Admin
* Fix real-time updating of Theme CSS on Internet Explorer 8 and below
* Fix a minor display bug in the CF Admin pages, where the queue number
instead of queue name would be displayed in requests shortly after
server startup.
* Add Extra Info as a possible field for More About Requestor
iCal
* Ensure that iCal dates are formatted with a leading space on the
first nine days of each month, for correctness.
* Show iCal dates (when omitting times) in the user's timezone, not UTC
REST
* Prevent a server error when attempting to guess content-type in the
REST interface.
Development
* Custom Action and Condition packages (as supplied by extensions;
these are not the text entry boxes in the UI) are now loaded at
server startup time, to catch compile-time errors in such classes
early as well as reducing RT's memory footprint on mod_perl.
Previously, these errors would have logged errors only when their
Scrip failed to fire. This restores the behavior found in RT 3.8,
which was mistakenly removed in RT 4.0.0.
* rt-dump-metadata has slightly more documentation and options
* Additional callbacks, including in charts,
[rt-users] [rt-announce] RT 4.2.2 released
RT 4.2.2 -- 2014-01-13 -- We are pleased to announce that RT 4.2.2 is now available. http://download.bestpractical.com/pub/rt/release/rt-4.2.2.tar.gz http://download.bestpractical.com/pub/rt/release/rt-4.2.2.tar.gz.asc SHA1 sums 72faa454a02240cf21a94633b880e2158325efa1 rt-4.2.2.tar.gz e45c6d244cd0b8e5c5cec57f4ceb8207d6a2ed81 rt-4.2.2.tar.gz.asc This release is primarily a bugfix release; of particular note is that it contains schema changes for MySQL. Though the changes are limited, it is especially important to take, and verify you can recover from, a database backup prior to upgrading. Also notable is that this release fixes a bug in 4.2.0 and 4.2.1 where failures of the HTML-to-text conversion would silently cause mail to fail to be sent. When using the rich text editor, RT will also now quote the the HTML parts of email, and not simply their text equivalents. Other changes include: Documentation * Wording fixes in Shredder * Clean up examples in Lifecycles documentation * Document additional indexes that increase performance of Shredder * Replace a suggested GnuPG option with one which is not deprecated * Note that errors reported from the GnuPG infrastructure may be caused by GnuPG not being configured, but having been automatically enabled. Database * Ensure that even disabled scrips get the same id-to-name change that other scrips got during the 4.0 - 4.2 upgrade. * On MySQL, alter the character set of all columns used to store email addresses to UTF-8 * Ensure that invalid byte sequences that may have snuck into the database previously (on earlier versions on MySQL, for instance) are not blindly interpreted as UTF-8 when retrieved from the database. As a result, invalid bytes will be returned from the API as the four characters \xHH, where HH is the hexadecimal encoding of the byte. * Ensure that all data containing non-ASCII is quoted-printable encoded for PostgreSQL, instead of merely all data not claiming to be text/plain * Additional warnings prevention on Oracle; tests now pass cleanly * Allow fully-automated database upgrades using --upgrade-from and --upgrade-to options to rt-setup-database * Clean out any remaining traces of RTFM that lingered in custom fields and custom field values that were disabled at the time of the previous upgrade step. * Bullet-proof a 3.8 - 4.0 upgrade step for Scrips with no Condition Serializer/importer * Install rt-serializer and rt-importer into sbin/ * Ensure that incremental upgrade steps only run on incremental serializations, not all exports * Fix a runtime error in the incremental upgrade path to 4.2 * Ensure that inflated Users and Groups are created with the same id as their Principal * Disable in-memory record caching when serializing and importing to improve performance * Only search non-Disabled custom fields when looking up BasedOn in initialdata files * Set up logging properly; warnings are now displayed during serialization and importing Email * Don't die if HTML - text conversion throws an error, which would silently prevent outgoing mail from being sent. Instead, fall back to just sending text/html with no text/plain * Replying to an HTML mail with the rich text editor will now quote the HTML part, not the equivalent text version. * Set a transfer encoding on outgoing dashboards; this resolves issues with long lines when using the Sendmail MTA. * Cope with mangled and overly-quoted recipient headers occasionally generated by Outlook. General user UI * Stop localizing custom field names, for consistency * Show a useful error on show outgoing mail if the user has no rights to see the page, rather than displaying an empty page. * Adjust UI to not block header on show outgoing email page * Hide the Take and Steal menu items if you already own the ticket, closing a regression in 4.2.0 and above. * Autocompletion custom fields now properly autocomplete when placed in custom field groupings * Improve rendering on Internet Explorer 6 * Fix cascaded custom fields on Internet Explorer 8 and below. * Fix third-level cascading custom fields, broken in 4.2.1 * Minor rendering bugs with Charts placed on homepages and dashboards * Whitelist show outgoing email and chart results from CSRF protection * RT 4.0.7 introduced a performance regression when building ticket searches that query Links; switch back to a much better-indexed query. * Fix Clone ticket functionality with Select-multiple custom fields. * Show the queue ID for the current queue in the ticket edit page, even if the user does not have SeeQueue; this prevents the user from accidentally changing the queue. * Respect custom field groupings on user preferences page Query Builder * Warnings avoidance for searches with more than 1000 results. * Allow IS NULL to search for dates which are unset * Properly quote CF names containing
Re: [rt-users] db migration from mysql to postgres
On Sun, 2014-01-12 at 20:42 +0100, Matthias Peplow wrote: I found out the following: 1. rt-serializer and rt-import are not installed automatically, had to copy them from my build directory manually to the RTs sbin directory Already fixed in 4.2.2rc1. 2. the import fails, as it is expecting the .dat files not in /my/backup/directory but in /my/backup/directory//my/backup/directory adding a symbolic link works as a workarround but this seems to be a bug. Not using the —directory switch works as well. Looks like a bug, yes. File it on issues.bestpractical.com? 3. the import fails right at the beginning with DBD::Pg::st execute failed: ERROR: relation users does not exist LINE 1: SELECT * FROM Users WHERE LOWER(Name) = LOWER($1) http://docs.bestpractical.com/rt-importer#CLONED_DATA - Alex
Re: [rt-users] Apache FastCGI and # of db connections
On Fri, 2014-01-10 at 11:45 +0100, Václav Ovsík wrote: I have a question regarding behaviour of FastCGI processes and database connections. While preparing upgrade of RT 3.8.16 to RT 4.2.1 I noticed a change of FastCGI usage in the RT. Thanks for bringing this to our attention. This is a bug which affects RT 4.0 and 4.2; the 4.0/fewer-active-handles branch resolves the issue. I did not study Plack too much - only look at http://search.cpan.org/~miyagawa/Plack-1.0030/lib/Plack/Handler/FCGI.pm and there is approach a bit different. One daemon is started standalone (forking to a number of processes) and Apache is configured to connect to this daemon FastCgiExternalServer /tmp/myapp.fcgi -socket /tmp/fcgi.sock This is a valid alternate deployment strategy, which comes with the benefit that one can restart one RT server without affecting others, by restarting its fastcgi process. However, it requires additional system configuration to ensure that these processes are started at server startup time, and so forth, which is why this is not the deployment suggested in RT's documentation, which we aim to keep as simple as possible. Should I really increase PostgreSQL max_connections to 100 and don't bother with it? Until a version of RT is released with the above branch, increasing the max_connections is likely your best bet. The additional connections will consume some small amount of memory each, but this is likely negligible, and will have no performance impact. - Alex
[rt-users] [rt-announce] End of Life of RT 3.8
As previously announced, with the release of RT 4.2, Best Practical will shortly cease support for the 3.8 series of Request Tracker -- specifically, on March 31st, 2014. The RT 3.8 series was first released in July 2008 and has received only critical bug and security fixes since 2011. We will continue to provide critical bug or security fixes until March 31st, 2014 if any are required. Please see http://bestpractical.com/rt/release-policy.html for our general policy on the lifespan of RT's releases. If you need commercial support for your upgrade, Best Practical is currently offering discounted pricing on our upgrade packages and support plans; for more details, contact sa...@bestpractical.com - Alex ___ rt-announce mailing list rt-annou...@lists.bestpractical.com http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce
Re: [rt-users] Problems in templates in Rt 4.2.1
On Mon, 2014-01-06 at 11:42 -0500, Kevin Falcone wrote: Alternatively, wait for RT 4.2.2rc1 (announced on rt-devel) and test once available. RT 4.2.2rc1 is now available for testing, and resolves this issue: http://bestpractical.com/release-notes/rt/4.2.2rc1 - Alex
Re: [rt-users] Encrypting the DB password in RT_Siteconfig
On Tue, 2014-01-07 at 21:36 +, Brent Wiese wrote:
Is there a way to use an encrypted value for $DatabasePassword in
RT_Siteconfig?
What, exactly, do you mean by encrypted? RT clearly needs to have
access to the plaintext password to pass to the MySQL authentication
process, so there is nothing that can prevent some part of the RT
internals from knowing the plaintext.
The fact that the password is in plaintext is one of the reasons why
RT_Config.pm is 0440 and generally owner root and group apache; this
prevents arbitrary users from seeing it. If you're looking to prevent
it from being gleaned from accidental reading by someone who can read
the file, you can simply rot13 it:
my $rot13 = sub {
my $s = shift; $s =~ tr/A-Za-z/N-ZA-Mn-za-m/; $s
};
Set( $DatabasePassword, $rot13-(cnffjbeq) );
- Alex
Re: [rt-users] Problems in templates in Rt 4.2.1
On Thu, 2014-01-02 at 16:18 +, Guadagnino Cristiano wrote: This message is related to my previous thread titled HTML templates in RT 4.2.1. This is a known bug in 4.2.1, relating to how RT attempts to generate a plain-text version of HTML templates. A fix will be in 4.2.2 which will ensure that mail is always sent out, even if it lacks a text/plain part due to failure of the HTML-text conversion. - Alex
Re: [rt-users] RT 4.2.1
On Sun, 2013-12-29 at 21:48 +0100, Nick Price wrote: ScriptAlias /rt /opt/rt4/sbin/rt-server.fcgi You are missing: 1. A trailing slash on rt-server.fcgi/ 2. The FastCgiServer directive. Please give http://docs.bestpractical.com/web_deployment a complete read. - Alex
Re: [rt-users] RT CLI Ticket Display Issue
On Thu, 2014-01-02 at 13:56 -0700, Jesse Griffin wrote: I think this error is related to the HTML - plain text bug in 4.2.1, but I'm hoping to find a pointer to a patch (or git commit) so that I can fix my setup. https://github.com/bestpractical/rt/commit/8807f0d0.patch - Alex
Re: [rt-users] Start
On Tue, 2013-12-24 at 17:37 +0100, Albert Shih wrote: In 4.0.x I use inside my search something like and Starts 'Today' to specify the starting date of this ticket is than today. After ugrading to 4.2.1 it's not working anymore. In RT 4.0, this search also found tickets where Starts was not set; this is no longer true in RT 4.2. Unfortunately, as this was an almost-unintended change, there is currently no way to search for tickets which have no Starts date set. I've pushed a branch for 4.2.2 which will resolve this; the ticketsql syntax will be 'Starts IS NULL' - Alex
Re: [rt-users] Centos 6,5 upgrade
On Mon, 2013-12-23 at 15:23 +, ali mobli wrote: I recently upgraded my Centos 6.4 to 6.5 and am currently running RT 4.0.13. After this upgrade My subjects in the emails are corrupt. We use Icelandic Char so I have default UTF-8 both in the ssl.conf and http.conf and RT_SiteConfig.pm. After the upgrade of the OS this is happening. Likely due to too recent a version of the Encode module. RT 4.0.18 inclues a fix. - Alex
Re: [rt-users] Request tracker and Lighttpd
On Mon, 2013-12-23 at 21:47 +0400, Ivan Osipov wrote: When I try start RT via Apache 2 with mod_fastcgi (http://www.bestpractical.com/docs/rt/4.2/web_deployment.html#mod_fastcgi) in Apache error-log: [snip] Sounds like you didn't configure with --with-web-handler=fastcgi, so 'make testdeps' didn't check the dependencies that that deployment adds. - Alex
Re: [rt-users] RES: RE: RES: Sphinx fulltext index v4.0.4
On Tue, 2013-12-17 at 17:28 -0500, Alex Vandiver wrote:
This lies firmly in the domain of having to debug MySQL and the SphinxSE
plugin, and not in debugging RT itself. From recent testing locally,
using 127.0.0.1 instead of localhost works acceptably.
I have confirmed that this is a bug in sphinxsearch. mysql 5.5.15 and
above removed a codepath that SphinxSE was using to do name resolution,
and the re-implementation of it that SphinxSE uses could never have
worked.
The work-around is to use an IP address (rather than a hostname like
localhost) in the sphinx:// URL that rt-setup-fulltext-index prompts
for. Alternately, the two attached patches can be applied to the
storage/sphinx/ directory.
The issue has been reported to sphinxsearch as bug 1815. RT may work
around this issue in a future release by defaulting to suggesting
127.0.0.1 instead of localhost when running on MySQL 5.5.
- Alex
From 21770e15fa8667177b79ae8f5cd8de67ebd44b28 Mon Sep 17 00:00:00 2001
From: Alex Vandiver a...@chmrr.net
Date: Thu, 19 Dec 2013 01:18:43 -0500
Subject: [PATCH 1/2] getaddrinfo returns 0 on success
---
mysqlse/ha_sphinx.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mysqlse/ha_sphinx.cc b/mysqlse/ha_sphinx.cc
index 06c8610..8305519 100644
--- a/mysqlse/ha_sphinx.cc
+++ b/mysqlse/ha_sphinx.cc
@@ -2121,7 +2121,7 @@ int ha_sphinx::Connect ( const char * sHost, ushort uPort )
#if MYSQL_VERSION_ID=50515
struct addrinfo *hp = NULL;
tmp_errno = getaddrinfo ( sHost, NULL, NULL, hp );
- if ( !tmp_errno || !hp || !hp-ai_addr )
+ if ( tmp_errno || !hp || !hp-ai_addr )
{
bError = true;
if ( hp )
--
1.8.5
From 204e78173db262d2ba73555ed277f0908a3fc568 Mon Sep 17 00:00:00 2001
From: Alex Vandiver a...@chmrr.net
Date: Thu, 19 Dec 2013 01:19:20 -0500
Subject: [PATCH 2/2] Copy out the correct part of the addrinfo response
Merely copying starting at the ai_addr of the addrinfo is incorrect; for
the presumed sockaddr_in value stored in ai_addr, the first bytes are
generally the family and port, not the in_addr.
Dereference to the in_addr out explicitly, and copy that.
---
mysqlse/ha_sphinx.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mysqlse/ha_sphinx.cc b/mysqlse/ha_sphinx.cc
index 8305519..d6ef94b 100644
--- a/mysqlse/ha_sphinx.cc
+++ b/mysqlse/ha_sphinx.cc
@@ -2148,7 +2148,7 @@ int ha_sphinx::Connect ( const char * sHost, ushort uPort )
}
#if MYSQL_VERSION_ID=50515
- memcpy ( sin.sin_addr, hp-ai_addr, Min ( sizeof(sin.sin_addr), (size_t)hp-ai_addrlen ) );
+ memcpy ( sin.sin_addr, ((struct sockaddr_in *)hp-ai_addr)-sin_addr, sizeof(sin.sin_addr) );
freeaddrinfo ( hp );
#else
memcpy ( sin.sin_addr, hp-h_addr, Min ( sizeof(sin.sin_addr), (size_t)hp-h_length ) );
--
1.8.5
Re: [rt-users] RES: RE: RES: Sphinx fulltext index v4.0.4
On Tue, 2013-12-17 at 23:11 +0100, m...@fv-berlin.de wrote: didn't get a response there. Is there a way to solve this? Possibly through debugging RT4 to see how its actually trying to connect to searchd instead of how the config looks like it should? This lies firmly in the domain of having to debug MySQL and the SphinxSE plugin, and not in debugging RT itself. From recent testing locally, using 127.0.0.1 instead of localhost works acceptably. Future versions of RT may default to 127.0.0.1 instead of localhost in the Sphinx connection parameters -- though I would be much more comfortable making that change if the underlying reason for the 'localhost' failure were clear. Unfortunately, debugging mysql is rather complex. You can drop and re-create your SphinxSE table by running 'DROP TABLE AttachmentsIndex' at a mysql prompt, re-running rt-setup-fulltext-index, and providing sphinx://127.0.0.1:3312/rt as the URL of the Sphinx server. - Alex
Re: [rt-users] Installing RT with Oracle 11g: ERROR: as user 'rt': ORA-01017
On Sat, 2013-12-14 at 18:43 -0500, supp...@pureview.com wrote: Could I still install with rt Oracle user in place already. If that is true what would be the new configuration file? What options should I omit...! sbin/rt-setup-database --action init --skip-create - Alex
Re: [rt-users] Excessive communication between RT and postgresql
On Mon, 2013-12-16 at 13:58 +, Jacobsson, Henrik G wrote: After upgrading to RT 4.2.1, the postgresql database is producing massive volumes of WAL files around the clock with peaks during office hours. And what version were you upgrading from? Before the upgrade – we had very limited volumes of WAL files produced, and nothing at all during non work hours. Now – at least 32MB, but usually 64MB of WAL is written every minute, when the system is supposed to be quiet. Does that output cease if you temporarily turn off the webserver? What about if you disable your incoming MTA? Should there be any traffic at all between the RT server and database server when the system is not in use? Apart from occasional handshakes etc. Depends what you mean by in use. RT has no long-running programs aside from the web front-end; as such, requests to the database are only generated by requests to Apache, or the cron jobs. At times when there are no Apache requests and no cron jobs, there should be no significant database traffic. Bear in mind that even if no _users_ are accessing the website, incoming email gets POST'ed to the mail gateway endpoint, which may account for some of the activity when you believe the system is not in use. It may be enlightening to examine the generated WAL logs using http://www.postgresql.org/docs/current/static/pgxlogdump.html - Alex
Re: [rt-users] Upgrade from 4.0.x to 4.2.x - Fresh install with DB upgrade ok?
On Mon, 2013-12-02 at 17:49 +, Cena, Stephen (ext. 300) wrote: I'm getting ready to do an upgrade from 4.0.18 to 4.2.1 here on two servers. When I try the upgrade in a test environment, I get a bunch of errors that fly by (I don't have them, sorry :( ) Get them and look at them. It may well solve you large amounts of time and data loss later. but the site appears to be working. My question is, is it safe to do a fresh install of 4.2.1 and then use the 'make upgrade-database- script against the current database, use my current RT_SiteConfig.pm file spin up the site? That's the recommended set of steps to upgrade, yes. Though it was written for 3.8 - 4.0, you may find http://blog.bestpractical.com/2011/07/upgrading-to-rt-4.html helpful. - Alex
Re: [rt-users] RT 4.2.1 Enter/return key does not work in Safari on OS X
On Tue, 2013-12-03 at 09:52 +1100, Andrew Chung wrote: Just typing in a comment/reply and hitting enter in the message box, it doesn't do anything. You need to use Ctrl-Enter. It's a text box. I don't understand why one would expect pressing enter in such a context to do anything other than add a newline. - Alex
Re: [rt-users] Scrips not accessible in 4.2 anymore
On Tue, 2013-12-03 at 09:21 +0100, Matthias Peplow wrote: Set(%AdminSearchResultFormat,… section in our RT_Site_config and it looks like some paths have changed. So replacing It sounds like you copied all of %AdminSearchResultFormat into your RT_SiteConfig. This is unnecessary, and leads to problems like this one. If you wish to customize an admin format, you need only specify the one you wish to change: # customize the Queues list Set(%%AdminSearchResultFormat, Queues = '' ); This change probably should be mentioned in the UPGRADING notes. We'll add an UPGRADING note. - Alex
Re: [rt-users] RT 4.2 Set($ShowHistory, 'delay') does not
On Tue, 2013-12-03 at 10:38 +0100, Matthias Peplow wrote: same result with Safari 7.0 and Chrome 31.0.1650.57 I can't reproduce with either. You'll need to examine the javascript logs (probably easier in chrome) to see what's happening. - Alex
Re: [rt-users] AD domains with RT::Authen::ExternalAuth
On Tue, 2013-12-03 at 12:35 +, Chris Davies wrote: On 02/12/13 17:11, Alex Vandiver wrote: Feel free to file a pull request on github[1], and we'll take a look. - Alex [1] https://github.com/bestpractical/rt-authen-externalauth/ You've lost me already. If you can send a unified diff patch, we'll start there. - Alex
Re: [rt-users] Custom Status Setup Problems
On Mon, 2013-12-02 at 11:35 -0600, Wendi M. wrote: I can then add this Custom Status setting to a particular queue, and it all looks good. My problem.. I can't resolve the ticket or do anything other than leave it in the new status? Am I missing something obvious here? Thanks! You're missing the transitions: http://docs.bestpractical.com/RT_Config#Transitions-between-statuses-and-UI-actions - Alex
Re: [rt-users] upgrade issues 4.0.17 - 4.2.1
On Tue, 2013-12-03 at 21:37 -0600, Mike W wrote: Upgrade from 4.0.17 and having some issues with email notices. It seems to be connected to scrips. I did run the make upgrade-database The errors below imply that it if you did run it, it did not complete. Show the RT Upgrade History section of Admin → Tools → System Configuration. - Alex
Re: [rt-users] FW: Serious problem with mime/html format email containing attachments
On Tue, 2013-12-03 at 22:39 +0100, Payam Poursaied wrote: First thank you for your feedback in the list regarding the bug in html parser Do not reply off-list. I believe Tom previously corrected you on that in the email you quote below. First time I point this case in 2011 http://lists.bestpractical.com/pipermail/rt-users/2011-January/068219.html Later in 2012 http://lists.bestpractical.com/pipermail/rt-users/2012-October/078179.html And also submit it through the bug tracker: http://issues.bestpractical.com/Ticket/Display.html?id=21267 This is related to RT's algorithm for detecting which part to quote, which has known bugs -- namely, not being sufficiently recursive. This is the same bug as http://issues.bestpractical.com/Ticket/Display.html?id=17769 I've merged your bug report into that one. I believe there is at least one patch you can try applying to see if it resolves your problem. - Alex
Re: [rt-users] upgrade issues 4.0.17 - 4.2.1
On Tue, 2013-12-03 at 22:35 -0600, Mike W wrote: Aha! I found: Upgrade from 4.1.0 to 4.1.1 (Incomplete) Fixed that and got things rolling properly. Thanks for telling me about that. Had no idea it logged that there. It's new in 4.2. However, it is no substitute for reading the 'make upgrade-database' output itself. - Alex
Re: [rt-users] RT 4.2 Set($ShowHistory, 'delay') does not work
On Mon, 2013-12-02 at 15:01 +0100, Matthias Peplow wrote: after the Upgrade from 4.016 to 4.2 the history of tickets was not shown anymore. The label „loading“ was shown forever but the history never appeared. We solved this issue by restoring the RT 4.0 behavior with Set($ShowHistory, 'always‘); How can we get the delayed ticket history working as intended? What browser? Was there anything of note in your logfiles from that time? - Alex
Re: [rt-users] Having trouble upgrading: Unknown column 'm.LastUpdatedBy' in 'on clause' at /usr/sbin/rt-validator
On Mon, 2013-12-02 at 11:38 +0100, m...@fv-berlin.de wrote: Hi, I'm trying to upgrade a 3.6.1-4 (don't ask) RT to 4.0.4-2 and I ran into issues. First of all: I am doing this upgrade (test) on a duplicate of the actual production system, so no worries. As part of the preparation before running the actual database upgrade, I ran rt-validator --check RT 3.6.1 didn't ship an rt-validator -- it appeared in 3.8. Because the schemas are different, you cannot simply run a current rt-validator against the 3.6 schema, either. At least that's how I explained the following error, that occurs when running the actual database upgrade afterwards: This is orthogonal. [...] Processing 3.7.81 Now populating database schema. [crit]: DBD::mysql::st execute failed: Duplicate key name 'CachedGroupMembers3' at /usr/share/request-tracker4/lib/RT/Handle.pm line 515. (/usr/share/request-tracker4/lib/RT.pm:351) DBD::mysql::st execute failed: Duplicate key name 'CachedGroupMembers3' at /usr/share/request-tracker4/lib/RT/Handle.pm line 515. The 3.6 - 3.8 upgrade steps attempt to create an index named 'CachedGroupMembers3', which you appear to already have added by hand locally. If you run 'DROP INDEX CachedGroupMembers3' the upgrade steps should run correctly. - Alex
Re: [rt-users] Upgrading from 4.0.8 to 4.2.1 missing dashboards
On Thu, 2013-11-28 at 11:48 -0800, Chris Black wrote: I just upgraded from 4.0.8 to 4.2.1 this morning and when I log in with my username which was full admin. When I log in now, I am only seeing my list of open tickets. I can't find any dashboard options, admin options, etc. Please show a screenshot -- as .jpg and not overly large, soas to be polite to folks' inboxes. Do you have any local customizations or extensions installed? Is there anything of note in RT's logs? - Alex
Re: [rt-users] changing Organization
On Fri, 2013-11-29 at 13:11 +, Jenny Martin wrote: I would like to change our Organization name to avoid confusion with another RT instance? Does anyone have a script to fixup the RT database so that I can change the Organization name without breaking the RT ticket links? RT 4.2's sbin/rt-validator has a --links-only which, in conjunction with --resolve, will fix links after an Organization change. - Alex
Re: [rt-users] Scrips not accessible in 4.2 anymore
On Mon, 2013-12-02 at 14:54 +0100, Matthias Peplow wrote: after upgrading from 4.016 to 4.2 I cannot select Scrips anymore via Admin-Scrips-Select. Please try the following patch, which should be in 4.2.2: https://github.com/bestpractical/rt/commit/d9c1d3a.patch - Alex
Re: [rt-users] AD domains with RT::Authen::ExternalAuth
On Fri, 2013-11-29 at 13:37 +, Chris Davies wrote: I've finally got around to making some changes to RT::Authen::ExternalAuth that allows me to define the Windows domain. [snip] Are the patches something that would be useful to share here? I've tried emailing the contact in the RT::Authen::ExternalAuth but heard nothing back. Feel free to file a pull request on github[1], and we'll take a look. - Alex [1] https://github.com/bestpractical/rt-authen-externalauth/
Re: [rt-users] RT 4.2.1 RSS feed of articles
On Sun, 2013-12-01 at 23:38 -0800, andkulb wrote: Is it possible to make a RSS feed from articles like with the tickets? Not currently; patches accepted. - Alex
Re: [rt-users] bug in HTML::FormatText::WithLinks::AndTables stops scrips working
On Sat, 2013-11-30 at 16:59 +0100, Payam Poursaied wrote: In the past weeks, we received considerable complaints from our staff that their comments and corresponds are not delivered to the requestors (i.e. on correspond notify requestors). [snip] Working more, I found that, when HTML::FormatText::WithLinks::AndTables could not parse the message and returned error, the scrips stop working In this special case, the problem could be generated very easy. Consider having 2 empty html tables which one of them enclosed in the other: [snip] Excellent debugging. First, does anybody else faced with such problem? i.e. incorrect/incompatible html mail from a customer and/or staff which causes scrips fail to run scrips? I could not figure it out if this exists in 3.8. or not. RT 4.2 is the first to attempt to automatically provide downgraded text/plain alternatives to text/html mail; as such, this did not exist in RT 3.8. Second, is that rational behavior for RT? I believe even if such module failed, at lease scrips should continue working. (maybe it should be submitted to rt-bugs) Absolutely a bug; we should be at least sending the HTML part. Please try https://github.com/bestpractical/rt/commit/8807f0d.patch How are your staff generating the problematic HTML, out of curiosity? Is the CKeditor generating that, or are you pasting in from Word or some other source? - Alex
Re: [rt-users] RT 4.2.1 Enter/return key does not work in Safari on OS X
On Tue, 2013-12-03 at 09:34 +1100, Andrew Chung wrote: I've got a couple of users who are having problems with using the enter/return key when using RT 4.2.1 with Safari. Using the return key in what context? - Alex
Re: [rt-users] Error while running make fixdeps on plack
On Thu, 2013-11-28 at 08:45 -0800, Chris Black wrote: It seems like it's failing on PLACK: arning: Prerequisite 'Plack = 0.992' for 'KAZUHO/Starlet-0.21.tar.gz' failed You've shown the error for Starlet, which depends on Plack. Please show the output of 'cpan install Plack' - Alex
Re: [rt-users] Error while running make fixdeps on plack
On Thu, 2013-11-28 at 09:30 -0800, Chris Black wrote: CPAN.pm: Going to build M/MI/MIYAGAWA/Plack-1.0030.tar.gz Can't locate File/ShareDir/Install.pm in @INC Apparently your version of CPAN.pm is too old to understand configure_requires. What does `cpan -v` report? You can work around this by running 'cpan install File::ShareDir::Install' before running 'make fixdeps' - Alex
Re: [rt-users] Error while running make fixdeps on plack
On Thu, 2013-11-28 at 09:59 -0800, Chris Black wrote: [root@localhost rt-4.2.1]# cpan -v /usr/bin/cpan script version 1.9, CPAN.pm version 1.9402 You may wish to update CPAN: 'cpan install CPAN' Or install and use cpanm: cpan install App::cpanminus RT_FIX_DEPS_CMD=cpanm make fixdeps Failed during this command: GFUJI/Mouse-2.1.0.tar.gz : writemakefile NO '/usr/bin/perl Build.PL --installdirs site' returned status 65280 SARTAK/Any-Moose-0.21.tar.gz : make_test NO ALEXMV/GnuPG-Interface-0.46.tar.gz : make_test NO Mouse is the dependency that failed to install. Show the logs from attempting to install that. - Alex
Re: [rt-users] CustomFields table problems after upgrade to 4.2.1. (column repeated referenced after upgrade)
On Wed, 2013-11-27 at 13:35 +0100, Budsjö, Martin wrote: Thanks a lot! I did have a extra RT4test schema... I did drop that yesterday, but for once I did not rm the mason cache. I did this after reading your reply and now it works perfectly! Thanks again! You saved our upgrade plan for the weekend. Please keep replies on-list, so others can benefit from what you discover. Glad to hear that fixed things. - Alex
Re: [rt-users] CustomFields table problems after upgrade to 4.2.1. (column repeated referenced after upgrade)
On Tue, 2013-11-26 at 11:30 +0100, Budsjö, Martin wrote: I tried to upgrade from 4.0.17 to 4.2.1 the other day and no matter what I do, I get the same result. After upgrading I can login without any problem and all lists of tickets and graphs etc looks good. (By the way, I really like the updates to the menus!) But if I open a ticket, it looks like the query builder is generating SQL using the “repeated” column of the CustomFields table, and that column was removed during the 4.1.11 upgrade process. Hm -- do you also have RT4.0 tables in a different tablespace or something? RT attempts to inspect the database's list of existent columns to determine which columns are available to GROUP BY. - Alex
Re: [rt-users] PostgreSQL sequence counters do not increment correctly with rt-importer
On Tue, 2013-11-26 at 17:25 +0100, Peter van Zetten wrote: I've been looking at migrating from MySQL to PostgreSQL with the rt-serializer/importer scripts. This is a precursor to merging two RT instances, but the initial migration of the main database is being done with the --clone flag to rt-serializer. The problem is that when rt-importer runs on the empty psql schema, none of the sequence values are being updated. Then any action using the new database fails because of duplicate key constraints. Semi-known bug. When we've imported into Pg in the past, we've set the sequences by hand afterwards. The importer should absolutely grow the SETVAL() calls to update the sequences after import; patches accepted. It should look like a more general form of https://github.com/bestpractical/rt-extension-assets-import-csv/blob/master/lib/RT/Extension/Assets/Import/CSV.pm#L230 So it looks like somehow this sequence isn't being hit at all. Perhaps because the 'id' of each object is set in the export and is being inserted directly it doesn't trigger an increment. I'm still finding my way around postgres so I'm just guessing at the moment. Correct; mysql automatically bumps its AUTO_INCREMENT if you insert with an explicit id, but neither Oracle nor Pg adjust their sequences. - Alex
Re: [rt-users] Update to RT 4.2.1 - JSON error after login
On Fri, 2013-11-22 at 09:28 +0100, Dr. Dirk Pape wrote: In the Log: [13817] [Fri Nov 22 08:17:15 2013] [error]: encountered object '1', but neither allow_blessed, convert_blessed nor allow_tags settings are enabled (or TO_JSON/FREEZE method missing) at /usr/local/share/perl/5.10.1/JSON.pm line 154. Show the output of: perl -MJSON -MModule::Versions::Report -e1 - Alex
Re: [rt-users] Update to RT 4.2.1 - JSON error after login
On Fri, 2013-11-22 at 17:22 +0100, Dr. Dirk Pape wrote:
Hi Alex,
$ perl -MJSON -MModule::Versions::Report -e1
[snip]
I can't replicate your failure with the same versions. Does the
following error for you?
perl -MJSON -wle 'print JSON::to_json({foo=JSON::true})'
- Alex
Re: [rt-users] make upgrade-database failed upgrading to 4.2.1
On Fri, 2013-11-22 at 13:06 -0800, Kevin wrote: make upgrade-database failed, while trying to upgrade from 4.0.15 to 4.2.1 I ran the configure, make testdeps and make fixdeps with out any issues. now trying to run the DB upgrade script asked for root pw and db version from popped in 4.0.15 and it failed almost immediately with a bunch of Asset Tracker errors, am pretty sure that I used the latest at version 3.0 when I installed it a few weeks ago. ( there were no issues installing AT) Any ideas on how to resolve these errors and get this upgraded? As far as I am aware, there is no released version of the 3rd-party Asset Tracker extension which is compatible with RT 4.2. Best Practical has written its an Assets extension against 4.2, which is in pre-release; you can install it from source at https://github.com/bestpractical/rt-extension-assets/ Note that it will not import your existing Asset Tracker assets. - Alex
Re: [rt-users] Question about Requestors in RT
On Thu, 2013-11-21 at 21:28 +0100, Bartosz Maciejewski wrote: Hi, Sorry for bother You on private, but I don't get mails from mailing list, only digest came. Then ask to be Cc'd -- please do not simply email directly. Keeping the correspondence on-list means that everyone and the archives will see the correction, below. Thank You for Your solution, but it won't work, error I get with my $Actor = $self-TicketObj-Requestors-First; is [Thu Nov 21 20:11:11 2013] [error]: Scrip 14 Commit failed: RT::Group::First Unimplemented in RT::Action::UserDefined. ((eval 535) line 1) Sorry, braino on my part: $self-TicketObj-Requestors-UserMembersObj-First; - Alex
Re: [rt-users] customfield error: date
On Thu, 2013-11-21 at 10:05 +, Thomas Lau wrote: [critical]: Unknown CustomField type: Date (/opt/rt4/share/html/Elements/BulkCustomFields:81) Does anyone have idea what's wrong with CustomField after upgrade from 4.0.13 to 4.2.0? Nothing. This warning is produced by the bulk update page, which doesn't support bulk update of Date custom fields. Neither 4.0 nor 4.2 do. The severity of the error should likely be decreased, however. - Alex
Re: [rt-users] RT loses MySQL connection
On Thu, 2013-11-21 at 15:20 -0800, Jay Christopherson wrote: I just installed a new instance of RT (4.2.1). I've been using RT for quite a long time now, through a lot of different versions, but this is a new issue for me. Is there anything of note in the mysql logs? - Alex
Re: [rt-users] How to use Requestor user in scrip?
On Thu, 2013-11-21 at 12:56 +0100, Bartosz Maciejewski wrote: I'm trying to get scrip that on status change set owner to requestor. Remember that Requestors may be a list of users; it may also be empty. Which do you intend to set the Owner to? For instance, to simply set it to the first requestor: # This will set $Actor to a user object my $Actor = $self-TicketObj-Requestors-First; # Stop if no requestors return unless $Actor; You can then call -Name or -id on $Actor as you please. - Alex
Re: [rt-users] RT loses MySQL connection
On Thu, 2013-11-21 at 18:05 -0800, Jay Christopherson wrote: No, no entries beyond the startup messages. I thought maybe there would be some connection errors (a flush-hosts situation or something), but nothing. That's odd. Can you show your my.cnf, webserver configuration, and RT_SiteConfig.pm ? Is this under SELinux, or anything else that might muck about with sockets? - Alex
Re: [rt-users] FW: Issue upgrading to 4.2.x
On Wed, 2013-11-20 at 13:56 -0500, Adam Hutchins wrote: [18504] [Wed Nov 20 17:27:58 2013] [critical]: DBD::mysql::st execute failed: Table 'ObjectScrips' already exists at /tmp/rt-4.2.0/sbin/../lib/RT/Handle.pm line 526. (/tmp/rt-4.2.0/sbin/../lib/RT.pm:391) DBD::mysql::st execute failed: Table 'ObjectScrips' already exists at /tmp/rt-4.2.0/sbin/../lib/RT/Handle.pm line 526. Have you tried to upgrade this RT instance previously? What extensions are installed, or have been at some point? - Alex
Re: [rt-users] FW: Issue upgrading to 4.2.x
Please keep all replies on-list. On Wed, 2013-11-20 at 14:10 -0500, Adam Hutchins wrote: I have upgraded it in the past from 3.x to 4.0.7. And I was successful with 4.0.7 to 4.0.18 today. It's the jump to 4.2.x that's giving me errors. Did you attempt the 4.0 - 4.2 upgrade at some earlier point? I'm not using any extensions at this time. Have you ever? RT has not, prior to RT 4.2, shipped an ObjectScrips table, yet you are finding one -- the question is how it got there. Please show the output of: mysql -u root rt4 -p -e select Content from Attributes where Name = 'UpgradeHistory' - Alex
Re: [rt-users] What’s the correct SQL syntax for a date/time custom field that’s not set?
On Wed, 2013-11-20 at 11:13 -0800, Landon Stewart wrote: Is using 1970-01-01 00:00:00” the only way? Currently, yes. Seems like that definite value might be begging for bugs or something if somehow the unset date equals 1970-01-01 05:00:00” for some reason down the road. I just want to make sure I’m not setting myself up for buggy behaviour in the future. That magic date is the UNIX epoch, and will not change. - Alex
Re: [rt-users] FW: Issue upgrading to 4.2.x
On Wed, 2013-11-20 at 14:34 -0500, Adam Hutchins wrote: Did you attempt the 4.0 - 4.2 upgrade at some earlier point? Not that I'm aware of. That's extremely odd. Can you show the output of: mysqldump -u root rt4 -p --no-data - Alex
