Re: [rt-users] Default Configuration RT
Hi Renato, What exactly did you try, and what happened? Going into MySQL, dropping the database (or all of its tables) and running the sbin/rt-setup-database script would restore all of your templates and scrips. Specifically, you would probably do this if your MySQL user has the permissions to drop the database: $ cd RT_ROOT_DIRECTORY $ sbin/rt-setup-database --action drop,create,schema,acl,coredata,insert --dba RT_DB_USERNAME --prompt-for-dba-password You can pass --help to the rt-setup-database script for further details. Remove drop,create, from the above line if you'd like to manually remove all of the tables first (using mysql). Please let us know how you go (using Reply All). On 10 December 2014 at 23:02, Renato Gentil renatorodrigo...@hotmail.com wrote: Hi Alex, I tried it but didn't work for me. Basically I'm trying to restore the default templates and scripts because I have deleted some of them and now some of our features have been gone with them. Can you help me with that ? thanks, Renato Gentil -- From: a...@peters.net Date: Wed, 10 Dec 2014 01:12:06 + Subject: Re: [rt-users] Default Configuration RT To: renatorodrigo...@hotmail.com; rt-users@lists.bestpractical.com You could drop the database and set it up again, or also completely uninstall and reinstall RT.
Re: [rt-users] Capturing 'Started' Value
Our company does not want to upgrade, so I need to figure it out in this version. Any thoughts? John John White Application Support Lead +1.301.214.7600 main +1.301.214.6362 direct +1.301.214.7601 fax +1.703.615.4986 cellular -Original Message- From: Alex Vandiver [mailto:ale...@bestpractical.com] Sent: Tuesday, December 09, 2014 11:34 AM To: John White; rt-users@lists.bestpractical.com Subject: Re: [rt-users] Capturing 'Started' Value On 12/09/2014 08:34 AM, john.white wrote: This is for RT ver. 3.8.2. I'm trying to capture the Started field value in the Dates block and place it in a Custom Field (called Started Date) so that I can output that data in the spread sheet reports to perform metrics (don't see how to output that data to the spreadsheets any other way). This trivial in RT 4.0 and later -- the column list that is displayed is the set of columns that are exported in the spreadsheet. Additionally, upgrading to a supported release means you won't be running an RT with publicly disclosed remote exploits. - Alex This email, including any attachments and files transmitted with it, are for the sole use of the intended recipient(s) to whom this email is addressed, and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please be advised that you have received this email in error, and please contact the sender by reply email and destroy all copies (including all electronic and hard copies) of the original message. Thank you.
Re: [rt-users] Default Configuration RT
Alex, I'm trying to drop but I'm getting the error attached.I'm using the following command: mysqladmin -u root -p drop but then I got the error attached and I also tried: mysqladmin -u root -p droppassword: another error attached. Thanks, Renato Gentil Date: Wed, 10 Dec 2014 23:20:30 +1100 Subject: Re: [rt-users] Default Configuration RT From: a...@peters.net To: renatorodrigo...@hotmail.com; rt-users@lists.bestpractical.com Hi Renato, What exactly did you try, and what happened? Going into MySQL, dropping the database (or all of its tables) and running the sbin/rt-setup-database script would restore all of your templates and scrips. Specifically, you would probably do this if your MySQL user has the permissions to drop the database: $ cd RT_ROOT_DIRECTORY$ sbin/rt-setup-database --action drop,create,schema,acl,coredata,insert --dba RT_DB_USERNAME --prompt-for-dba-password You can pass --help to the rt-setup-database script for further details. Remove drop,create, from the above line if you'd like to manually remove all of the tables first (using mysql). Please let us know how you go (using Reply All). On 10 December 2014 at 23:02, Renato Gentil renatorodrigo...@hotmail.com wrote: Hi Alex, I tried it but didn't work for me. Basically I'm trying to restore the default templates and scripts because I have deleted some of them and now some of our features have been gone with them. Can you help me with that ? thanks, Renato Gentil From: a...@peters.net Date: Wed, 10 Dec 2014 01:12:06 + Subject: Re: [rt-users] Default Configuration RT To: renatorodrigo...@hotmail.com; rt-users@lists.bestpractical.com You could drop the database and set it up again, or also completely uninstall and reinstall RT.
Re: [rt-users] Installation error for RT 4.2.9 - cannot initialize database
Thanks for the suggestion. I've tried it, but unfortunately, it recreated the same error: root@10.10.10.3:/tmp/rt-4.2.9# make initialize-database /usr/bin/perl -I/opt/rt4/local/lib -I/opt/rt4/lib sbin/rt-setup-database --action init --prompt-for-dba-password In order to create or update your RT database, this script needs to connect to your mysql instance on 10.20.20.5 (port '3306') as rtuser Please specify that user's database password below. If the user has no database password, just press return. Password: Working with: Type: mysql Host: 10.20.20.5 Port: 3306 Name: rt4 User: rtuser DBA:rtuser Now creating a mysql database rt4 for RT. Done. Now populating database schema. Done. Now inserting database ACLs. [32233] [Wed Dec 10 16:55:31 2014] [warning]: DBD::mysql::st execute failed: Access denied for user 'rtuser'@'%' to database 'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452. (/tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm:452) [32233] [Wed Dec 10 16:55:31 2014] [critical]: DBD::mysql::st execute failed: Access denied for user 'rtuser'@'%' to database 'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452. (/tmp/rt-4.2.9/sbin/../lib/RT.pm:388) DBD::mysql::st execute failed: Access denied for user 'rtuser'@'%' to database 'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452. make: *** [initialize-database] Error 255 I keep wondering why it keeps getting stuck on the step Now inserting database ACLs. Are those handled differently from the previous steps or creating and populating the database? For reference, here are the permissions for rtuser: +---+ | Grants for rtuser@% +---+ | GRANT USAGE ON *.* TO 'rtuser'@'%' IDENTIFIED BY PASSWORD '*hash' | GRANT ALL PRIVILEGES ON `rt4`.* TO 'rtuser'@'%' | GRANT ALL PRIVILEGES ON `rt4test`.* TO 'rtuser'@'%' +---+ On 12/10/2014 2:56 AM, Alex Peters wrote: You're doing this: # make initialize-database which is in turn running this: # /usr/bin/perl -I/opt/rt4/local/lib -I/opt/rt4/lib sbin/rt-setup-database --action init --prompt-for-dba-password which is going to connect to the database as the RT DBA user (RT_Config setting $DatabaseAdmin), which according to your pasted output: In order to create or update your RT database, this script needs to connect to your mysql instance on 10.20.20.5 (port '3306') as root is root. Going off your RT_SiteConfig.pm snippet, you actually want to connect to the database as user rtuser. Therefore, adding this to RT_SiteConfig.pm might solve your issue: Set($DatabaseAdmin, rtuser); On 10 December 2014 at 01:56, Kristan Wagner kristan.wag...@lifewireless.com mailto:kristan.wag...@lifewireless.com wrote: I am having troubles with the database initialization, for a fresh install of RT 4.2.9. The error message is: DBD::mysql::st execute failed: Access denied for user 'root'@'10.10.10.3' to database 'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452. make: *** [initialize-database] Error 255 Here's my setup: Separate servers for the web frontend and the database, both running Ubuntu 14.04. The web frontend is running Apache/2.4.7 and has an IP address 10.10.10.3. The database machine is running MySQL 5.5.40 and has the IP address 10.20.20.5. Both of these are fresh installs, and RT is a fresh install, but we plan to migrate our old RT database (3.6.5) when the 4.2.9 is (eventually) running and tested. Right now, I'm just trying to get 4.2.9 going. Here's the context for the error: I've been following the README on the bestpractical website. At step 2, I ran configure with only one flag, --with-db-host=10.20.20.5. At step 4, fixdeps kept claiming that MySQL was missing, so I had to install MySQL on the web frontend as well, just to get it to install. At step 6a, make initialize-database is failing with the following output: root@10.10.10.3/tmp/rt-4.2.9# http://root@10.10.10.3/tmp/rt-4.2.9# make initialize-database /usr/bin/perl -I/opt/rt4/local/lib -I/opt/rt4/lib sbin/rt-setup-database --action init --prompt-for-dba-password In order to create or update your RT database, this script needs to connect to your mysql instance on 10.20.20.5 (port '3306') as root Please specify that user's database password below. If the user has no database password, just press return. Password: Working with: Type: mysql Host: 10.20.20.5 Port: 3306 Name: rt4 User: rtuser DBA:root Now creating a mysql database rt4 for RT. Done. Now populating database schema. Done. Now inserting database ACLs. [23346] [Mon
[rt-users] RT-Extension-AceEditor
Hi list, Here is an extension that replace the default scrip edition textarea with the embeded Ace editor (http://ace.c9.io) https://github.com/valmiRe/rt-extension-aceeditor Rémi
[rt-users] Errors on user logins --
I'm getting what seems to be a common error when users login. The page you requested could not be found This is only with non-root users. When the users login it redirects to https://rt.example.com/HASH(0x68193a8) If I remove the 'HASH(0x68193a8)' I get my dashboard. I've cleaned out the mason cache and walked through many of the existing 'how to' but to no avail. I've ensured that CPAN modules are all up to date. CentOS 6.6 RT 4.2.9 == /var/log/httpd/error_log == [30947] [Wed Dec 10 17:22:23 2014] [info]: RT::Authen::ExternalAuth::LDAP::GetAuth External Auth OK ( ldapserver_LDAP ): joe.bob (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:161) [30947] [Wed Dec 10 17:22:23 2014] [info]: RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Address1: example, EmailAddress: joe@example.com, Name: joe.bob, RealName: Joe Bob, WorkPhone: 7025551234 (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:665) [30947] [Wed Dec 10 17:22:23 2014] [info]: Successful login for joe.bob from 10.10.10.10 (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:341) Thanks for any and all assistance.
Re: [rt-users] Errors on user logins --
On 12/10/2014 01:09 PM, Matt Wells wrote: I'm getting what seems to be a common error when users login. The page you requested could not be found This is only with non-root users. When the users login it redirects to https://rt.example.com/HASH(0x68193a8) If I remove the 'HASH(0x68193a8)' I get my dashboard. I've cleaned out the mason cache and walked through many of the existing 'how to' but to no avail. I've ensured that CPAN modules are all up to date. CentOS 6.6 RT 4.2.9 == /var/log/httpd/error_log == [30947] [Wed Dec 10 17:22:23 2014] [info]: RT::Authen::ExternalAuth::LDAP::GetAuth External Auth OK ( ldapserver_LDAP ): joe.bob (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:161) [30947] [Wed Dec 10 17:22:23 2014] [info]: RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Address1: example, EmailAddress: joe@example.com mailto:joe@example.com, Name: joe.bob, RealName: Joe Bob, WorkPhone: 7025551234 (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:665) [30947] [Wed Dec 10 17:22:23 2014] [info]: Successful login for joe.bob from 10.10.10.10 (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:341) Thanks for any and all assistance. Which version of RT::Authen::ExternalAuth are you using? Hint 0.25 would be the recommended version. There was a fix for this somewhere between 0.17 and 0.21 if I remember correctly. Jeff
Re: [rt-users] Installation error for RT 4.2.9 - cannot initialize database
Solved this issue. When I created the user 'root'@'10.10.10.3' on the
MySQL server, I used this command:
GRANT ALL PRIVILEGES ON rt4.* TO 'root'@'10.10.10.3';
This gave the root user privileges to manipulate the database, but
**not** to pass on their privileges to others. When I re-granted using
this command:
GRANT ALL PRIVILEGES ON rt4.* TO 'root'@'10.10.10.3' WITH GRANT OPTION;
...the Access denied error vanished. I also had to readjust my
RT_SiteConfig.pm back to using root as the db admin. Solved and archived
for posterity. Thanks!
On 10 December 2014 at 01:56, Kristan Wagner
kristan.wag...@lifewireless.com
mailto:kristan.wag...@lifewireless.com wrote:
I am having troubles with the database initialization, for a fresh
install of RT 4.2.9. The error message is: DBD::mysql::st execute
failed: Access denied for user 'root'@'10.10.10.3' to database
'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452. make:
*** [initialize-database] Error 255
Here's my setup: Separate servers for the web frontend and the
database, both running Ubuntu 14.04. The web frontend is running
Apache/2.4.7 and has an IP address 10.10.10.3. The database
machine is running MySQL 5.5.40 and has the IP address
10.20.20.5. Both of these are fresh installs, and RT is a fresh
install, but we plan to migrate our old RT database (3.6.5) when
the 4.2.9 is (eventually) running and tested. Right now, I'm just
trying to get 4.2.9 going.
Here's the context for the error: I've been following the README
on the bestpractical website. At step 2, I ran configure with only
one flag, --with-db-host=10.20.20.5. At step 4, fixdeps kept
claiming that MySQL was missing, so I had to install MySQL on the
web frontend as well, just to get it to install. At step 6a, make
initialize-database is failing with the following output:
root@10.10.10.3/tmp/rt-4.2.9#
http://root@10.10.10.3/tmp/rt-4.2.9# make initialize-database
/usr/bin/perl -I/opt/rt4/local/lib -I/opt/rt4/lib
sbin/rt-setup-database --action init --prompt-for-dba-password
In order to create or update your RT database, this script needs
to connect to your mysql instance on 10.20.20.5 (port '3306') as root
Please specify that user's database password below. If the user
has no database password, just press return.
Password:
Working with:
Type: mysql
Host: 10.20.20.5
Port: 3306
Name: rt4
User: rtuser
DBA:root
Now creating a mysql database rt4 for RT.
Done.
Now populating database schema.
Done.
Now inserting database ACLs.
[23346] [Mon Dec 8 21:27:35 2014] [warning]: DBD::mysql::st
execute failed: Access denied for user 'root'@'10.10.10.3' to
database 'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452.
(/tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm:452)
[23346] [Mon Dec 8 21:27:35 2014] [critical]: DBD::mysql::st
execute failed: Access denied for user 'root'@'10.10.10.3' to
database 'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452.
(/tmp/rt-4.2.9/sbin/../lib/RT.pm:388)
DBD::mysql::st execute failed: Access denied for user
'root'@'10.10.10.3' to database 'rt4' at
/tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452.
make: *** [initialize-database] Error 255
I've spent a lot of time reading forum questions about
mysqld.sock, but please note that there is NO mention of any
socket trouble in the error, so I don't think that's it. Plus,
it's able to get through the first two steps just fine.
Here is some of RT_SiteConfig.pm from the web frontend:
Set($DatabaseHost, '10.20.20.5' );
Set($DatabasePort, 3306);
Set($DatabasePassword, q{passwordhere});
Set($DatabaseUser, rtuser);
Set($DatabaseName, q{rt4});
On the database server, here is some of my.cnf:
[mysqld]
user= mysql
pid-file= /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port= 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address = 0.0.0.0
I've already tried this using the option skip-name-resolve, but
that did not help.
Here are the permissions for the root user, as shown on
10.20.20.5's MySQL instance:
++
| Grants for root@10.10.10.3 mailto:root@10.10.10.3
++
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'10.10.10.3' IDENTIFIED BY
PASSWORD '*hash'
| GRANT ALL PRIVILEGES ON `rt4`.* TO 'root'@'10.10.10.3'
Re: [rt-users] Errors on user logins --
Jeff my upgrade to V25 failed before. This time it worked (well after two attempts); thanks for the reply and the assist. Lesson of the day read your output. Thanks all! On Wed, Dec 10, 2014 at 11:33 AM, Jeff Voskamp javosk...@uwaterloo.ca wrote: On 12/10/2014 01:09 PM, Matt Wells wrote: I'm getting what seems to be a common error when users login. The page you requested could not be found This is only with non-root users. When the users login it redirects to https://rt.example.com/HASH(0x68193a8) If I remove the 'HASH(0x68193a8)' I get my dashboard. I've cleaned out the mason cache and walked through many of the existing 'how to' but to no avail. I've ensured that CPAN modules are all up to date. CentOS 6.6 RT 4.2.9 == /var/log/httpd/error_log == [30947] [Wed Dec 10 17:22:23 2014] [info]: RT::Authen::ExternalAuth::LDAP::GetAuth External Auth OK ( ldapserver_LDAP ): joe.bob (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/ Authen/ExternalAuth/LDAP.pm:161) [30947] [Wed Dec 10 17:22:23 2014] [info]: RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Address1: example, EmailAddress: joe@example.com mailto:joe@example.com, Name: joe.bob, RealName: Joe Bob, WorkPhone: 7025551234 (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/ Authen/ExternalAuth.pm:665) [30947] [Wed Dec 10 17:22:23 2014] [info]: Successful login for joe.bob from 10.10.10.10 (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/ Authen/ExternalAuth.pm:341) Thanks for any and all assistance. Which version of RT::Authen::ExternalAuth are you using? Hint 0.25 would be the recommended version. There was a fix for this somewhere between 0.17 and 0.21 if I remember correctly. Jeff
Re: [rt-users] plugins link to module file, not package file
I’ve been using Perl for 20 years now. I grok perl. Good run with the insults and rudeness. Because yeah, that’s a great way to treat someone who’s pointing out a way to improve the usability of something. Treat them like dirt, and talk down to them like they’ve never used Perl before. I’ll stop offering advice on ways to improve the UI. Unintelligible and prone to confusion on the part of people isn’t my problem. I’m not going to be helpful if I get treated like shit when I’m trying to make someone’s profit-making production better and more likely to be used. I forgot why I dropped this list. Thanks for reminding me. On Dec 9, 2014, at 5:10 AM, Alex Peters a...@peters.net wrote: I feel that there are actually several issues to discuss in this thread: Perl modules vs. Perl module distributions Perl module distribution sources Perl module distribution installation knowledge assumed by the CPAN site knowledge assumed by RT's documentation what documentation should actually change Based on your description of the steps you performed in an attempt to install a Perl module from CPAN, with all due respect, I believe you've been improperly advised on Perl module installation and possibly haven't been made aware of some crucial things about how Perl's modules work. I'll go over some of those things, then with everything in mind, maybe we can agree on what documentation changes are needed where. Perl modules vs. Perl module distributions A Perl module is (for all intents and purposes of this thread) a single .pm file. A Perl module distribution consists of a number of Perl modules (which can be just one), a Makefile (or more commonly, a Makefile generator in Makefile.PL), and instructions for installation of the distribution and hence its modules (usually in README or INSTALL). Distributions exist because often, a single module isn't enough to provide some meaningful form of functionality. Modules are never installed directly. Modules are always made available as a side effect installing module distributions. The distribution (not the module) is the smallest unit involved in the action of installation. Installation of a distribution might result in the installation of only one module, but nonetheless, it's the distribution that's acted upon directly for installation rather than the module. In summary, direct installation of single modules doesn't happen. Perl module distribution sources Distributions are typically (but not always) available on the CPAN site (typically capitalised as CPAN), and can be downloaded as an archive. Other distribution sources include (but are not limited to) GitHub, Bitbucket, CD-ROMs, FTP sites and personal web pages. In summary, distribution files can come from many different places. Perl module distribution installation Every distribution includes installation instructions in README or INSTALL, and the most typical experience for installing a Perl module distribution (after obtaining an archive of it) goes like this: $ tar xzf My-Perl-Module-0.01.tar.gz $ cd My-Perl-Module-0.01 $ perl Makefile.PL $ make $ make test $ make install Distributions on CPAN can be installed without first downloading an archive, using the CPAN installation tool (typically capitalised as cpan). cpan is actually smart enough to take a module name (rather than a distribution name) on the command line, determine the distribution to which that module belongs, and install that distribution. Since one distribution generally depends on others (prerequisites) being installed in advance, cpan also manages the installation of prerequisite distributions. This makes the use of a tool like cpan the generally preferred means of installing distributions (and by extension, modules). Other similar tools exist which do the job in a more streamlined fashion. I personally prefer cpanm. In summary, distribution installation tools function on distributions, not modules—although some tools have the ability to infer the right distribution if given a module name. Knowledge assumed by the CPAN site Given that a CPAN module page only offers a single Download link, and that link points to an archive of the module's distribution, it's safe to say that the CPAN site assumes that its users already know the distinction between modules and distributions, and expects that the user then refer to the documentation found within the downloaded archive. I suppose the reasoning is that anyone who knows about CPAN already knows about Perl modules, and how to install module distributions. I don't feel that the installation of Perl modules/distributions is within the domain of RT's documentation. However, given RT's use of Perl modules as extensions, and that CPAN would probably be the main source for RT extensions, I feel that perhaps RT's documentation could benefit from at
[rt-users] REST API and acting as users
Hey, I'm looking at integrating RT with the OpenStack Horizon Dashboard for at least ticket creation, ideally listing tickets and showing ticket details for our customers. The RESTful API appears to require logging in with credenials for the RT user. Is it possible to masquerade as another user? Given passwords are stored encrypted, I can't use the users passsword to login. I might be able to cook up a RT::Authen::ExternalAuth plugin to use the existing OpenStack tokens to allow SSO, I haven't look into that yet. Any assistance would be appreciated. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2015 New Zealand's only Cloud: | BeAwesome in Auckland, NZ https://catalyst.net.nz/cloud | http://lca2015.linux.org.au
Re: [rt-users] plugins link to module file, not package file
Jo, I honestly think that Alex simply misunderstood you. That's not uncommon in these kind of lists. Better to not attribute to malice what can be explained by miscommunication. Even in the very rare occasion that it _is_ malice, you are better off assuming the best of people. - Rick Ive been using Perl for 20 years now. I grok perl. Good run with the insults and rudeness. Because yeah, thats a great way to treat someone whos pointing out a way to improve the usability of something. Treat them like dirt, and talk down to them like theyve never used Perl before. Ill stop offering advice on ways to improve the UI. Unintelligible and prone to confusion on the part of people isnt my problem. Im not going to be helpful if I get treated like shit when Im trying to make someones profit-making production better and more likely to be used. I forgot why I dropped this list. Thanks for reminding me. On Dec 9, 2014, at 5:10 AM, Alex Peters a...@peters.net wrote: I feel that there are actually several issues to discuss in this thread: Perl modules vs. Perl module distributions Perl module distribution sources Perl module distribution installation knowledge assumed by the CPAN site knowledge assumed by RT's documentation what documentation should actually change Based on your description of the steps you performed in an attempt to install a Perl module from CPAN, with all due respect, I believe you've been improperly advised on Perl module installation and possibly haven't been made aware of some crucial things about how Perl's modules work. I'll go over some of those things, then with everything in mind, maybe we can agree on what documentation changes are needed where. Perl modules vs. Perl module distributions A Perl module is (for all intents and purposes of this thread) a single .pm file. A Perl module distribution consists of a number of Perl modules (which can be just one), a Makefile (or more commonly, a Makefile generator in Makefile.PL), and instructions for installation of the distribution and hence its modules (usually in README or INSTALL). Distributions exist because often, a single module isn't enough to provide some meaningful form of functionality. Modules are never installed directly. Modules are always made available as a side effect installing module distributions. The distribution (not the module) is the smallest unit involved in the action of installation. Installation of a distribution might result in the installation of only one module, but nonetheless, it's the distribution that's acted upon directly for installation rather than the module. In summary, direct installation of single modules doesn't happen. Perl module distribution sources Distributions are typically (but not always) available on the CPAN site (typically capitalised as CPAN), and can be downloaded as an archive. Other distribution sources include (but are not limited to) GitHub, Bitbucket, CD-ROMs, FTP sites and personal web pages. In summary, distribution files can come from many different places. Perl module distribution installation Every distribution includes installation instructions in README or INSTALL, and the most typical experience for installing a Perl module distribution (after obtaining an archive of it) goes like this: $ tar xzf My-Perl-Module-0.01.tar.gz $ cd My-Perl-Module-0.01 $ perl Makefile.PL $ make $ make test $ make install Distributions on CPAN can be installed without first downloading an archive, using the CPAN installation tool (typically capitalised as cpan). cpan is actually smart enough to take a module name (rather than a distribution name) on the command line, determine the distribution to which that module belongs, and install that distribution. Since one distribution generally depends on others (prerequisites) being installed in advance, cpan also manages the installation of prerequisite distributions. This makes the use of a tool like cpan the generally preferred means of installing distributions (and by extension, modules). Other similar tools exist which do the job in a more streamlined fashion. I personally prefer cpanm. In summary, distribution installation tools function on distributions, not modulesalthough some tools have the ability to infer the right distribution if given a module name. Knowledge assumed by the CPAN site Given that a CPAN module page only offers a single Download link, and that link points to an archive of the module's distribution, it's safe to say that the CPAN site assumes that its users already know the distinction between modules and distributions, and expects that the user then refer to the documentation found within the downloaded archive. I suppose the reasoning is that anyone who knows about CPAN already knows about Perl modules, and how to install module distributions. I don't feel that the installation of Perl modules/distributions is
Re: [rt-users] RT-Extension-AceEditor
Hi Remi, nice work, love this, but the Custom Action Prep Code and Custom Condition are changed in the display order?!? [cid:image001.png@01D01519.BE459020] Torsten Von: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] Im Auftrag von Rémi Gesendet: Mittwoch, 10. Dezember 2014 18:23 An: rt Users Betreff: [rt-users] RT-Extension-AceEditor Hi list, Here is an extension that replace the default scrip edition textarea with the embeded Ace editor (http://ace.c9.io) https://github.com/valmiRe/rt-extension-aceeditor Rémi Kühne + Nagel (AG Co.) KG Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878. Geschäftsleitung Kühne + Nagel (AG Co.) KG: Reiner Heiken (Vors.), Dirk Blesius, Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Christian Marnetté, Christian Solf, Jens Wollesen. Persönlich haftende Gesellschafterin: Kühne Nagel A.G., Rechtsform: Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt. Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Hans-Georg Brinkmann (Stellv.), Richard Huhn, Björn Johansson, Bruno Mang, Stefan Paul, Tim Scharwath, Dominic Edmonds, Peder Winther. Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen Spediteursbedingungen (ADSp), jeweils neuester Fassung. Wir verweisen insbesondere auf die vom Gesetz abweichenden Haftungsbeschränkungen von Ziffer 23 und 24 ADSp. Den vollständigen Text der ADSp übersenden wir Ihnen gerne auf Anfrage und können Sie auch unter http://www.kuehne-nagel.com einsehen. Ergänzend wird vereinbart, dass (1) Ziffer 27 ADSp im Rahmen internationaler Übereinkommen weder unsere Haftung noch die Zurechnung des Verschuldens von Leuten und sonstigen Dritten zu Gunsten des Auftraggebers erweitert, und (2) wir in den im deutschen Seehandelsrecht aufgeführten Fällen des nautischen Verschuldens oder Feuer an Bord nur für eigenes Verschulden und (3) im Sinne der CMNI genannten Voraussetzungen nicht für nautisches Verschulden, Feuer an Bord oder Mängel des Schiffes haften.
Re: [rt-users] plugins link to module file, not package file
No problem. Sorry to see you go. On Thu, 11 Dec 2014 12:49 pm Jo Rhett jrh...@netconsonance.com wrote: I’ve been using Perl for 20 years now. I grok perl. Good run with the insults and rudeness. Because yeah, that’s a great way to treat someone who’s pointing out a way to improve the usability of something. Treat them like dirt, and talk down to them like they’ve never used Perl before. I’ll stop offering advice on ways to improve the UI. Unintelligible and prone to confusion on the part of people isn’t my problem. I’m not going to be helpful if I get treated like shit when I’m trying to make someone’s profit-making production better and more likely to be used. I forgot why I dropped this list. Thanks for reminding me. On Dec 9, 2014, at 5:10 AM, Alex Peters a...@peters.net wrote: I feel that there are actually several issues to discuss in this thread: 1. Perl modules vs. Perl module distributions 2. Perl module distribution sources 3. Perl module distribution installation 4. knowledge assumed by the CPAN site 5. knowledge assumed by RT's documentation 6. what documentation should actually change Based on your description of the steps you performed in an attempt to install a Perl module from CPAN, with all due respect, I believe you've been improperly advised on Perl module installation and possibly haven't been made aware of some crucial things about how Perl's modules work. I'll go over some of those things, then with everything in mind, maybe we can agree on what documentation changes are needed where. *Perl modules vs. Perl module distributions* A Perl *module* is (for all intents and purposes of this thread) a single .pm file. A Perl module *distribution* consists of a number of Perl modules (which can be just one), a Makefile (or more commonly, a Makefile generator in Makefile.PL), and instructions for installation of the distribution and hence its modules (usually in README or INSTALL). Distributions exist because often, a single module isn't enough to provide some meaningful form of functionality. Modules are never installed directly. Modules are always made available as a side effect installing module distributions. The distribution (not the module) is the smallest unit involved in the action of installation. Installation of a distribution might result in the installation of only one module, but nonetheless, it's the distribution that's acted upon directly for installation rather than the module. In summary, direct installation of single modules doesn't happen. *Perl module distribution sources* Distributions are typically (but not always) available on the CPAN site (typically capitalised as CPAN), and can be downloaded as an *archive*. Other distribution sources include (but are not limited to) GitHub, Bitbucket, CD-ROMs, FTP sites and personal web pages. In summary, distribution files can come from many different places. *Perl module distribution installation* Every distribution includes installation instructions in README or INSTALL, and the most typical experience for installing a Perl module distribution (after obtaining an archive of it) goes like this: $ tar xzf My-Perl-Module-0.01.tar.gz $ cd My-Perl-Module-0.01 $ perl Makefile.PL $ make $ make test $ make install Distributions on CPAN can be installed without first downloading an archive, using the CPAN installation tool (typically capitalised as cpan). cpan is actually smart enough to take a module name (rather than a distribution name) on the command line, determine the distribution to which that module belongs, and install that distribution. Since one distribution generally depends on others (prerequisites) being installed in advance, cpan also manages the installation of prerequisite distributions. This makes the use of a tool like cpan the generally preferred means of installing distributions (and by extension, modules). Other similar tools exist which do the job in a more streamlined fashion. I personally prefer cpanm https://metacpan.org/pod/distribution/App-cpanminus/bin/cpanm. In summary, distribution installation tools function on distributions, not modules—although some tools have the ability to infer the right distribution if given a module name. *Knowledge assumed by the CPAN site* Given that a CPAN module page http://search.cpan.org/dist/RT-Extension-MandatorySubject/lib/RT/Extension/MandatorySubject.pm only offers a single Download link, and that link points to an archive of the module's distribution, it's safe to say that the CPAN site assumes that its users already know the distinction between modules and distributions, and expects that the user then refer to the documentation found within the downloaded archive. I suppose the reasoning is that anyone who knows about CPAN already knows about Perl modules, and how to install module distributions. I don't feel that the installation of
