[rt-users] Assign Global Rights to Group?
We find that the best way for us to manage user rights is to create a number of groups, assign global rights to the groups, and then assign users to the appropriate group. I'm trying to work out how to assign global rights to a group via a Perl script, but I'm not having much luck. A simple case might look something like this, I think: #!/usr/bin/perl use strict; use warnings; use lib /usr/share/request-tracker4/lib; use RT; RT::LoadConfig(); RT::Init(); use RT::Group; use RT::User; use RT::Principal; my ($group, $status, $msg); $group = RT::Group-new( $RT::SystemUser ); $group-LoadUserDefinedGroup( Group2 ); die couldn't load group unless $group-id; print(SelfDescription : . $group-SelfDescription() . \n); $group-GrantRight(Object = , Right = CreateTicket); This works up to and including the print. So the problem, of course, is that the GrantRight call is obviously incomplete. I haven't figured out what the Object should be. And maybe there is some additional work to set it up. Suggestions on where to get started to understand this? Ken -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] 'Everyone' group is missing from upgraded RT installation
Ruslan, Thanks for this very helpful pointer. As you probably suspected, there was in fact an Everyone group. I had failed to understand that I needed to approach my issue by giving Everyone create privileges on a queue, rather than by trying to edit the properties of the Everyone group. Thanks, Ken From: ruslan.zaki...@gmail.com [mailto:ruslan.zaki...@gmail.com] On Behalf Of Ruslan Zakirov Sent: Thursday, April 18, 2013 3:13 AM Cc: RT users Subject: Re: [rt-users] 'Everyone' group is missing from upgraded RT installation On Thu, Apr 18, 2013 at 2:05 AM, Ken Johnson kjohn...@eclypse.org wrote: I recently upgraded an RT installation from 3.4.5 to 4.0.7, in parallel to the original installation, and am still testing RT 4.0. In general things look good now, but I ran in to a difficulty when trying to allow rt-mailgate to create new tickets. As I understand it, I need to allow ticket creation for the Everyone group if 'outside' email users are to create new tickets. Unfortunately, I don't have an Everyone group. OK, I can add one. I tried looking here: https://github.com/bestpractical/rt/blob/stable/etc/initialdata For information on the characteristics that this group should have, but struck out. Where should I look to find out how to set this group up properly? Are you saying that RT 3.4.5 had no Everyone group in the DB? What do you get when you run the following query: SELECT * FROM Groups WHERE Domain = 'SystemInternal'; Ken -- Best regards, Ruslan.
Re: [rt-users] Warning when open ticket 'Modify people' in RT4
On Fri, Apr 12, 2013 at 05:01:38PM -0500, Ken Johnson wrote: I recently upgraded an RT installation from 3.4.5 to 4.0.7, in parallel to the original installation, and am still testing RT 4.0. In general things look good now, but I receive this warning in the Apache2 error.log when I select the Modify people option for a ticket. For example, (http://10.20.30.40/rt4/Ticket/ModifyPeople.html?id=12345) (real IP address obscured...) [Fri Apr 12 21:34:10 2013] [warning]: Use of uninitialized value $Text::Template::GEN5::comment in substitution (s///) at template line 1. (template:1) Your Admin Comment template likely contains older code that a) warns and b) has some bugs. You can go find that template and compare it to the code here: https://github.com/bestpractical/rt/blob/stable/etc/initialdata#L295 After editing your template, ensure that AdminCcs are still sent mail on Comments. It's easy to introduce errors there. -kevin Thanks for this helpful pointer. I checked/updated all of the templates, and added the missing password change template. Ken
[rt-users] Warning when open ticket 'Modify people' in RT4
I recently upgraded an RT installation from 3.4.5 to 4.0.7, in parallel to the original installation, and am still testing RT 4.0. In general things look good now, but I receive this warning in the Apache2 error.log when I select the Modify people option for a ticket. For example, (http://10.20.30.40/rt4/Ticket/ModifyPeople.html?id=12345) (real IP address obscured...) [Fri Apr 12 21:34:10 2013] [warning]: Use of uninitialized value $Text::Template::GEN5::comment in substitution (s///) at template line 1. (template:1) The 'GENnn' part of the message is variable, but 'nn' is always observed to be a sequentially increasing multiple of 5. (0, 5, 10, etc.) What could I do to track this down further? Ken
Re: [rt-users] Database upgrade from 3.4.5 to 3.7.87 fails with Unknown Column
On Fri, Apr 05, 2013 at 05:43:41PM -0500, Ken Johnson wrote: I'm trying to upgrade from RT 3.4.5 to 4.0.7 on Debian 6.0.7. I backed up the existing database and loaded it a new database according the the instructions in UPGRADING.mysql. I reached the point where I believed it was time to perform the first stage of the database upgrades, and used a command like this: rt-setup-database-4 --action upgrade --dba user --dba-password password Enter RT version you're upgrading from: 3.4.5 On Fri, Apr 05, 2013 Kevin Falcone wrote: It looks like at some point in the past - someone upgraded you to 3.4.5 without running the database upgrades. Version 3.3.0 of RT added the Pattern column to the CustomFields table. https://github.com/bestpractical/rt/blob/stable/etc/upgrade/3.3.0/schema.my sql I'd be really concerned and be looking to see what else between your older version and 3.4.5 was never upgraded. -kevin Thank you for the pointer to github. I looked. Based on what tables and columns are present, I conclude that the database updates for 3.3.0 and 3.3.11 were run, but for reasons unknown, the very last part of the 3.3.0 database update, beginning with 'ALTER TABLE CustomFields ...' and including 'UPDATE CustomFields...' did not occur. On the other hand, dropping the Current column from the TicketCustomFieldValues table in the 3.3.11 update did occur. My best idea is to apply the missed portion of the updates and proceed, along the lines of the shell script below. Not ideal, but I don't know a better approach that does not involve time travel. That approach generates one warning during the generation of the queries.sql file: Use of uninitialized value in join or string at /usr/share/request-tracker3.8/etc/upgrade/upgrade-mysql-schema.pl line 261. .Groups.Instance has type VARCHAR however mapping is missing. All of the other operations have no complaints. Ken == script to do the database updates = #!/bin/bash -vx # # Drop the previous RT4 database. # mysql --user=user --password=password /home/shared/sysadmin/dropRT4.sql # # Create an empty RT4 database. # Specify the character set default of the RT4 database. See UPGRADING.mysql item 1b) # mysql --user=user --password=password /home/shared/sysadmin/createRT4.sql # # Dump the RT3 database to an .sql file. See UPGRADING.mysql item 1a) # mysqldump -F --opt --user=user --password=password --default-character-set=binary rt3 /tmp/daily/rt3.sql # # Load rt3.sql into the RT4 database. See UPGRADING.mysql item 1c) # mysql --user=user --password=password --default-character-set=binary rt4 /tmp/daily/rt3.sql # # Grant access for rt_user to the RT4 database # mysql --user=user --password=password rt4 /home/shared/sysadmin/grantRT4.sql # # Apply the 3.3.0 database update subset # mysql --user=user --password=password rt4 /home/shared/sysadmin/rt3.3.0dbpartial.sql # # Apply the 3.3.11 database update subset (nothing to do -- previously done.) # # mysql --user=user --password=password rt4 /home/shared/sysadmin/rt3.3.11dbpartial.sql # # Apply the 3.3.11-3.7.87 updates with rt-setup-database-4 --action upgrade --dba user --dba-password password # rt-setup-database-4 --action upgrade --dba user --dba-password password /home/shared/sysadmin/first.txt # # Apply the RT 3.8 schema upgrades. See UPGRADING.mysql item 5) # First step, generate queries.sql file # Second step, apply queries.sql file. See UPGRADING.mysql item 7) # See /usr/share/request-tracker3.8/etc/upgrade-mysql-schema.pl perl /usr/share/request-tracker3.8/etc/upgrade/upgrade-mysql-schema.pl rt4 user password /home/shared/sysadmin/queries.sql mysql --user=user --password=password rt4 /home/shared/sysadmin/queries.sql # # Apply the RT 3.7.87-4.0.6 database updates. See UPGRADING.mysql item 8) # rt-setup-database-4 --action upgrade --dba user --dba-password password /home/shared/sysadmin/second.txt
[rt-users] Meaning of database upgrade message: DBD::mysql::st execute failed: Unknown column 'column-name' in 'table-name'
Ah. In this case, 'Unknown column' means 'expected column not found', or 'known column missing', from the point of view of the database conversion program. It does _not_ mean 'an unexpected column was found', or 'a column unknown to me was found'. Well, perhaps there will be someone else for whom this was not utterly obvious. Ken
[rt-users] Database upgrade from 3.4.5 to 3.7.87 fails with Unkown Column
I'm trying to upgrade from RT 3.4.5 to 4.0.7 on Debian 6.0.7. I backed up the existing database and loaded it a new database according the the instructions in UPGRADING.mysql. I reached the point where I believed it was time to perform the first stage of the database upgrades, and used a command like this: rt-setup-database-4 --action upgrade --dba user --dba-password password Here's what I saw: Working with: Type: mysql Host: localhost Name: /var/lib/dbconfig-common/sqlite3/request-tracker4/rtdb User: DBA:user Enter RT version you're upgrading from: 3.4.5 Going to apply following upgrades: * 3.5.1 * ... * 4.0.6 Enter RT version if you want to stop upgrade at some point, or leave it blank if you want apply above upgrades: 3.7.87 Going to apply following upgrades: * 3.5.1 * 3.7.1 * 3.7.3 * 3.7.10 * 3.7.15 * 3.7.19 * 3.7.81 * 3.7.82 * 3.7.85 * 3.7.86 * 3.7.87 IT'S VERY IMPORTANT TO BACK UP BEFORE THIS STEP Proceed [y/N]:y Processing 3.5.1 Now inserting data. Processing 3.7.1 Now inserting data. Processing 3.7.3 Now populating database schema. [Fri Apr 5 21:40:38 2013] [crit]: DBD::mysql::st execute failed: Unknown column 'Pattern' in 'CustomFields' at /usr/share/request-tracker4/lib/RT/Handle.pm line 515. (/usr/share/request-tracker4/lib/RT.pm:351) DBD::mysql::st execute failed: Unknown column 'Pattern' in 'CustomFields' at /usr/share/request-tracker4/lib/RT/Handle.pm line 515. So I thought that perhaps there was some bogus column in the old database: mysql use rt3 Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql show tables; +-+ | Tables_in_rt3 | +-+ | ACL | | Attachments | | Attributes | | CachedGroupMembers | | CustomFieldValues | | CustomFields| | GroupMembers| | Groups | | Links | | ObjectCustomFieldValues | | ObjectCustomFields | | Principals | | Queues | | ScripActions| | ScripConditions | | Scrips | | Templates | | TicketCustomFieldValues | | Tickets | | Transactions| | Users | | sessions| +-+ 22 rows in set (0.00 sec)ysql describe CustomFields; +---+--+--+-+-++ | Field | Type | Null | Key | Default | Extra | +---+--+--+-+-++ | id| int(11) | NO | PRI | NULL| auto_increment | | Name | varchar(200) | YES | | NULL|| | Type | varchar(200) | YES | | NULL|| | Queue | int(11) | NO | | 0 || | Description | varchar(255) | YES | | NULL|| | SortOrder | int(11) | NO | | 0 || | Creator | int(11) | NO | | 0 || | Created | datetime | YES | | NULL|| | LastUpdatedBy | int(11) | NO | | 0 || | LastUpdated | datetime | YES | | NULL|| | Disabled | smallint(6) | NO | MUL | 0 || +---+--+--+-+-++ 11 rows in set (0.00 sec) I don't see that column in that table in the original database. Can anyone point me in the right direction? Ken
Re: [rt-users] Database upgrade from 3.4.5 to 3.7.87 fails with Unkown Column
On Fri, Apr 05, 2013 at 05:43:41PM -0500, Ken Johnson wrote: I'm trying to upgrade from RT 3.4.5 to 4.0.7 on Debian 6.0.7. I backed up the existing database and loaded it a new database according the the instructions in UPGRADING.mysql. I reached the point where I believed it was time to perform the first stage of the database upgrades, and used a command like this: rt-setup-database-4 --action upgrade --dba user --dba-password password Enter RT version you're upgrading from: 3.4.5 It looks like at some point in the past - someone upgraded you to 3.4.5 without running the database upgrades. Version 3.3.0 of RT added the Pattern column to the CustomFields table. https://github.com/bestpractical/rt/blob/stable/etc/upgrade/3.3.0/schema.mys ql I'd be really concerned and be looking to see what else between your older version and 3.4.5 was never upgraded. -kevin +---+--+--+-+-++ | Field | Type | Null | Key | Default | Extra | +---+--+--+-+-++ | id| int(11) | NO | PRI | NULL| auto_increment | | Name | varchar(200) | YES | | NULL|| | Type | varchar(200) | YES | | NULL|| | Queue | int(11) | NO | | 0 || | Description | varchar(255) | YES | | NULL|| | SortOrder | int(11) | NO | | 0 || | Creator | int(11) | NO | | 0 || | Created | datetime | YES | | NULL|| | LastUpdatedBy | int(11) | NO | | 0 || | LastUpdated | datetime | YES | | NULL|| | Disabled | smallint(6) | NO | MUL | 0 || +---+--+--+-+-++ Kevin, Thank you for replying! I can look into the database upgrade issue. I'm still confused, though. Why don't I see the the Pattern field in my 3.4.5 database in the CustomFields table (shown above)? Where would I look for it if not there? Or is it there but I don't recognize it? Ken
