Re: [rt-users] Outgoing email text of a closing incident
No answers yet so it is still an open question. More precisely: where can I change the default outgoing email message sent by the system to whom the Incident Report came when a whole case (e.g. Report,Incidents and Investigations are all solved) is closed? Is there a file for it (could not find it yet) or is it in the RT database somewhere? Any help would be appreciated. Tamas on 2014.12.03. 14:32 Tamás, Szép wrote: Hello all, where can I find and modify the text of the outgoing email when I close a whole Incident? Best regards, Tamas Szep GovCERT-Hungary
Re: [rt-users] Default Configuration RT
Does anyone know how to get the default config back to the RT system ? Renato Gentil Date: Thu, 4 Dec 2014 15:49:41 +0100 From: sven.sternber...@desy.de To: renatorodrigo...@hotmail.com Subject: Re: [rt-users] Default Configuration RT Hi! about which configuration you are talking exactly. genaerally if you have no data to preserve it is simple just go to the install directory and make dropdb make initialize-database and maybe remove all lines in /opt/rt4/etc/RT_SiteConfig.pm you made if you have to preserve your data im not sure how to do it, then you should only edit RT_SiteConfig.pm regards Sven - Ursprüngliche Mail - Von: rgentil renatorodrigo...@hotmail.com An: rt-users@lists.bestpractical.com Gesendet: Donnerstag, 4. Dezember 2014 11:58:07 Betreff: [rt-users] Default Configuration RT Hi Guys, I'd like to know if it is possible to install the default configuration on Request -TRacker. The reason I'm asking this is because I made a change on the system and a lots of things stopped working and I want to install the default config again and restart doing my changes. Thanks -- View this message in context: http://requesttracker.8502.n7.nabble.com/Default-Configuration-RT-tp59108.html Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] plugins link to module file, not package file
So here’s my perspective. As someone with 25 years of sysadmin experience, who has both used RT for many years (but not in the last three years) and someone who uses CPAN fairly often, when sent to the pm module directly, I did the operations directly in front of me and downloaded the .pm and tried to figure out how to install it. There is nothing in the documentation as it stands today to inform a new or dead-brained returning user that they need to download a package, not the .pm file —which in CPAN is often the sum total of an extension. Yes, there is a link to the package file on the page — off on the right, out of the “actionable” area of the screen, if you spend any time with usability experts. Given that the link is not in the user working area, and there’s no reason given to the user to search for the link, I suspect many others will make the same mistake. I outlined this confusion in detail in my original post, showing how I had misunderstood. I believe that any change which makes it clear to the user that they should download the entire package, not just the .pm file, would significantly improve the user experience. On Dec 3, 2014, at 2:09 AM, Alex Peters a...@peters.net wrote: I think I might be missing something crucial in what you are saying/asking. Linking to the main module within a distribution is a very common practice, because that module is likely to have the most relevant documentation for that distribution. The distribution is clearly linked to on the page of every module belonging to a particular distribution. Asking the user to edit the URL in their browser window to be able to find the extension to download doesn’t make a lot of sense is essentially a fallacy, because: the download link for the extension is available on that very page; and the home page for the extension itself (which in my opinion is generally far less informational anyway) is available as a link on that very page. Can you please rephrase why you feel that the links in the directory should be changed? Your assertion that these links are broken in their current form is confusing to me. On 3 December 2014 at 18:40, Jo Rhett jrh...@netconsonance.com wrote: As I said below, in the Extensions directory the links are broken. For example, Homepage link takes you to: http://search.cpan.org/dist/RT-Extension-MandatorySubject/lib/RT/Extension/MandatorySubject.pm If you’re a bit tired and under-caffeniated, or just plain new to RT, it may not be clear to you that you need to remove a bunch from the URL to find the extension package. In my opinion, it would be much better to link to the package instead of the module file, like so: http://search.cpan.org/dist/RT-Extension-MandatorySubject/ As I just said, asking the user to edit the URL in their browser window to be able to find the extension to download doesn’t make a lot of sense. The links in the directory should be fixed. On Dec 2, 2014, at 11:34 PM, Alex Peters a...@peters.net wrote: Could you please clarify what you're asking here? How to install the plugins? The plugins can be installed like any other CPAN module. Given a link to a specific .pm file: http://search.cpan.org/dist/RT-Extension-MandatorySubject/lib/RT/Extension/MandatorySubject.pm you can hit the Download link on the right side of the page to receive a .tar.gz file of the distribution, which can either be fed directly into the cpan or cpanm utilities, or unpacked and installed manually using Makefile.PL and make. With RT extensions, you may find it useful to set environment variable RTHOME to the root directory of your RT installation before installing the plugin: $ RTHOME=/opt/rt-4.2.7 cpanm RT-Extension-MandatorySubject-0.05.tar.gz On 3 December 2014 at 16:19, Jo Rhett jrh...@netconsonance.com wrote: Hey, dunno if this got overlooked during the short vacation week. This is a pretty serious issue… asking users to manually hack up the URL in their browser bar is not accessible. On Nov 26, 2014, at 2:22 PM, Jo Rhett jrh...@netconsonance.com wrote: Hey guys and gals, been a long time. I’m doing an upgrade from 3.8.5 to 4.2. It seems to be going well. I’m liking the changes. Other than some confusion about what order to do things in (see my other message) the one thing I can’t seem to wrap my head around is the new plugin setup. First, yay! I like the idea of what you’ve done with plugins, keeping them local and the simplified syntax in RT_SiteConfig.pm. [in which I wander in the wrong direction… read and giggle] However, I can’t find any plugins other than yours which are built in these new packages you document at https://www.bestpractical.com/docs/rt/4.2/writing_extensions.html What is the fallback method for installing the other style modules? How do I get from a .pm file to an installed module. Can I manually create the directory structures
Re: [rt-users] docs improvement suggestion for full-text searching
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 5, 2014, at 8:07 AM, Alex Vandiver ale...@bestpractical.com wrote: On 12/01/2014 04:11 PM, Jo Rhett wrote: version 2.0.8-1 rpm package for EL6 compat_sphinxql_magics was added in 2.0.1-beta, defaults to 0 in 2.1.1-beta, and was removed in 2.2.1-beta. I'm hesitant to add something to the documented configuration which will cause sphinx to fail on all other versions. Can you explain the failure mode of not having it more clearly? binlog_path was added in 1.10 -- I've added it, with a comment to the versions it's pertinent to. - Alex -- Jo Rhett +1 (415) 999-1798 Skype: jorhett Net Consonance : net philanthropy to improve open source and internet projects.
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.
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
refuses to run, please show your configuration file, the sphinx version,
and the actual error when running without compat_sphinxql_magics.
- Alex
-bash-4.1# rm /opt/rt4/var/sphinx/*
-bash-4.1# indexer --config tmp.conf rt
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 'tmp.conf'...
indexing index 'rt'...
WARNING: Attribute count is 0: switching to none docinfo
collected 1 docs, 0.0 MB
sorted 0.0 Mhits, 100.0% done
total 1 docs, 626 bytes
total 0.009 sec, 64073 bytes/sec, 102.35 docs/sec
total 2 reads, 0.000 sec, 0.3 kb/call avg, 0.0 msec/call avg
total 6 writes, 0.000 sec, 0.3 kb/call avg, 0.0 msec/call avg
-bash-4.1# cat tmp.conf
source rt {
type= mysql
sql_host= 127.0.0.1
sql_db = rt4
sql_user= root
sql_pass=
sql_query_pre = SET NAMES utf8
sql_query = \
SELECT a.id, a.content FROM Attachments a \
JOIN Transactions txn ON a.TransactionId = txn.id AND
txn.ObjectType = 'RT::Ticket' \
JOIN Tickets t ON txn.ObjectId = t.id \
WHERE a.ContentType = 'text/plain' AND t.Status != 'deleted'
sql_query_info = SELECT * FROM Attachments WHERE id=$id
}
index rt {
source = rt
path= /opt/rt4/var/sphinx/index
docinfo = extern
charset_type= utf-8
}
indexer {
mem_limit = 32M
}
searchd {
port= 3312
log = /opt/rt4/var/sphinx/searchd.log
query_log = /opt/rt4/var/sphinx/query.log
read_timeout= 5
max_children= 30
pid_file= /opt/rt4/var/sphinx/searchd.pid
max_matches = 1000
seamless_rotate = 1
preopen_indexes = 0
unlink_old = 1
}
[rt-users] [rt-announce] Assets 1.02
We are pleased to announce Assets 1.02. This release improves bulk update, allows for catalog-specific formats for search results, fixes sorting of assets, allows for quicker lookup of single assets, and simplifies the installation steps to agree with other RT extensions. https://download.bestpractical.com/pub/rt/release/RT-Extension-Assets-1.02.tar.gz https://download.bestpractical.com/pub/rt/release/RT-Extension-Assets-1.02.tar.gz.asc SHA1 sums 8fae329b4630b4a520defd08db942c3723e9d203 RT-Extension-Assets-1.02.tar.gz c76c5a105126f0d1ecf36b57a62fd5e8a06cad28 RT-Extension-Assets-1.02.tar.gz.asc Changes from 1.01: * Special-case and support 'NULL' in custom field searches * Include global asset CFs in spreadsheet download * Fix bulk update of asset roles * Improve two-column layout of role bulk update * Support adding multiple space-separated assets to a ticket at once * Rename Download TSV to the more correct and generic Download Spreadsheet * Ensure that global (applied across all catalogs) custom fields are also shown during asset search * Avoid errors when a singular role group (e.g. Owner) is disabled. * AssetSearchFormat may now be a hashref, for catalog-specific formats * Allow the standard RT extension install ordering of make initdb prior to adding to @Plugins * Fix sorting of assets by custom field and role * Jump directly to asset display page if a numeric asset is searched for A complete changelog is available from git by running: git log 1.01..1.02 or visiting https://github.com/bestpractical/rt-extension-assets/compare/1.01...1.02 ___ rt-announce mailing list rt-annou...@lists.bestpractical.com http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce
Re: [rt-users] filter error in RT-Authen-ExternalAuth
My error was thinking attr_match_list and attr_map were not dependent on
each other. The following change works:
#
name
'attr_match_list' = [
'Name',
],
# Import the following properties of the user from LDAP
upon
#
login
'attr_map' = {
'Name' = 'uid',
'RealName' = 'cn',
},
On 12/05/2014 02:44 PM, Pete Ashdown wrote:
I'm using an LDAP filter, that otherwise works, in
RT-Authen-ExternalAuth that is giving me an perl error that I'm having
trouble getting rid of. Here is my configuration (names changed to
protect the innocent):
Set($ExternalSettings, {
'My_LDAP' = {
'type' = 'ldap',
'server' = 'ldap.myorg.org',
'user' = 'cn=authentication,ou=widgets,o=myorg',
'pass' = 'SUPERSEKRET',
'tls' = 1,
'base' = 'ou=accounts,o=myorg',
'filter' = '(objectClass=FooBarBoo)',
'd_filter' = '(objectClass=Deactivated)',
'net_ldap_args' = [ version = 3 ],
# Users are allowed to log in via email address or account
# name
'attr_match_list' = [
'uid',
],
# Import the following properties of the user from LDAP upon
# login
'attr_map' = {
'RealName' = 'cn',
},
},
} );
And here's the error:
[28018] [Thu Dec 4 22:34:57 2014] [error]: Can't locate object method
as_string via package (objectClass=FooBarBaz) (perhaps you forgot to
load (objectClass=FooBarBoo)?) at
/usr/local/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm
line 469.
I've tried quoting, escaping, and staring blankly at the code for hours
on end, but filter just doesn't digest. Can any tell me what I'm missing?
Re: [rt-users] plugins link to module file, not package file
Am 08.12.2014 um 19:09 schrieb Jo Rhett: Which is said where and how? The point is to improve the documentation such that available paths for installation are clear. Your suggestion for yet another undocumented path is just further argument that the extensions documentation should be improved. I think you missed that RT extension are Perl modules. If they are available on CPAN, you can install them the CPAN way which is documented here: http://www.cpan.org/modules/INSTALL.html Chris
