[rt-users] Missing dependencies in RT3.8.1?
I've just done a fresh install of 3.8.1 and found the graphing functions didn't work. make testdeps of our old version, 3.6.6 indicated various GD packages were necessary but 3.8.1 does not do this. Manually installing the GD packages indicated by 3.6.6 fixed the graphs. Paul Goffin___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Charset issues after upgrade to 3.8.1
Hi, you must add/change this lines in your my.cnf: [client] default-character-set = utf8 [mysqld] default-character-set=utf8 character_set_server=utf8 collation_server=utf8_general_ci init_connect='SET collation_connection = utf8_general_ci' init_connect='SET CHARACTER_SET utf8' init_connect='SET NAMES utf8' [mysql] default-character-set=utf8 Stop/start you mysqld and you have: mysql show variables like 'c%'; +--++ | Variable_name| Value | +--++ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results| utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | | collation_connection | utf8_general_ci| | collation_database | utf8_general_ci| | collation_server | utf8_general_ci| | completion_type | 0 | | concurrent_insert| 1 | | connect_timeout | 10 | +--++ 14 rows in set (0.00 sec) After these modifications all works well. -- Gian Luca Gobbi From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of BALINT Bekeny Sent: Wednesday, September 03, 2008 11:07 AM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Charset issues after upgrade to 3.8.1 Hi, I reported the same problem here (but nobody answered): http://lists.bestpractical.com/pipermail/rt-users/2008-August/053512.html I think there is a lack in the mysql upgrade document or in the upgrade script. I did it on a test environment and didn't have time to find out the real solution, so I delayed the migration of the real system. Some more information: - After migration, new entries (for example CF-s) seemed good, even if they have non-ascii characters. - In mysql CLI: show variables like 'c%' shows that everything is utf8 (so this seems good) Any suggestion? Thanks, -- Bekény On Tue, Sep 2, 2008 at 5:28 PM, Emmanuel Lacour [EMAIL PROTECTED] wrote: On Tue, Sep 02, 2008 at 08:14:55AM -0700, F350 wrote: Thanks a lot for your help and time Emmanuel. I updated all the tickets, CF and templates that look corrupted. Next time i'll make sure I do the updates on a test server :) You're welcome :) Using a test server or a test db/rt instance is a must have ;) ___ ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Missing dependencies in RT3.8.1?
Hi Paul, From memory on my CentOS machine I had to make sure that I had following: rpm -qa|grep graphviz graphviz-devel-2.20.2-1.el5 graphviz-perl-2.20.2-1.el5 graphviz-2.20.2-1.el5 I then configured RT with: --enable-graphviz Turns on support for RT's GraphViz dependency charts --enable-gd Turns on support for RT's GD pie and bar charts Under links section I then got a graph button/link. Regards, Jason On 4 Sep 2008, at 07:29, Paul Goffin wrote: I've just done a fresh install of 3.8.1 and found the graphing functions didn't work. make testdeps of our old version, 3.6.6 indicated various GD packages were necessary but 3.8.1 does not do this. Manually installing the GD packages indicated by 3.6.6 fixed the graphs. Paul Goffin___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] urgent: Connect Failed received invalid response to SSL negotiation
Please help me, I am not a perl nor Pg expert. After a restart, request-tracker 3.6.1 on Debian etch stopped working. The complete error message is this: Connect Failed received invalid response to SSL negotiation: F\n\n at /usr/share/request-tracker3.6/lib/RT.pm line 176\n I have tried to figure out where to switch off SSL off but could not find it. How can I get this working again? Thanks for your valued assistance. H. Kaya ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] urgent: Connect Failed received invalid response to SSL negotiation
On Thu, Sep 04, 2008 at 12:20:00PM +0200, Hakan Kaya wrote: Please help me, I am not a perl nor Pg expert. After a restart, request-tracker 3.6.1 on Debian etch stopped working. The complete error message is this: Connect Failed received invalid response to SSL negotiation: F\n\n at /usr/share/request-tracker3.6/lib/RT.pm line 176\n I have tried to figure out where to switch off SSL off but could not find it. How can I get this working again? There is a variable in RT config file: DatabaseRequireSSL, you can try to disable it (set to 0 or undef) if your databse isn't configured for SSL connections. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Charset issues after upgrade to 3.8.1
Are u sure it is the way to do ? In the Upgrading.mysql help file, they say that the default charset should not be utf-8. In my database, all my tables are set as utf-8 but the default charset of the database is latin1. Gian Luca Gobbi wrote: Hi, you must add/change this lines in your my.cnf: [client] default-character-set = utf8 [mysqld] default-character-set=utf8 character_set_server=utf8 collation_server=utf8_general_ci init_connect='SET collation_connection = utf8_general_ci' init_connect='SET CHARACTER_SET utf8' init_connect='SET NAMES utf8' [mysql] default-character-set=utf8 Stop/start you mysqld and you have: mysql show variables like 'c%'; +--++ | Variable_name| Value | +--++ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results| utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | | collation_connection | utf8_general_ci| | collation_database | utf8_general_ci| | collation_server | utf8_general_ci| | completion_type | 0 | | concurrent_insert| 1 | | connect_timeout | 10 | +--++ 14 rows in set (0.00 sec) After these modifications all works well. -- Gian Luca Gobbi From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of BALINT Bekeny Sent: Wednesday, September 03, 2008 11:07 AM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Charset issues after upgrade to 3.8.1 Hi, I reported the same problem here (but nobody answered): http://lists.bestpractical.com/pipermail/rt-users/2008-August/053512.html I think there is a lack in the mysql upgrade document or in the upgrade script. I did it on a test environment and didn't have time to find out the real solution, so I delayed the migration of the real system. Some more information: - After migration, new entries (for example CF-s) seemed good, even if they have non-ascii characters. - In mysql CLI: show variables like 'c%' shows that everything is utf8 (so this seems good) Any suggestion? Thanks, -- Bekény On Tue, Sep 2, 2008 at 5:28 PM, Emmanuel Lacour [EMAIL PROTECTED] wrote: On Tue, Sep 02, 2008 at 08:14:55AM -0700, F350 wrote: Thanks a lot for your help and time Emmanuel. I updated all the tickets, CF and templates that look corrupted. Next time i'll make sure I do the updates on a test server :) You're welcome :) Using a test server or a test db/rt instance is a must have ;) ___ ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- View this message in context: http://www.nabble.com/Charset-issues-after-upgrade-to-3.8.1-tp19267620p19308775.html Sent from the Request Tracker - User mailing list archive at Nabble.com. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Charset issues after upgrade to 3.8.1
Here is a sample of my custom fields table schema: CREATE TABLE `CustomFields` ( `id` int(11) NOT NULL auto_increment, `Name` varchar(200) default NULL, `Type` varchar(200) character set ascii default NULL, `MaxValues` int(11) default NULL, `Pattern` text, `Repeated` smallint(6) NOT NULL default '0', `Description` varchar(255) default NULL, `SortOrder` int(11) NOT NULL default '0', `LookupType` varchar(255) character set ascii NOT NULL, `Creator` int(11) NOT NULL default '0', `Created` datetime default NULL, `LastUpdatedBy` int(11) NOT NULL default '0', `LastUpdated` datetime default NULL, `Disabled` smallint(6) NOT NULL default '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; Can someone tell me if the schema is correct ? When comparing the old database version (3.8.0) and the new one (3.8.1) I found no differences in the schema even after applying the script. Thanks F350 wrote: Are u sure it is the way to do ? In the Upgrading.mysql help file, they say that the default charset should not be utf-8. In my database, all my tables are set as utf-8 but the default charset of the database is latin1. Gian Luca Gobbi wrote: Hi, you must add/change this lines in your my.cnf: [client] default-character-set = utf8 [mysqld] default-character-set=utf8 character_set_server=utf8 collation_server=utf8_general_ci init_connect='SET collation_connection = utf8_general_ci' init_connect='SET CHARACTER_SET utf8' init_connect='SET NAMES utf8' [mysql] default-character-set=utf8 Stop/start you mysqld and you have: mysql show variables like 'c%'; +--++ | Variable_name| Value | +--++ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results| utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | | collation_connection | utf8_general_ci| | collation_database | utf8_general_ci| | collation_server | utf8_general_ci| | completion_type | 0 | | concurrent_insert| 1 | | connect_timeout | 10 | +--++ 14 rows in set (0.00 sec) After these modifications all works well. -- Gian Luca Gobbi From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of BALINT Bekeny Sent: Wednesday, September 03, 2008 11:07 AM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Charset issues after upgrade to 3.8.1 Hi, I reported the same problem here (but nobody answered): http://lists.bestpractical.com/pipermail/rt-users/2008-August/053512.html I think there is a lack in the mysql upgrade document or in the upgrade script. I did it on a test environment and didn't have time to find out the real solution, so I delayed the migration of the real system. Some more information: - After migration, new entries (for example CF-s) seemed good, even if they have non-ascii characters. - In mysql CLI: show variables like 'c%' shows that everything is utf8 (so this seems good) Any suggestion? Thanks, -- Bekény On Tue, Sep 2, 2008 at 5:28 PM, Emmanuel Lacour [EMAIL PROTECTED] wrote: On Tue, Sep 02, 2008 at 08:14:55AM -0700, F350 wrote: Thanks a lot for your help and time Emmanuel. I updated all the tickets, CF and templates that look corrupted. Next time i'll make sure I do the updates on a test server :) You're welcome :) Using a test server or a test db/rt instance is a must have ;) ___ ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- View this message in context: http://www.nabble.com/Charset-issues-after-upgrade-to-3.8.1-tp19267620p19308784.html Sent from the Request Tracker - User mailing list archive at Nabble.com. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's
[rt-users] GPG inbound decrypt/verify problems in RT 3.8.1
Greetings all! I've been running into a very strange decrypt/verify problem with inbound GPG mail in RT 3.8.1. The problem seems to be the same with both PGP/MIME and inline PGP, though I've been mostly testing with inline PGP. RT gets the inbound message, and all of the GPG infrastructure appears to be set up correctly, but encrypted messages get NODATA 1 and NODATA 2 back from GPG, and signed-only messages get BADSIG back. However, when I look in /tmp, I can see the temp files that RT creates with the appropriate body parts (based on their contents and the timestamps), and when I pass them through command-line gpg, using the same homedir and other options that I pass in my RT config, it can decrypt/verify them just fine! As far as I can tell from some testing, it seems that something wonky is happening with the file handles that are getting passed around - I just can't figure out what! If I strip out even one character from those temp files I found, and run them through command-line gpg, I get the same results that RT gets. I have verified that GPG encryption works outbound - I can send an encrypted message from the queue, and it is encrypted with the appropriate keys. RT is 3.8.1, GnuPG::Interface is 0.36, gpg is 1.2.6 (working on getting that upgraded, though it doesn't seem a likely culprit), Apache is 2.2.9, mod_perl is 2.0. GnuPG options in RT_SiteConfig.pm: Set( %GnuPG, Enable=1, OutgoingMessagesFormat='RFC', AllowEncryptDataInDB=0, ); Set( %GnuPGOptions, 'passphrase'='mypassphrasehere', 'no-permission-warning'=undef, 'homedir'='var/data/gpg', ); Set(@MailPlugins, 'Auth::MailFrom', 'Auth::GnuPG', ); My GPG keyrings are in var/data/gpg relative to the RT root, and all my command-line testing of temp files has used those same keyrings for consistency. Debug log entries from encrypted inbound message: [Thu Sep 4 14:35:03 2008] [debug]: Found encrypted inline part (/usr/local/rt-3.8.1/bin/../local/lib/RT/Crypt/GnuPG.pm:883) [Thu Sep 4 14:35:03 2008] [debug]: [GNUPG:] NODATA 1 [GNUPG:] NODATA 2 (/usr/local/rt-3.8.1/bin/../local/lib/RT/Crypt/GnuPG.pm:1313) [Thu Sep 4 14:35:03 2008] [error]: gpg: no valid OpenPGP data found. gpg: decrypt_message failed: eof (/usr/local/rt-3.8.1/bin/../local/lib/RT/Crypt/GnuPG.pm:1315) [Thu Sep 4 14:35:03 2008] [debug]: Found GnuPG protected parts (/usr/local/rt-3.8.1/bin/../lib/RT/Interface/Email/Auth/GnuPG.pm:234) [Thu Sep 4 14:35:03 2008] [debug]: Error during verify/decrypt operation (/usr/local/rt-3.8.1/bin/../lib/RT/Interface/Email/Auth/GnuPG.pm:238) [Thu Sep 4 14:35:03 2008] [error]: Had a problem during decrypting and verifying (/usr/local/rt-3.8.1/bin/../lib/RT/Interface/Email/Auth/GnuPG.pm:97) [Thu Sep 4 14:35:03 2008] [error]: Couldn't process a message: No data has been found. The reason is 'No armored data', No data has been found. The reason is 'Expected a packet, but did not found one' (/usr/local/rt-3.8.1/bin/../lib/RT/Interface/Email/Auth/GnuPG.pm:204) [Thu Sep 4 14:35:04 2008] [debug]: Converting 'ISO-8859-1' to 'utf-8' for text/plain - encrypted test (/usr/local/rt-3.8.1/bin/../lib/RT/I18N.pm:231) Same debug log section from signed inbound message: [Thu Sep 4 14:35:37 2008] [debug]: Found signed inline part (/usr/local/rt-3.8.1/bin/../local/lib/RT/Crypt/GnuPG.pm:883) [Thu Sep 4 14:35:37 2008] [debug]: [GNUPG:] BADSIG 96E45B46redacted Tim Wilde [EMAIL PROTECTED] (/usr/local/rt-3.8.1/bin/../local/lib/RT/Crypt/GnuPG.pm:1313) [Thu Sep 4 14:35:37 2008] [error]: gpg: Signature made Thu Sep 4 14:35:35 2008 GMT using DSA key ID redacted gpg: BAD signature from Tim Wilde [EMAIL PROTECTED] (/usr/local/rt-3.8.1/bin/../local/lib/RT/Crypt/GnuPG.pm:1315) [Thu Sep 4 14:35:37 2008] [debug]: Found GnuPG protected parts (/usr/local/rt-3.8.1/bin/../lib/RT/Interface/Email/Auth/GnuPG.pm:234) [Thu Sep 4 14:35:37 2008] [debug]: Error during verify/decrypt operation (/usr/local/rt-3.8.1/bin/../lib/RT/Interface/Email/Auth/GnuPG.pm:238) [Thu Sep 4 14:35:37 2008] [error]: Had a problem during decrypting and verifying (/usr/local/rt-3.8.1/bin/../lib/RT/Interface/Email/Auth/GnuPG.pm:97) [Thu Sep 4 14:35:37 2008] [debug]: Converting 'ISO-8859-1' to 'utf-8' for text/plain - Subjectless message (/usr/local/rt-3.8.1/bin/../lib/RT/I18N.pm:231) Note that the second message did have a subject, signed test, I don't know if the fact that RT thinks it was subjectless is relevant or not. Is it possible that all of this has something to do with specifying the passphrase in the config (verified multiple times to be the correct passphrase for the secret key for the queue, by the way) rather than using the agent? Based on the other threads here in the archives, I hope this is all the information needed to take a peek at this. Again, for both of the specific messages for which I pasted debug entries here, I have files in /tmp with the exact body content, which, when passed in to command-line gpg, work just fine. I'm at my wit's end, to be
[rt-users] automatic take
Suppose there is a new unassigned ticket. Suppose I reply to the ticket via email. Is there some way for my RT account to automatically take the ticket? If so, how? If this is a bad idea, why? ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] automatic take
On 4 Sep 2008, at 4:05 pm, Joshua N Pritikin wrote:
Suppose there is a new unassigned ticket. Suppose I reply to the
ticket
via email. Is there some way for my RT account to automatically take
the
ticket? If so, how?
We have this set up.
You need to add a Scrip to do it. We have a Global scrip called
AutoTakeOnCorrespond, which has the following custom action. You'll
notice there are some parts of it (particularly the line about the
syshelp queue) which are specific to our site, so you will want to
change parts of it.
my $correspondent = $self-TransactionObj-Creator;
# don't auto-take for root
return 1 if $correspondent == $RT::SystemUser-id;
# only auto-take if owned by Nobody
return 1 unless $self-TicketObj-Owner == $RT::Nobody-id;
# don't auto-take tickets in syshelp
return 1 if $self-TicketObj-QueueObj-Name eq 'syshelp';
# don't auto-take if correspondent is requestor
# see http://wiki.bestpractical.com/index.cgi?OnCreateSetDeptHeadCc
my $rgobj = $self-TicketObj-Requestors;
my $rmobj = $rgobj-UserMembersObj;
my $uobj;
while ($uobj = $rmobj-Next) {
if ($uobj-PrincipalObj-Id == $correspondent) {
$RT::Logger-info(Not auto-assigning ticket # . $self-
TicketObj-id . to its requestor);
return 1;
}
}
$RT::Logger-info(Auto assign ticket #. $self-TicketObj-id . to
user #. $correspondent );
my ($status, $msg) = $self-TicketObj-SetOwner( $correspondent );
unless( $status ) {
$RT::Logger-error( Impossible to assign ticket to $correspondent:
$msg );
return undef;
}
return 1;
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Separate permission
Kevin, My situation is that these queues are completely seperate support groups and very seldom do they work on the same issue. This is for those tickets where one support group needs another group to complete their work in order for the first group to complete theirs. The DependsOn link is perfect, but to do that, I have to allow the ModifyTicket right for group1 to a queue they normally do not touch. Not very secure. But thanks. Kenn LBNL On 8/29/2008 4:46 PM, Kevin Falcone wrote: On Aug 29, 2008, at 4:55 PM, Kenneth Crocker wrote: I'm not using 3.8 yet, but I was hoping that perhaps the permissions had been modified a bit to allow a user from one queue to link his ticket to a ticket in another queue without having to have the ModifyTicket privilege. I have many queues that could have their tickets linked to tickets in other queues, but don't want the support personnel of those other queues to be able to modify tickets in their own. Does that make any sense? I can't tell if you don't want to hand out ModifyTicket to these users at all or if you're ok letting them have ModifyTicket in their own queue. If the latter, StrictLinkACL in your config may help. If the former, there is some rather tangled code that would need untangling to do what you want. -kevin ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] canned replies with attachment
Hi Is it possible to have attachments directly attached to a template. So if I choose this template as canned reply the attachment will be attached as well? Thanks Ruben Monzoon Networks AG Ruben Lehmann -- Nomadic Workers - hotspot.monzoon.net Wireless Internet - home.monzoon.net Surf the safer way - www.swissvpn.net -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] canned replies with attachment
On Thu, Sep 4, 2008 at 11:46, Ruben Lehmann [EMAIL PROTECTED] wrote: Hi Is it possible to have attachments directly attached to a template. So if I choose this template as canned reply the attachment will be attached as well? I would suggest that the proper way to handle this is to provide a URI to the documents instead. -- Cambridge Energy Alliance: Save money the planet ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] RT upgrade from 3.6.2 - 3.8.1 - No longer seems to be looking at the Requestor Permisions
Hello, We have had a couple queues that have been setup and working fine for a while now, however after the upgrade to 3.8.1 we have ran into an issue. Anyone can open a ticket in the queue via email, however once they have opened the ticket they cannot reply to the ticket. The permissions on the queue are setup as follows: System Groups: Unprivileged: none Privileged: none Everyone: Create Ticket Roles: Requestor: ReplyToTicket, ShowTicket Owner: AssignCustomFields, CommentOnTicket, ModifyACL, ModifyQueueWatchers, ModifyTicket, ReplyToTicket, SeeQueue, ShowACL, ShowOutgoingEmail, ShowScrips, ShowTemplate, ShowTicket, ShowTicketComments, Watch, WatchAsAdminCc AdminCC: has the same permissions as Owner Then we have our own User Defined Groups however that shouldn't play a role in this as the user that created the ticket is unprivileged. If I modified the Everyone Permissions to include ReplyToTicket then the user that created the ticket can reply to the ticket without issue. Under the People portion of the Ticket information it does correctly list the user that created the ticket as the Requestor. The email that is given back to the user is the following: Message not recorded: RE: [Data393 #4554] Testing, permission denied. From the rt.log: [Wed Sep 3 21:51:52 2008] [crit]: Permission Denied (/opt/rt3/bin/../lib/RT/Interface/Email.pm:244) [Wed Sep 3 21:51:52 2008] [error]: Could not record email: Message not recorded: Permission Denied (/opt/rt3/share/html/REST/1.0/No Auth/mail-gateway:75) One other thing I am getting a bunch of errors in the log file: [Thu Sep 4 13:28:32 2008] [warning]: RT::Handle=HASH(0xbae51be0) couldn't execute the query 'SELECT ACL.id FROM ACL, Groups, Princi pals, CachedGroupMembers WHERE (ACL.RightName = 'SuperUser' OR ACL.RightName = 'CreateTicket') AND Principals.Disabled = 0 AND Cache dGroupMembers.Disabled = 0 AND Principals.id = Groups.id AND Principals.PrincipalType = 'Group' AND Principals.id = CachedGroupMembe rs.GroupId AND CachedGroupMembers.MemberId = 5000 AND ACL.PrincipalType = Groups.Type AND ((ACL.ObjectType = 'RT::System' AND ACL.O bjectId = 1) OR (ACL.ObjectType = 'RT::Queue' AND ACL.ObjectId = 6)) AND Groups.Domain = 'RT::System-Role' AND Groups.Instance = '1' LIMIT 1' at /usr/lib/perl5/site_perl/5.8.8/DBIx/SearchBuilder/Handle.pm line 518 Which as I understand means I need to run the mysql schema script. The output of that script is as follows: Use of uninitialized value in numeric gt () at schema.mysql-4.0-4.1.pl line 311. Use of uninitialized value in numeric gt () at schema.mysql-4.0-4.1.pl line 311. Use of uninitialized value in numeric gt () at schema.mysql-4.0-4.1.pl line 311. Use of uninitialized value in numeric gt () at schema.mysql-4.0-4.1.pl line 311. Use of uninitialized value in numeric gt () at schema.mysql-4.0-4.1.pl line 311. Use of uninitialized value in numeric gt () at schema.mysql-4.0-4.1.pl line 311. Use of uninitialized value in numeric gt () at schema.mysql-4.0-4.1.pl line 311. Use of uninitialized value in numeric gt () at schema.mysql-4.0-4.1.pl line 311. Use of uninitialized value in numeric gt () at schema.mysql-4.0-4.1.pl line 311. ALTER DATABASE rt DEFAULT CHARACTER SET utf8; ALTER TABLE ACL DEFAULT CHARACTER SET utf8; ALTER TABLE Attachments DEFAULT CHARACTER SET utf8; ALTER TABLE Attachments MODIFY Content CHAR NULL DEFAULT NULL; ALTER TABLE Attributes DEFAULT CHARACTER SET utf8; ALTER TABLE Attributes MODIFY Content CHAR NULL DEFAULT NULL; ALTER TABLE CustomFields DEFAULT CHARACTER SET utf8; ALTER TABLE CustomFieldValues DEFAULT CHARACTER SET utf8; ALTER TABLE GroupMembers DEFAULT CHARACTER SET utf8; ALTER TABLE Groups DEFAULT CHARACTER SET utf8; ALTER TABLE Links DEFAULT CHARACTER SET utf8; ALTER TABLE ObjectCustomFields DEFAULT CHARACTER SET utf8; ALTER TABLE ObjectCustomFieldValues DEFAULT CHARACTER SET utf8; ALTER TABLE ObjectCustomFieldValues MODIFY LargeContent CHAR NULL DEFAULT NULL; ALTER TABLE Principals DEFAULT CHARACTER SET utf8; ALTER TABLE Queues DEFAULT CHARACTER SET utf8; ALTER TABLE ScripActions DEFAULT CHARACTER SET utf8; ALTER TABLE ScripActions MODIFY Argument CHAR NULL DEFAULT NULL; ALTER TABLE ScripConditions DEFAULT CHARACTER SET utf8; ALTER TABLE ScripConditions MODIFY Argument CHAR NULL DEFAULT NULL; ALTER TABLE Scrips DEFAULT CHARACTER SET utf8; ALTER TABLE sessions DEFAULT CHARACTER SET utf8; ALTER TABLE sessions MODIFY id CHAR NOT NULL DEFAULT ''; ALTER TABLE sessions MODIFY a_session CHAR NULL DEFAULT NULL; ALTER TABLE Templates DEFAULT CHARACTER SET utf8; ALTER TABLE Tickets DEFAULT CHARACTER SET utf8; ALTER TABLE Transactions DEFAULT CHARACTER SET utf8; ALTER TABLE Users DEFAULT CHARACTER SET utf8; ALTER TABLE Users MODIFY PGPKey CHAR NULL DEFAULT NULL; ALTER TABLE Users MODIFY Password CHAR NULL DEFAULT NULL; If I run the script against the MYSQL database I get the following mysql
[rt-users] Extension CommandByMail
Hi all, I'm using RT 3.6.6 and I'd like to use the extension CommandByMail. Well, I downloaded the source and follow the instrunctions to install, but I didn't understand in what file and in what part of that file I have to put the CommandByMail configuration. Any help? Regards, Reginaldo Russinholi Developer/Sys.Adm. IRapida Telecom ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] [patch] GPG inbound decrypt/verify problems in RT 3.8.1
Tim Wilde wrote:
[ snip ]
Is it possible that all of this has something to do with specifying the
passphrase in the config (verified multiple times to be the correct
passphrase for the secret key for the queue, by the way) rather than
using the agent?
[ snip ]
Greetings again all!
Ding ding ding ding, we have a winner! After far too many hours of
digging, I found something that didn't look quite right to me, changed
it, and viola, problem solved.
The attached patch to lib/RT/Crypt/GnuPG.pm should make operation with a
passphrase specified in RT_SiteConfig.pm actually work - without it, I
don't think it can work, at least not with gpg 1.2.6. The passphrase
needs to be deleted out of %opt before it's passed to
_PrepareGnuPGOptions, otherwise it gets very very grumpy in ways that
don't even come close to immediately pointing back to the real cause.
I note there was an additional section of code dealing with
$args{'Passphrase'} right after the one I moved - I didn't move that to
the new location, since it doesn't seem to much matter which place it
exists. I assume the intent of GetPassphrase() is to allow for
subclassing and/or local versions of the module to do more than return
'test' all the time? Otherwise, that code probably doesn't need to be
there at all. :) This should probably be mentioned in the documentation.
Finally, the area of this module that this patch modifies could use some
additional attention/cleanup - almost identical code, with very few
variations, occurs 8 times in the same source file, as far as I can
tell. It shouldn't be too difficult to factor the options handling out
and make maintenance considerably easier.
Best Practical folks, please review and apply this patch (or an
appropriate variation thereof) to the next release so that others don't
have to dig through these problems for as many hours as we did! Please
feel free to contact me if you have any further questions about it.
Thanks,
Tim Wilde
--- lib/RT/Crypt/GnuPG.pm 2008-08-29 15:50:00.0 +
+++ local/lib/RT/Crypt/GnuPG.pm 2008-09-04 19:45:39.0 +
@@ -435,6 +435,11 @@
my $gnupg = new GnuPG::Interface;
my %opt = RT-Config-Get('GnuPGOptions');
+
+# handling passphrase in GnuPGOptions
+$args{'Passphrase'} = delete $opt{'passphrase'}
+if !defined $args{'Passphrase'};
+
$opt{'digest-algo'} ||= 'SHA1';
$opt{'default_key'} = $args{'Signer'}
if $args{'Sign'} $args{'Signer'};
@@ -446,10 +451,6 @@
my $entity = $args{'Entity'};
-# handling passphrase in GnuPGOptions
-$args{'Passphrase'} = delete $opt{'passphrase'}
-if !defined $args{'Passphrase'};
-
if ( $args{'Sign'} !defined $args{'Passphrase'} ) {
$args{'Passphrase'} = GetPassphrase( Address = $args{'Signer'} );
}
@@ -610,6 +611,11 @@
my $gnupg = new GnuPG::Interface;
my %opt = RT-Config-Get('GnuPGOptions');
+
+# handling passphrase in GnupGOptions
+$args{'Passphrase'} = delete $opt{'passphrase'}
+if !defined($args{'Passphrase'});
+
$opt{'digest-algo'} ||= 'SHA1';
$opt{'default_key'} = $args{'Signer'}
if $args{'Sign'} $args{'Signer'};
@@ -619,10 +625,6 @@
meta_interactive = 0,
);
-# handling passphrase in GnupGOptions
-$args{'Passphrase'} = delete $opt{'passphrase'}
-if !defined($args{'Passphrase'});
-
if ( $args{'Sign'} !defined $args{'Passphrase'} ) {
$args{'Passphrase'} = GetPassphrase( Address = $args{'Signer'} );
}
@@ -694,6 +696,11 @@
my $gnupg = new GnuPG::Interface;
my %opt = RT-Config-Get('GnuPGOptions');
+
+# handling passphrase in GnupGOptions
+$args{'Passphrase'} = delete $opt{'passphrase'}
+if !defined($args{'Passphrase'});
+
$opt{'digest-algo'} ||= 'SHA1';
$opt{'default_key'} = $args{'Signer'}
if $args{'Sign'} $args{'Signer'};
@@ -703,10 +710,6 @@
meta_interactive = 0,
);
-# handling passphrase in GnupGOptions
-$args{'Passphrase'} = delete $opt{'passphrase'}
-if !defined($args{'Passphrase'});
-
if ( $args{'Sign'} !defined $args{'Passphrase'} ) {
$args{'Passphrase'} = GetPassphrase( Address = $args{'Signer'} );
}
@@ -792,6 +795,11 @@
my $gnupg = new GnuPG::Interface;
my %opt = RT-Config-Get('GnuPGOptions');
+
+# handling passphrase in GnupGOptions
+$args{'Passphrase'} = delete $opt{'passphrase'}
+if !defined($args{'Passphrase'});
+
$opt{'digest-algo'} ||= 'SHA1';
$opt{'default_key'} = $args{'Signer'}
if $args{'Sign'} $args{'Signer'};
@@ -801,10 +809,6 @@
meta_interactive = 0,
);
-# handling passphrase in GnupGOptions
-$args{'Passphrase'} = delete $opt{'passphrase'}
-if !defined($args{'Passphrase'});
-
if ( $args{'Sign'} !defined $args{'Passphrase'} ) {
$args{'Passphrase'} = GetPassphrase( Address = $args{'Signer'} );
}
@@ -1131,6 +1135,11 @@
Re: [rt-users] Extension CommandByMail
On Thu, Sep 04, 2008 at 01:59:06PM -0300, Reginaldo Russinholi wrote: Hi all, I'm using RT 3.6.6 and I'd like to use the extension CommandByMail. Well, I downloaded the source and follow the instrunctions to install, but I didn't understand in what file and in what part of that file I have to put the CommandByMail configuration. Any help? Hi Reginaldo, The config for CommandByMail goes in your RT_SiteConfig.pm file. If you're using the standard layout, it'll be in /opt/rt3/etc. Shawn ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Quick Search in 3.8.1 doesn't include Resolved Status
Hi everyone, A couple of my users noticed our newly upgraded version of RT (3.8.1) handles the quick searches differently from past versions (3.6.3). When they perform a Quick Search, it does not search on Resolved tickets anymore. The quick search was how we were able to quickly pull up historical resolved tickets. Is this something I can turn on globally somewhere? Cheers! Helmuth Ramirez ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status
On Thu, Sep 04, 2008 at 05:53:41PM -0400, Helmuth Ramirez wrote: Hi everyone, A couple of my users noticed our newly upgraded version of RT (3.8.1) handles the quick searches differently from past versions (3.6.3). When they perform a Quick Search, it does not search on Resolved tickets anymore. The quick search was how we were able to quickly pull up historical resolved tickets. Is this something I can turn on globally somewhere? I'd take a patch to make it configurable, but generally, we've found that more often than not, users want to search current tickets quickly. Limiting it to only open tickets makes the actual search much faster and less cluttered. Cheers! Helmuth Ramirez ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status
I'd love to say I'd write the patch, but sadly Perl (or any coding for that matter) is not my strong point. Not from a lack of trying though, I went out and bought a Perl book just to help me understand RT better :) Unfortunately I haven't used it yet :( Oh well, I'll tell them they'll have to use the standard Tickets section for their searches going forward. Thanks Jesse for the quick response. Helmuth -Original Message- From: Jesse Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2008 5:58 PM To: Helmuth Ramirez Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status On Thu, Sep 04, 2008 at 05:53:41PM -0400, Helmuth Ramirez wrote: Hi everyone, A couple of my users noticed our newly upgraded version of RT (3.8.1) handles the quick searches differently from past versions (3.6.3). When they perform a Quick Search, it does not search on Resolved tickets anymore. The quick search was how we were able to quickly pull up historical resolved tickets. Is this something I can turn on globally somewhere? I'd take a patch to make it configurable, but generally, we've found that more often than not, users want to search current tickets quickly. Limiting it to only open tickets makes the actual search much faster and less cluttered. Cheers! Helmuth Ramirez ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Editing Comments or Replies
I don't really see a business reason for comments/replies not to be editable, as long as a record of edits were kept. You can argue that the content of a reply or comment is data, not an audit trail entry. If RT has sent it out by email, it can't be taken back. Ticket replies or comments are a record of a conversation, rather than a notes field. It's perfectly reasonable to set up a big text custom field for recording a cleaned up version of the ticket's data, but that's a very separate thing than the log of all history. -j ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status
They can still search resolved by using a format like 'search term resolved' I have the same issue, in which we need to search resolved tickets as it makes it much easier to find someone since most of the people that call us don't have a clue what their email is (hard to believe I know) or have 10 different emails that they give us Greg Evans Hood Canal Communications (360) 898-2481 ext.212 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Helmuth Ramirez Sent: Thursday, September 04, 2008 3:03 PM To: Jesse Vincent Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status I'd love to say I'd write the patch, but sadly Perl (or any coding for that matter) is not my strong point. Not from a lack of trying though, I went out and bought a Perl book just to help me understand RT better :) Unfortunately I haven't used it yet :( Oh well, I'll tell them they'll have to use the standard Tickets section for their searches going forward. Thanks Jesse for the quick response. Helmuth -Original Message- From: Jesse Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2008 5:58 PM To: Helmuth Ramirez Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status On Thu, Sep 04, 2008 at 05:53:41PM -0400, Helmuth Ramirez wrote: Hi everyone, A couple of my users noticed our newly upgraded version of RT (3.8.1) handles the quick searches differently from past versions (3.6.3). When they perform a Quick Search, it does not search on Resolved tickets anymore. The quick search was how we were able to quickly pull up historical resolved tickets. Is this something I can turn on globally somewhere? I'd take a patch to make it configurable, but generally, we've found that more often than not, users want to search current tickets quickly. Limiting it to only open tickets makes the actual search much faster and less cluttered. Cheers! Helmuth Ramirez ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status
Thanks Greg for the tip. That does work :) And I completely understand where you're coming from. On our end when we're searching for a ticket, 99% of the time its to look for something that's already been done/resolved (end users calling for status, etc). Thanks Helmuth -Original Message- From: Greg Evans [mailto:[EMAIL PROTECTED] Sent: Thu 9/4/2008 6:42 PM To: Helmuth Ramirez; 'Jesse Vincent' Cc: rt-users@lists.bestpractical.com Subject: RE: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status They can still search resolved by using a format like 'search term resolved' I have the same issue, in which we need to search resolved tickets as it makes it much easier to find someone since most of the people that call us don't have a clue what their email is (hard to believe I know) or have 10 different emails that they give us Greg Evans Hood Canal Communications (360) 898-2481 ext.212 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Helmuth Ramirez Sent: Thursday, September 04, 2008 3:03 PM To: Jesse Vincent Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status I'd love to say I'd write the patch, but sadly Perl (or any coding for that matter) is not my strong point. Not from a lack of trying though, I went out and bought a Perl book just to help me understand RT better :) Unfortunately I haven't used it yet :( Oh well, I'll tell them they'll have to use the standard Tickets section for their searches going forward. Thanks Jesse for the quick response. Helmuth -Original Message- From: Jesse Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2008 5:58 PM To: Helmuth Ramirez Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status On Thu, Sep 04, 2008 at 05:53:41PM -0400, Helmuth Ramirez wrote: Hi everyone, A couple of my users noticed our newly upgraded version of RT (3.8.1) handles the quick searches differently from past versions (3.6.3). When they perform a Quick Search, it does not search on Resolved tickets anymore. The quick search was how we were able to quickly pull up historical resolved tickets. Is this something I can turn on globally somewhere? I'd take a patch to make it configurable, but generally, we've found that more often than not, users want to search current tickets quickly. Limiting it to only open tickets makes the actual search much faster and less cluttered. Cheers! Helmuth Ramirez ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status
We are the same, much prefer searching for all unresolved and resolved tickets in the quick search. The change has caused quite a bit of abuse at the sysadmin (me). Gordon Helmuth Ramirez wrote: On our end when we're searching for a ticket, 99% of the time its to look for something that's already been done/resolved (end users calling for status, etc). Thanks Helmuth ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status
On Sep 4, 2008, at 8:42 PM, [EMAIL PROTECTED] wrote: We are the same, much prefer searching for all unresolved and resolved tickets in the quick search. The change has caused quite a bit of abuse at the sysadmin (me). As I sad before, I'd love to take a patch :) Best, Jesse Gordon Helmuth Ramirez wrote: On our end when we're searching for a ticket, 99% of the time its to look for something that's already been done/resolved (end users calling for status, etc). Thanks Helmuth ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Quick Search in 3.8.1 doesn't include Resolved Status
Jessie, I guess it just depends on the size of the organization, how many queues they have, and how many open tickets are open at a given time. In our environment, we have over 30,000 resolved tickets while we usually have no more than a few dozen open in any given queue. It makes much more sense for our users to simply look at the open tickets in the queues they are responsible for rather than actually perform a search. When we perform a search, 99% of the time we are searching resolved tickets, not open tickets. In our environment, it makes much more sense to have quick searches return results of resolved and open tickets. Any thoughts (based upon feedback thus far) to simply reverting back to the old way vs. a patch to make things configurable? James Moseley I'd take a patch to make it configurable, but generally, we've found that more often than not, users want to search current tickets quickly. Limiting it to only open tickets makes the actual search much faster and less cluttered. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Privileges not honored for Everyone after 3.8.1 upgrade
rt-users, I recently upgraded from 3.6.5 (MySQL 4.0.21) to 3.8.1 (MySQL 5.0.45), using the following -- /opt/rt3/sbin/rt-setup-database --dba root --action upgrade perl etc/upgrade/schema.mysql-4.0-4.1.pl rt3 (and applying the output) Everything appears to be fine with respects to incoming tickets, ownership, etc. No obvious errors appear in any logs. Authentication is handled by mod_authnz_ldap. One queue in particular, Support has no privileges enabled for the Everyone role. Unprivileged users, which are manually created, have CreateTicket privileges. Prior to the 3.8.1 upgrade, incoming e-mails from unknown users were rejected with the appropriate No permissions to create tickets in queue Support. Only e-mails from existing Unprivileged users would generate tickets. After the 3.8.1 upgrade, any incoming e-mail causes a user to be auto-created by form submission and the ticket to be created in the appropriate queue, disregarding any permissions for the queue. (This is bad.) Auth::Mailfrom appears in 'Admin/Tools/Configuration.html', which as best I understand it, should check the Queue permissions and reject the e-mail appropriately. It doesn't appear that this is occurring. No obvious errors for Auth::Mailfrom appear in any of the logs (error_log, ssl_error_log, maillog, messages). If there's a workaround, e.g. disabling the auto-creation of users, that would work just as well. Any thoughts are appreciated. I'm at a loss for the moment. Thank you for any assistance or insight. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Web interface
Hell I have done 2 installs rt-3.8.1 exactly the same with the same confgis except one is on fedora 7 and the other is on fedora 9 both with all the updates installed the fedora 9 works web as it should do On the fedora 7 the program works ok except the web interface gives everything in text mode. Any ideas please Many thanks _ Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Web interface
Permissions for the html noauth dir Sent via BlackBerry from T-Mobile -Original Message- From: Nick Price [EMAIL PROTECTED] Date: Fri, 5 Sep 2008 04:18:10 To: rt-users@lists.bestpractical.com Subject: [rt-users] Web interface ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
