Re: [rt-users] Vexed by Permission Denied
On 02/17/2010 08:14 AM, Todd Herr wrote: On 02/17/2010 04:17 AM, Simon Dray wrote: Todd You may find that you need to add modify ticket either at user or group level Thanks, Simon. I'll give that a whirl and do some more digging to see if I can determine a pattern to the behavior, which occurs on email replies to tickets (i.e., closed vice open; requestor vice cc vice other, etc.) Just to follow up here... While I didn't see any noticeable pattern to the issue, other than the fact that all affected tickets were in Queue B, adding ModifyTicket rights to the roles in question seems to have made the problem go away. Thanks again for all on-list and off-list responses. -- Todd Herr ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com 2010 RT Training Sessions! San Francisco, CA, USA - Feb 22 23 Dublin, Ireland - Mar 15 16 Boston, MA, USA - April 5 6 Washington DC, USA - Oct 25 26 Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Vexed by Permission Denied
On 02/17/2010 04:17 AM, Simon Dray wrote: Todd You may find that you need to add modify ticket either at user or group level Thanks, Simon. I'll give that a whirl and do some more digging to see if I can determine a pattern to the behavior, which occurs on email replies to tickets (i.e., closed vice open; requestor vice cc vice other, etc.) -- Todd Herr ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com 2010 RT Training Sessions! San Francisco, CA, USA - Feb 22 23 Dublin, Ireland - Mar 15 16 Boston, MA, USA - April 5 6 Washington DC, USA - Oct 25 26 Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Vexed by Permission Denied
or maybe I just need a clue by four with regard to rights. Since migrating from 3.6.0 to 3.8.6, we've been getting reports of people getting permission denied errors from time to time. I know this is a common problem, and I thought I'd taken steps to fix it, based on what I'd read, but today proved otherwise, so I'm going to throw myself on the the mercy of the list. We have two queues, call them A and B. Most tickets are created in A and stay in A for their entire lives; some get moved to B, and I sense it's only the ones in B that have the issue. For GLOBAL group rights, I have: o Everyone - CreateTicket, ReplyToTicket o Requestor - CreateTicket, ReplyToTicket o Cc - CreateTicket, ReplyToTicket For Queue A group rights, I have: o Everyone - CreateTicket, ReplyToTicket o Requestor - CreateTicket, ReplyToTicket For Queue B group rights, I have: o Everyone - CreateTicket, ReplyToTicket o Requestor - CreateTicket, ReplyToTicket Now, I notice that I don't have Cc setup for either queue, and I know that the most recent occurrence was for someone in the Cc group on a ticket in Queue B. I perceive, therefore, that I must also have: o Cc - CreateTicket, ReplyToTicket for both queues, correct? Also, is it necessary for me to add ModifyTicket to any of these (in case of a reply to a ticket that's been set to Resolved) or is ReplyToTicket enough? Finally, are there any permissions I'm missing? Thanks. -- Todd Herr ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com 2010 RT Training Sessions! San Francisco, CA, USA - Feb 22 23 Dublin, Ireland - Mar 15 16 Boston, MA, USA - April 5 6 Washington DC, USA - Oct 25 26 Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Version 3.8.1 upgrade - UPGRADING.mysql file clarification
I'll confess to still not quite being able to parse steps 2 and 3 in the UPGRADING.mysql file; Follow instructions in the README file to the step 7); Apply changes described in the seven step, but only up to version 3.8.0. Here's step 7 from README: As a user with permission to install RT in your chosen installation directory, type: make upgrade This will install new binaries, config files and libraries without overwriting your RT database. Update etc/RT_SiteConfig.pm in your RT installation directory. You'll need to add any new values you need to change from the defaults in etc/RT_Config.pm You may also need to update RT's database. You can do this with the rt-setup-database tool. Replace root with the name of the dba user on your database (root is the default for MySQL). You will be prompted for your previous version of RT (such as 3.6.4) so that we can calculate which database updates to apply You should back up your database before running this command. /opt/rt3/sbin/rt-setup-database --dba root --prompt-for-dba-password --action upgrade Clear mason cache dir: rm -fr /opt/rt3/var/mason_data/obj Stop and start web-server. So, to clarify then... untar distro ./configure -blahblahblah make testdeps make fixdeps (lather, rinse, repeat as necessary) backup database make upgrade perl etc/upgrade/schema.mysql-4.0-4.1.pl db user pass sql.queries mysql -u root -p rt3 sql.queries /opt/rt3/sbin/rt-setup-database --dba root --prompt-for-dba-password --action upgrade Is that the right sequence of steps, or does make upgrade come after the schema upgrades? Drew Barnes wrote: Yup. Todd Herr wrote: Hello. I'm still in the planning stages of an upgrade from 3.6.0, with MySQL 5.0.22, to 3.8.1, and I'm a bit confused by contents of the UPGRADING.mysql file. The file includes the line: If you're upgrading RT from versions prior to 3.8.0 then you MUST follow instructions below. but those instructions all seem to speak to an upgrade of MySQL from 4.0 to 4.1, and I'm already running MySQL 5.0.22: 1) Backup RT database. It's really good to test that you can restore from this backup. 2) Follow instructions in the README file to the step 7). 3) Apply changes described in the seven step, but only up to version 3.8.0. 4) Apply mysql 4.0-4.1 schema changes. RT tarball has script etc/upgrade/schema.mysql-4.0-4.1.pl that generates SQL queries to upgrade schema of the DB. Run it: perl etc/upgrade/schema.mysql-4.0-4.1.pl db user pass sql.queries 5) Check sanity of sql queries yourself or consult with your DBA 6) Apply queries. Note that this step can take a while. May require additional space on your hard drive comparable with size of your tables. mysql -u root -p rt3 sql.queries So, my question is, do I have to follow the instructions in the UPGRADING.mysql file, given that I'm already running MySQL 5.0.22? -- Todd Herr 703.220.4153 ___ 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] Version 3.8.1 upgrade - UPGRADING.mysql file clarification
Hello. I'm still in the planning stages of an upgrade from 3.6.0, with MySQL 5.0.22, to 3.8.1, and I'm a bit confused by contents of the UPGRADING.mysql file. The file includes the line: If you're upgrading RT from versions prior to 3.8.0 then you MUST follow instructions below. but those instructions all seem to speak to an upgrade of MySQL from 4.0 to 4.1, and I'm already running MySQL 5.0.22: 1) Backup RT database. It's really good to test that you can restore from this backup. 2) Follow instructions in the README file to the step 7). 3) Apply changes described in the seven step, but only up to version 3.8.0. 4) Apply mysql 4.0-4.1 schema changes. RT tarball has script etc/upgrade/schema.mysql-4.0-4.1.pl that generates SQL queries to upgrade schema of the DB. Run it: perl etc/upgrade/schema.mysql-4.0-4.1.pl db user pass sql.queries 5) Check sanity of sql queries yourself or consult with your DBA 6) Apply queries. Note that this step can take a while. May require additional space on your hard drive comparable with size of your tables. mysql -u root -p rt3 sql.queries So, my question is, do I have to follow the instructions in the UPGRADING.mysql file, given that I'm already running MySQL 5.0.22? -- Todd Herr ___ 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] Upgrading from 3.6.0 to 3.8.1 - cpansign -v fails - GnuPG::Interface and Module::Versions::Report
Hi. I'm going through the make fixdeps step of an upgrade to 3.8.1, and I'm running into problems installing/upgrading two perl modules. Here's what make testdeps reports: SOME DEPENDENCIES WERE MISSING. GPG missing dependencies: GnuPG::Interface...MISSING CORE missing dependencies: Module::Versions::Report = 1.05...MISSING Module::Versions::Report version 1.05 required--this is only version 1.02 make: *** [testdeps] Error 1 I can't manage to install/upgrade those perl modules, because their GPG signatures are not properly verifying. Here's what cpansign -v reports for Module-Versions-Report-1.05: Executing gpg --verify --batch --no-tty --keyserver=hkp://pgp.mit.edu:11371 --keyserver-options=auto-key-retrieve SIGNATURE gpg: Signature made Fri Jun 13 15:30:32 2008 EDT using DSA key ID 108E4046 gpg: Good signature from Jesse Vincent [EMAIL PROTECTED] gpg: aka Jesse Vincent [EMAIL PROTECTED] gpg: aka Jesse Vincent [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: AB4A 62CF 1A1A 119A 0462 39D6 122F 5DF7 108E 4046 --- SIGNATURE 2008-06-13 15:30:34.0 -0400 +++ - 2008-10-16 22:19:33.048637000 -0400 @@ -17,7 +17,7 @@ SHA1 bab979585b69021cd5060cc9d961382dee57c852 ChangeLog SHA1 5100a6effb9d891380cdef4568fd1b76256374a1 MANIFEST SHA1 b06a8885d1afbe56e1601b4950784b2dfc0a5208 MANIFEST.SKIP -SHA1 f989d5dce8c4cabe64fb945934be60116750ef8e META.yml +SHA1 96306e2dbb0a716c928f66f0b9eb3492caad0416 META.yml SHA1 13483ba20165e50ad24143c1a8a017f83bffe094 Makefile.PL SHA1 c1ef7c52be72b6f5c504fdc57bf5b8e438f80193 README SHA1 6d28fb26b7ebffb34df6363e8671cd1dc74ae917 lib/Module/Versions/Report.pm == MISMATCHED content between SIGNATURE and distribution files! == and here's what I get for cpansign -v for GnuPG-Interface-0.36: Executing gpg --verify --batch --no-tty --keyserver=hkp://pgp.mit.edu:11371 --keyserver-options=auto-key-retrieve SIGNATURE gpg: Signature made Mon Aug 13 12:25:15 2007 EDT using DSA key ID 108E4046 gpg: Good signature from Jesse Vincent [EMAIL PROTECTED] gpg: aka Jesse Vincent [EMAIL PROTECTED] gpg: aka Jesse Vincent [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: AB4A 62CF 1A1A 119A 0462 39D6 122F 5DF7 108E 4046 --- SIGNATURE 2007-08-13 12:25:15.0 -0400 +++ - 2008-10-16 22:21:03.929275000 -0400 @@ -16,7 +16,8 @@ SHA1 187c2cfc1fc31d42c18d5b1653afa1a905bf266c COPYING SHA1 5df20960703ba8651c67f36ed4ed601e0d0d4406 ChangeLog -SHA1 ae07f475fb7a1668d2ffcfe090f99961ddb77d41 MANIFEST +SHA1 9da791ec2e2601cd2ec44553c319820ef4de6c0d MANIFEST +SHA1 ed72de33d3749888766ced62d18d95df9ad7e74d META.yml SHA1 7beeb96d32ce9fd224db1fe25052960fe640c464 Makefile.PL SHA1 d6e32c5128419cdbfe6e6f846ff7f64fc0adac2f NEWS SHA1 1047dc54823b1321e939274dd261d8e40febee24 README == MISMATCHED content between SIGNATURE and distribution files! == Both modules were downloaded from CPAN today, October 16. Jesse, I know you're a frequent poster to this list, so I'm hoping you can give me some clues here. Thank you all for your time. -- Todd Herr ___ 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
