Re: [rt-users] docs improvement suggestion for full-text searching
On 12/08/2014 01:12 PM, Jo Rhett wrote: Sphinx refuses to run without that parameter. Which given that it wasn’t defined in the file they really should have set the default appropriately and not whined at the user, but this is the version of Sphinx currently in RHEL EPEL so there’s going to be a lot of RHEL/CentOS users running into this problem. On Dec 8, 2014, at 11:24 AM, Alex Vandiver ale...@bestpractical.com wrote: I can't replicate the compat_sphinxql_magics problems you report with a stock Sphinx 2.0.8 from EPEL on CentOS 6. With a stock configuration as provided by 4.2-trunk, indexer runs with no errors (see below). If it RT's use of sphinx requires the daemon to answer, which you didn’t start. With your example file when I start the daemon I get this error: # service searchd start Starting searchd: Sphinx 2.0.8-id64-release (r3831) Copyright (c) 2001-2012, Andrew Aksyonoff Copyright (c) 2008-2012, Sphinx Technologies Inc (http://sphinxsearch.com) using config file '/etc/sphinx/sphinx.conf'... WARNING: compat_sphinxql_magics=1 is deprecated; please update your application and config Note that your file doesn’t contain magics=1. So I totally agree that it’s an annoying bug that the developers should fix, but it’s also something you can avoid by putting it in the file you output. -- Jo Rhett +1 (415) 999-1798 Skype: jorhett Net Consonance : net philanthropy to improve open source and internet projects.
[rt-users] How to delete a asset record from the Asset Tracker using shredder
Hi Team, I wanted the steps to delete a wrongly created asset from the Asset Tracker ( 1.02) Database in RT 4.2.9 I cannot find any write up apart from the delete section of the asset tracker extension documentation. -- *Shrikant Mhatre* *IOT InfraStructure Energy Services Ltd* Plot Y2, CEAT Tyre Road, Near Nahur Railway Station, Bhandup (West), Mumbai 400078. Contact : +91 22 61524 500/600/700/800/900 _www.iotinfraenergy.com http://www.iotinfraenergy.com/_ Disclaimer: This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by return e-mail message (shrikant.mha...@iotgroup.in) and delete the original transmission, its attachments, and any copies without reading or saving in any manner. Thank you. Disclaimer: This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by return e-mail message (shrikant.mha...@iotgroup.in) and delete the original transmission, its attachments, and any copies without reading or saving in any manner. Thank you.
Re: [rt-users] Trying to shred a ticket
Just wondering if anyone can shed some light on how to delete this ticket? Thanks for the help Bryon Baker Network Operations Manager Copesan - Specialists in Pest Solutions 800-267-3726 • 262-783-6261 ext. 2296 bba...@copesan.commailto:cstep...@copesan.com www.copesan.comhttp://www.copesan.com/ Servicing North America with Local Care From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Bryon Baker Sent: Friday, December 12, 2014 5:06 PM To: rt-users Subject: Re: [rt-users] Trying to shred a ticket An Update I found information about Dependencies and raised the limit to 10 which does not seem to help. Also the only scripts running against this tick is an action using rt-crontool. Here is the full error /opt/rt4/sbin/rt-shredder --plugin 'Tickets=query,Id=145013' SQL dump file is '/home/admin/20141212T230121-0001.sql' Next 1 objects would be deleted: RT::Ticket-145013 object Do you want to proceed? [y/N] y ERROR: Dependencies list has reached its limit. See $RT::DependenciesLimit in RT::Shredder docs. [30789] [Fri Dec 12 23:01:57 2014] [warning]: Too late to safely run transaction-batch scrips! This is typically caused by using ticket objects at the top-level of a script which uses the RT API. Be sure to explicitly undef such ticket objects, or put them inside of a lexical scope. at /opt/rt4/sbin/../lib/RT/Ticket.pm line 2615, STDIN line 1 during global destruction. (/opt/rt4/sbin/../lib/RT/Ticket.pm:2615) Again thanks for any help and or pointer given. Bryon Baker Network Operations Manager Copesan - Specialists in Pest Solutions 800-267-3726 • 262-783-6261 ext. 2296 bba...@copesan.commailto:cstep...@copesan.com www.copesan.comhttp://www.copesan.com/ Servicing North America with Local Care From: Bryon Baker Sent: Friday, December 12, 2014 4:22 PM To: rt-users Subject: Trying to shred a ticket I am trying to shred a ticket and I am issuing the following command. /opt/rt4/sbin/rt-shredder –force --plugin 'Tickets=query,Id=145013' I want this ticket to just go away. I am getting the following error. [28230] [Fri Dec 12 22:14:02 2014] [warning]: Too late to safely run transaction-batch scrips! This is typically caused by using ticket objects at the top-level of a script which uses the RT API. Be sure to explicitly undef such ticket objects, or put them inside of a lexical scope. at /opt/rt4/sbin/../lib/RT/Ticket.pm line 2615, STDIN line 1 during global destruction. (/opt/rt4/sbin/../lib/RT/Ticket.pm:2615) I am running RT 4.2.3 Copyright 1996-2014 Thanks for any help I can get. Bryon Baker Network Operations Manager Copesan - Specialists in Pest Solutions 800-267-3726 • 262-783-6261 ext. 2296 bba...@copesan.commailto:cstep...@copesan.com www.copesan.comhttp://www.copesan.com/ Servicing North America with Local Care
[rt-users] Customiz theme -- Title Bar
Hi all - Running RT 4.2.9 and it seems as though that I can't customize the color of the *Title Bar*. Changing the color of any other page section works fine. I've tried in multiple browsers and get the same result. Is this a known bug? Or am I missing something? -- Max McGrath Network Administrator Carthage College 262-552-5512 mmcgr...@carthage.edu
Re: [rt-users] unordered mismash of upgrade instructions
On 11/26/2014 05:32 PM, Jo Rhett wrote: I’m doing an upgrade from 3.8.5 to 4.2. It seems to be going well. I’m liking the changes. Glad to see RTFM integrated. My one big question here that I think the documentation could definitely improve upon, is what order to do the changes in? There are changes in every one of these pages and there’s no clear outline for which ones go first. https://www.bestpractical.com/docs/rt/4.2/README.html …(list of files)... On Dec 4, 2014, at 2:08 PM, Alex Vandiver ale...@bestpractical.com wrote: Step (2) and (6b) of this address the other files. These are the sections of which my complaint is generated. Yes, they list the entire stack of docs which should be read. That’s how I knew the list I posted. But there is no ordering information included here. The top of UPGRADING.mysql even tells you to start there. A bug in the POD - html (now fixed) causes it to not show up in the website, but it's in the shipped docs/UPGRADING.mysql in the source tarball. Yes the revised page is more clear. It’s still not the easiest to track instruction. You could easily demonstrate this with screenshots in a way that someone could follow. Furthermore, this phrasing is very confusing and implies that nothing else in the documentation applies. • You are upgrading RT from a version prior to 3.8.0, on any version of MySQL • You are migrating from MySQL 4.0 to MySQL 4.1 or above If neither of the above cases apply, your should upgrade as per the instructions in the README. So if I am upgrading MySQL 5.1 with RT 3.8.5 I shouldn’t read any farther, right? I don’t think that’s what you intended to say. -- Jo Rhett +1 (415) 999-1798 Skype: jorhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: [rt-users] Documentation for installing extensions
On 12/12/2014 02:39 AM, Jo Rhett wrote: Linking to the documentation makes sense. Linking to the module docs without any clear installation instructions does not. On Dec 12, 2014, at 10:06 AM, Alex Vandiver ale...@bestpractical.com wrote: Picking a commonly-used module, RT::Extension::SLA, and looking at the documentation we link to: http://search.cpan.org/~alexmv/RT-Extension-SLA-1.03/lib/RT/Extension/SLA.pm#INSTALLATION It contains an INSTALLING section which details the steps necessary to install the module. I believe that all, or nearly all, of the modules that Best Practical places on CPAN have a similar section. I’m not sure where you are looking. I’m at https://www.bestpractical.com/rt/extensions.html and it links to https://metacpan.org/pod/RT::Extension::SLA without #INSTALLATION. None of the modules I looked at or included in my original report linked to an INSTALLATION section. In a section below I go through the first six modules provided by BP, and not a single one of them links to installation instructions, and most of them don’t have that section at all. It seems you’ve updated this to link to MetaCPAN now. That does look better, but I’m not sure that the “Source Code” link is truly an improvement, for a reason I’ll describe in my next reply below (read down) Can you point me at documentation which suggests downloading one file from CPAN and putting it in place manually? Perl's own core documentation (http://perldoc.perl.org/perlmodinstall.html ) suggests: And this is the core issue that both you and Alex Peters seem to be hung up on, which I keep addressing over and over again but it’s not getting through. Let me try another way. Puppet is written in Ruby. Puppet modules are written in Ruby and Puppet Ruby-DSL. If you want to write a really good Puppet module, you need to be a Ruby coder. HOWEVER, tens if not hundreds of thousands of people use Puppet and install Puppet modules (e.g. extensions) without knowing how to code in Ruby, without having read the Ruby documentation, and without being able to write a single line of Ruby code. They are able to install and use Puppet extensions, without ever learning Ruby. I would think that this would be a desirable situation for RT. Nearly nobody is hiring these days for Perl knowledge, and that every company I’ve worked at in the last 10 years has been replacing and removing Perl in favor of Python or Ruby. There are numerous places who have refused to consider RT simply because they don’t support Perl. Given this environment today, there is significant advantage for Best Practical to lower that barrier to entry, and make RT work without Perl competency. Obviously there are numerous places that BP would need to change the installation process to make this work better, however this is clearly one of those places. It would be an improvement. Can you point me at documentation which suggests downloading one file from CPAN and putting it in place manually? You linked directly to the singular file. That is the appropriate approach for many, many systems where the plugin is a single file. Remember that there are no sysadmins who know nothing beyond RT and never use any systems beyond RT. Perl's own coredocumentation (http://perldoc.perl.org/perlmodinstall.html ) suggests: ... These are thus the steps which RT extensions mirror in their installation. I have used numerous self-contained Perl applications which would not work properly if you simply CPANed the module in. I’ve worked in two companies who exclusively used their own library paths to avoid the breakage associated with random CPAN upgrades. No, it is not “obvious” that simply using CPAN or any other “standard perl thing” to install the package would be appropriate. So let’s start at the top of extensions try to follow the clear process for each one. For this I’m going to exclusively use modules provided by Best Practical. https://metacpan.org/pod/RT::Extension::ActivityReports#INSTALLATION — does not link to installation as you suggested above — forgets to mention that you need -I /opt/rt4/lib” so fails on my fresh 4.2.9 installation https://metacpan.org/pod/RT::Extension::ActivityReports::Billing — error, not found https://metacpan.org/pod/RT::Extension::AddAdminCcsOnQueueChange — no installation instructions https://metacpan.org/pod/RT::Extension::AttributeWalker — no installation instructions https://metacpan.org/pod/RT::Authen::Bitcard — no installation instructions https://metacpan.org/pod/RT::Authen::ExternalAuth#INSTALLATION — does not link to installation as you suggested above — forgets to mention that you need -I /opt/rt4/lib” so fails on my fresh 4.2.9 installation Do I really need to keep going? In short, yes a Perl hacker can figure this out. Is your target audience ONLY perl hackers? This is the key point I’m trying to get through. If you
Re: [rt-users] unordered mismash of upgrade instructions
On 12/14/2014 08:19 PM, Jo Rhett wrote: On Dec 4, 2014, at 2:08 PM, Alex Vandiver ale...@bestpractical.com wrote: Step (2) and (6b) of this address the other files. These are the sections of which my complaint is generated. Yes, they list the entire stack of docs which should be read. That’s how I knew the list I posted. But there is no ordering information included here. We've not previously had explicit documentation on it because there's no strict ordering -- so we didn't specify it. I've pushed b49f950b to 4.0-trunk which gives a more explicit ordering. Would that have sufficed to answer your question? Yes the revised page is more clear. It’s still not the easiest to track instruction. You could easily demonstrate this with screenshots in a way that someone could follow. What screenshots would you find useful? Furthermore, this phrasing is very confusing and implies that nothing else in the documentation applies. • You are upgrading RT from a version prior to 3.8.0, on any version of MySQL • You are migrating from MySQL 4.0 to MySQL 4.1 or above If neither of the above cases apply, your should upgrade as per the instructions in the README. So if I am upgrading MySQL 5.1 with RT 3.8.5 I shouldn’t read any farther, right? I don’t think that’s what you intended to say. If you're upgrading MySQL 5.1 with RT 3.8.5, you should just follow the upgrading instructions in the README; UPGRADING.mysql does indeed not apply. So yes, you have interpreted as we intended. If you have suggested clarifications, I'd be glad to hear them. - Alex
Re: [rt-users] Continued Migrations Questions -
I've not completed it yet. Matt Wells | Chief Systems Architect Red Hat Certified Architect II- #110-000-353 GPG Public Key ID: 0x1438A3EB Mosaic451 702.808.0424 (mobile) 877.799.2411 (S/NOC) matt.we...@mosaic451.com On Fri, Dec 12, 2014 at 8:16 PM, Alex Peters a...@peters.net wrote: Did you end up resolving this? If I understand correctly, you want outgoing mail that has a different domain in the From: address to be sent through the SMTP server belonging to that domain (i.e. a remote SMTP server). I don't believe that's possible within RT itself. On Thu, 23 Oct 2014 2:36 am Matt Wells matt.we...@mosaic451.com wrote: On my continued migration from ZenDesk I've come across something that honestly I've not done with RT. Templates, Queues and app configuration, I feel good with. Something unique to my current workplace is the need for multiple domains email addresses. I know I can catch this downstream in a postfix server and write a filter for it but I wanted to see if RT could do it. My domain is example.com Queue 1 Email - supp...@example.com Queue 2 Email - n...@example.com Queue 3 Email - supp...@companyabc.com I need to relay mail through their smtp system. Can you do that per queue? Like I said, I can catch it downstream with postfix but something in the app would just be cleaner. Honestly, it's been a while since I ran RT in the workplace and I had forgotten how awesome these groups are. -- RT Training November 4 5 Los Angeles http://bestpractical.com/training
Re: [rt-users] docs improvement suggestion for full-text searching
On 12/14/2014 08:25 PM, Jo Rhett wrote: RT's use of sphinx requires the daemon to answer, which you didn’t start. With your example file when I start the daemon I get this error: # service searchd start Starting searchd: Sphinx 2.0.8-id64-release (r3831) Copyright (c) 2001-2012, Andrew Aksyonoff Copyright (c) 2008-2012, Sphinx Technologies Inc (http://sphinxsearch.com) using config file '/etc/sphinx/sphinx.conf'... WARNING: compat_sphinxql_magics=1 is deprecated; please update your application and config As the output notes, that is merely a warning. It is not an error. searchd starts up just fine for me: # service searchd start Starting searchd: Sphinx 2.0.8-id64-release (r3831) Copyright (c) 2001-2012, Andrew Aksyonoff Copyright (c) 2008-2012, Sphinx Technologies Inc (http://sphinxsearch.com) using config file '/etc/sphinx/sphinx.conf'... WARNING: compat_sphinxql_magics=1 is deprecated; please update your application and config listening on all interfaces, port=3312 precaching index 'rt' precached 1 indexes in 0.001 sec [ OK ] # service searchd status searchd (pid 15041) is running... Note that your file doesn’t contain magics=1. So I totally agree that it’s an annoying bug that the developers should fix, but it’s also something you can avoid by putting it in the file you output. Since it starts up fine without the line, and would fail to start on Sphinx 2 or 2.2 with the line, I'm unconvinced on adding it to the default configuration. Administrators who are running Sphinx 2.0.x can simply heed the warning and add compat_sphinxql_magics=0 to their configuration. - Alex
Re: [rt-users] Documentation for installing extensions
On 12/14/2014 07:23 PM, Jo Rhett wrote: I’m not sure where you are looking. I’m at https://www.bestpractical.com/rt/extensions.html and it links to https://metacpan.org/pod/RT::Extension::SLA without #INSTALLATION. Sorry -- I did not mean to imply that our link contained the #INSTALLATION anchor, merely pointing out that the SLA extension does contain what I believe to be clear installation instructions. I choose to believe that users are capable of scrolling down to the third heading on the page. It seems you’ve updated this to link to MetaCPAN now. That does look better, but I’m not sure that the “Source Code” link is truly an improvement, for a reason I’ll describe in my next reply below (read down) I agree that most users won't need the github link; it is mostly superfluous, as metacpan provides it in most cases. I've removed it for all of the extensions which are on CPAN, which is most of them. Can you point me at documentation which suggests downloading one file from CPAN and putting it in place manually? Perl's own core documentation (http://perldoc.perl.org/perlmodinstall.html ) suggests: And this is the core issue that both you and Alex Peters seem to be hung up on, which I keep addressing over and over again but it’s not getting through. Let me try another way. I was not trying to argue that we cannot make this simpler for new users -- I agree that we can, and should. I was primarily addressing what seemed to be your belief that most CPAN modules could be installed via copying a single file, or that this was a widely documented custom for CPAN modules. I hear you that modules in other languages are often more straightforward to install than Perl's -- and that while our bar for installation is currently set at the same as Perl's, that is not to say that we cannot do better. So let’s start at the top of extensions try to follow the clear process for each one. For this I’m going to exclusively use modules provided by Best Practical. That list has absolutely needed better curation for a while; for instance, it didn't list 4.2 compatibility for the majority of the extensions. Thank for calling out some of the entries that need updating, and providing impetus for fixing them. https://metacpan.org/pod/RT::Extension::ActivityReports#INSTALLATION — does not link to installation as you suggested above — forgets to mention that you need -I /opt/rt4/lib” so fails on my fresh 4.2.9 installation Where did you find you needed to add -I /opt/rt4/lib ? With a fresh 4.2.9 in /opt/rt4, the installation instructions work fine for me: https://chmrr.net/nopaste/2014-12-15l4EVqmFw https://metacpan.org/pod/RT::Extension::ActivityReports::Billing — error, not found This extension was last updated in 3.8, which is why it never got to CPAN. I've removed it from the list. https://metacpan.org/pod/RT::Extension::AddAdminCcsOnQueueChange — no installation instructions Pushed an updated version with our canonical installation instructions, and version compatibility notes. https://metacpan.org/pod/RT::Extension::AttributeWalker — no installation instructions Adds a command-line tool, which is probably not useful for most users; I've removed it from the list. https://metacpan.org/pod/RT::Authen::Bitcard — no installation instructions Written for rt.perl.org and rt.cpan.org, but unlikely to be useful to anyone else; I've removed it from the list. https://metacpan.org/pod/RT::Authen::ExternalAuth#INSTALLATION — does not link to installation as you suggested above — forgets to mention that you need -I /opt/rt4/lib” so fails on my fresh 4.2.9 installation As above. Do I really need to keep going? Did you have feedback on the generalized installation instructions that I posted earlier in this thread? https://github.com/bestpractical/rt/blob/4.2/installing-extensions/docs/extensions.pod In short, yes a Perl hacker can figure this out. Is your target audience ONLY perl hackers? This is the key point I’m trying to get through. If you only want to sell RT and its services to Perl hackers, then feel free to ignore my advice. I don't disagree that plugin installation could be made better, and it's an area we'd like to improve on. Where you've made actionable suggestions, I believe we've responded to the best of our ability. The larger-scale changes necessary to make plugins be one-click installs cannot, obviously, appear overnight. RT is open-source; if you support a number of RT installations and have a vested interest in making plugin installation easier for your clients, patches in this area would certainly be accepted. - Alex
[rt-users] How do the 'One-time Cc' and 'One-time Bcc' lists get populated
Hi RT Users, I am trying to clear an address that keeps appearing in the One-time Cc/Bcc list on the Reply form for a ticket. The user is no longer here, but the address keeps showing up in the Reply form for new tickets. How is that list constructed? Regards, Ken
Re: [rt-users] Documentation for installing extensions
On Dec 15, 2014, at 2:20 PM, Alex Vandiver ale...@bestpractical.com wrote: I was not trying to argue that we cannot make this simpler for new users -- I agree that we can, and should. I was primarily addressing what seemed to be your belief that most CPAN modules could be installed via copying a single file, or that this was a widely documented custom for CPAN modules. Again, back to “you must be a perl hacker to use RT”. My entire point is that installation instructions can and should be self-sufficient, without requiring a person to utilize “common knowledge” of something they might not be experts in. I hear you that modules in other languages are often more straightforward to install than Perl's -- and that while our bar for installation is currently set at the same as Perl's, that is not to say that we cannot do better. Take a look at the published usage charts for the Perl language and decide if you want RT to have the same (plummeting) trajectory. I don't disagree that plugin installation could be made better, and it's an area we'd like to improve on. Where you've made actionable suggestions, I believe we've responded to the best of our ability. The larger-scale changes necessary to make plugins be one-click installs cannot, obviously, appear overnight. Puppet modules are not one-click installations. In fact, I can’t think of any extensions outside of web browser extensions which are even a few clicks. This is not what I have said. I have suggested that the installation instructions should be self-standing and complete. This is a significantly easier task. Where did you find you needed to add -I /opt/rt4/lib Perhaps phrased more straightforward — what about your installation places /opt/rt4/lib in @INC ? Without that, it cannot find the RT-specific paths and makefile creation fails. I suspect you’ve got this in your path because RT is your job. That’s not true of a normal person. You shouldn’t test in your RT dev setup. -- Jo Rhett +1 (415) 999-1798 Skype: jorhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: [rt-users] Documentation for installing extensions
On 12/15/2014 06:20 PM, Jo Rhett wrote: Again, back to “you must be a perl hacker to use RT”. My entire point is that installation instructions can and should be self-sufficient, without requiring a person to utilize “common knowledge” of something they might not be experts in. I've just verified that all of BPS' packages that we list on the Extensions page contain an INSTALLATION section which is up-to-date, which I believe removes any necessity for common knowledge. I don't disagree that plugin installation could be made better, and it's an area we'd like to improve on. Where you've made actionable suggestions, I believe we've responded to the best of our ability. The larger-scale changes necessary to make plugins be one-click installs cannot, obviously, appear overnight. Puppet modules are not one-click installations. In fact, I can’t think of any extensions outside of web browser extensions which are even a few clicks. This is not what I have said. Nor did I claim that was what you said; it was what _I_ would ideally want. Apologies if that was unclear. I have suggested that the installation instructions should be self-standing and complete. This is a significantly easier task. As noted above, I believe I've verified that all of our extensions now contain up-to-date INSTALLATION sections, which I believe suffices to mark that task as accomplished. Do you think that that, combined with https://github.com/bestpractical/rt/blob/4.2/installing-extensions/docs/extensions.pod will sufficiently help new users? If not, what would improve on the situation? Where did you find you needed to add -I /opt/rt4/lib Perhaps phrased more straightforward — what about your installation places /opt/rt4/lib in @INC ? Without that, it cannot find the RT-specific paths and makefile creation fails. The Module::Install::RTx machinery, loaded from inc/ by the Makefile.PL, takes care of checking the the standard install locations for RT, and setting the installation prefix accordingly. It is part of the package itself, and not part of my environment. In fact, if it _fails_ to find your RT.pm, it should be prompting you: $ perl Makefile.PL Cannot find the location of RT.pm that defines $RT::LocalPath in: [snip contents of @INC] Path to directory containing your RT.pm: ...whereupon providing the path will cause it to carry on, and install appropriately in your non-standard RT prefix. Hence, if running 'perl Makefile.PL' is failing for you, I'd be quite curious to see how, so we can fix it. I suspect you’ve got this in your path because RT is your job. That’s not true of a normal person. You shouldn’t test in your RT dev setup. We test things like this in clean VMs explicitly to prevent that. If it fails for you, then that is a bug -- and one that we certainly should address. - Alex
