Upgraded to 3.6.6 and superuser functionality missing

Yesterday, I upgraded RT from 3.6.5 to 3.6.6 and now when I login as
root, I don’t see any superuser functions available. I don’t remember
the last time I logged in as root, but it could only have been a month
or two ago. We’re using MySQL 5.0.22 as the backend on RedHat
Enterprise Server Release 5. I’ve checked the database, and we still
have the root user, it still is in the superuser group. I’d appreciate
any ideas–thanks.

Karl Boyken

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)

smime.p7s (3.18 KB)

What are you expecting to see?On 2/19/08, Karl Boyken boyken@divms.uiowa.edu wrote:

Yesterday, I upgraded RT from 3.6.5 to 3.6.6 and now when I login as
root, I don’t see any superuser functions available. I don’t remember
the last time I logged in as root, but it could only have been a month
or two ago. We’re using MySQL 5.0.22 as the backend on RedHat
Enterprise Server Release 5. I’ve checked the database, and we still
have the root user, it still is in the superuser group. I’d appreciate
any ideas–thanks.

Karl Boyken


Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

I don’t see even Preferences in the menu bar. I was expecting to be
able to manipulate rights–that’s gone. All I see in the menu bar are:

 *    Home
 * · Simple Search
 * · Tickets
 * · Tools
 * · Approval

In other words, root seems to have the same functionality in the GUI as
a regular user here.

Karl

Todd Chapman wrote:

What are you expecting to see?

Yesterday, I upgraded RT from 3.6.5 to 3.6.6 and now when I login as
root, I don’t see any superuser functions available. I don’t remember
the last time I logged in as root, but it could only have been a month
or two ago. We’re using MySQL 5.0.22 as the backend on RedHat
Enterprise Server Release 5. I’ve checked the database, and we still
have the root user, it still is in the superuser group. I’d appreciate
any ideas–thanks.

Karl Boyken


Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)

smime.p7s (3.18 KB)

Have you updated deps, cleaned mason cache and restarted apache server?On Feb 19, 2008 8:19 PM, Karl Boyken boyken@divms.uiowa.edu wrote:

I don’t see even Preferences in the menu bar. I was expecting to be
able to manipulate rights–that’s gone. All I see in the menu bar are:

 *    Home
 * · Simple Search
 * · Tickets
 * · Tools
 * · Approval

In other words, root seems to have the same functionality in the GUI as
a regular user here.

Karl

Todd Chapman wrote:

What are you expecting to see?

On 2/19/08, Karl Boyken boyken@divms.uiowa.edu wrote:

Yesterday, I upgraded RT from 3.6.5 to 3.6.6 and now when I login as
root, I don’t see any superuser functions available. I don’t remember
the last time I logged in as root, but it could only have been a month
or two ago. We’re using MySQL 5.0.22 as the backend on RedHat
Enterprise Server Release 5. I’ve checked the database, and we still
have the root user, it still is in the superuser group. I’d appreciate
any ideas–thanks.

Karl Boyken


Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Yep, did all that.

I rolled back to 3.6.5, and still have the same problem. I suspect I
may at some point have screwed up the rt3 database somehow. I use
rtx-shredder and at one point, last December, after I first began using
it, I inadvertently deleted root, but I restored it and was able to
login and everything seemed fine–had full superuser functionality. But
who knows?

I just now tried the restore-superuser-privileges tip from the Wiki, but
that didn’t work, either. So, now, I’m thinking I’ll recreate the
database–start over with a new, pristine db–and suck over values from
the current one. Any idea if that’s just a big waste of time?

Karl

Ruslan Zakirov wrote:

Have you updated deps, cleaned mason cache and restarted apache server?

I don’t see even Preferences in the menu bar. I was expecting to be
able to manipulate rights–that’s gone. All I see in the menu bar are:

 *    Home
 * · Simple Search
 * · Tickets
 * · Tools
 * · Approval

In other words, root seems to have the same functionality in the GUI as
a regular user here.

Karl

Todd Chapman wrote:

What are you expecting to see?

Yesterday, I upgraded RT from 3.6.5 to 3.6.6 and now when I login as
root, I don’t see any superuser functions available. I don’t remember
the last time I logged in as root, but it could only have been a month
or two ago. We’re using MySQL 5.0.22 as the backend on RedHat
Enterprise Server Release 5. I’ve checked the database, and we still
have the root user, it still is in the superuser group. I’d appreciate
any ideas–thanks.

Karl Boyken


Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)

smime.p7s (3.18 KB)

Karl,

Have you gone into the DataBase with SQL and looked at what is in the 

table records? especially for root? That might help, especially if you
see something glaringly odd. Then you could find out what you need to
change and modify that particular record. Normally, I wouldn’t recommend
modifying the RT DataBasee directly, but if you need to “fix” something,
sometimes that’s the only way to do it. I’d look at the USERS table to
get the ID number and then the PRINCIPALS table and asee if the Id is
disabled or not. If that doesn’t indicate anything, then look at the ACL
table. There must be something there that would give you a clue. Hope
this helps.

Kenn
LBNLOn 2/19/2008 9:45 AM, Karl Boyken wrote:

Yep, did all that.

I rolled back to 3.6.5, and still have the same problem. I suspect I
may at some point have screwed up the rt3 database somehow. I use
rtx-shredder and at one point, last December, after I first began using
it, I inadvertently deleted root, but I restored it and was able to
login and everything seemed fine–had full superuser functionality. But
who knows?

I just now tried the restore-superuser-privileges tip from the Wiki, but
that didn’t work, either. So, now, I’m thinking I’ll recreate the
database–start over with a new, pristine db–and suck over values from
the current one. Any idea if that’s just a big waste of time?

Karl

Ruslan Zakirov wrote:

Have you updated deps, cleaned mason cache and restarted apache server?

On Feb 19, 2008 8:19 PM, Karl Boyken boyken@divms.uiowa.edu wrote:

I don’t see even Preferences in the menu bar. I was expecting to be
able to manipulate rights–that’s gone. All I see in the menu bar are:

 *    Home
 * · Simple Search
 * · Tickets
 * · Tools
 * · Approval

In other words, root seems to have the same functionality in the GUI as
a regular user here.

Karl

Todd Chapman wrote:

What are you expecting to see?

On 2/19/08, Karl Boyken boyken@divms.uiowa.edu wrote:

Yesterday, I upgraded RT from 3.6.5 to 3.6.6 and now when I login as
root, I don’t see any superuser functions available. I don’t remember
the last time I logged in as root, but it could only have been a month
or two ago. We’re using MySQL 5.0.22 as the backend on RedHat
Enterprise Server Release 5. I’ve checked the database, and we still
have the root user, it still is in the superuser group. I’d
appreciate
any ideas–thanks.

Karl Boyken


Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Yes, I’ve poked around a bit in the database. I haven’t seen anything
glaringly wrong yet, but that could be more a statement about my
ignorance of the RT schema than anything else. The ‘root’ user is in
Users, and it looks like it has all the settings it would have from
creating the initial db. There are two SuperUser rights entries in the
ACL table, one for RT_System and one for root.

Karl

Kenneth Crocker wrote:

Karl,

Have you gone into the DataBase with SQL and looked at what is in 

the table records? especially for root? That might help, especially if
you see something glaringly odd. Then you could find out what you need
to change and modify that particular record. Normally, I wouldn’t
recommend modifying the RT DataBasee directly, but if you need to “fix”
something, sometimes that’s the only way to do it. I’d look at the USERS
table to get the ID number and then the PRINCIPALS table and asee if the
Id is disabled or not. If that doesn’t indicate anything, then look at
the ACL table. There must be something there that would give you a clue.
Hope this helps.

Kenn
LBNL

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)

smime.p7s (3.18 KB)

One additional bit of info:

When I run the Perl code from Wiki that’s supposed to restore superuser,
I get “Principal 12 not found.” root has id 12 in the Users table.
Here’s the Perl code:

/usr/bin/perl -I/opt/rt3/lib -MRT -e’RT::LoadConfig; RT::Init;

my $u=RT::User->new($RT::SystemUser);
$u->Load(“root”);
($val,$msg) = $u->PrincipalObj->GrantRight(Object=> $RT::System,
Right => “SuperUser”);
print “$msg\n”’

In mysql, a “select * from Principals where id=‘12’;” yields an entry
for root:

| id | PrincipalType | ObjectId | Disabled |
| 12 | User | 12 | 0 |

Karl

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)

smime.p7s (3.18 KB)

Karl,

Go to the PRINCIPALS table and look up the correct UserID in the and 

see if it is enabled/disabled. The USers table doesn’t have that info.

Kenn
LBNLOn 2/19/2008 11:10 AM, Karl Boyken wrote:

Yes, I’ve poked around a bit in the database. I haven’t seen anything
glaringly wrong yet, but that could be more a statement about my
ignorance of the RT schema than anything else. The ‘root’ user is in
Users, and it looks like it has all the settings it would have from
creating the initial db. There are two SuperUser rights entries in the
ACL table, one for RT_System and one for root.

Karl

Kenneth Crocker wrote:

Karl,

Have you gone into the DataBase with SQL and looked at what is in 

the table records? especially for root? That might help, especially if
you see something glaringly odd. Then you could find out what you need
to change and modify that particular record. Normally, I wouldn’t
recommend modifying the RT DataBasee directly, but if you need to
“fix” something, sometimes that’s the only way to do it. I’d look at
the USERS table to get the ID number and then the PRINCIPALS table and
asee if the Id is disabled or not. If that doesn’t indicate anything,
then look at the ACL table. There must be something there that would
give you a clue. Hope this helps.

Kenn
LBNL

Karl,

What do you get from the "GROUPS" table? There could be an "equivilancy 

ID" for that userID.

Kenn
LBNLOn 2/19/2008 11:30 AM, Karl Boyken wrote:

One additional bit of info:

When I run the Perl code from Wiki that’s supposed to restore superuser,
I get “Principal 12 not found.” root has id 12 in the Users table.
Here’s the Perl code:

/usr/bin/perl -I/opt/rt3/lib -MRT -e’RT::LoadConfig; RT::Init;

my $u=RT::User->new($RT::SystemUser);
$u->Load(“root”);
($val,$msg) = $u->PrincipalObj->GrantRight(Object=> $RT::System,
Right => “SuperUser”);
print “$msg\n”’

In mysql, a “select * from Principals where id=‘12’;” yields an entry
for root:

±—±--------------±---------±---------+
| id | PrincipalType | ObjectId | Disabled |
±—±--------------±---------±---------+
| 12 | User | 12 | 0 |
±—±--------------±---------±---------+

Karl



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Kenn, is this what you mean?

mysql> select * from Groups where Description=‘ACL equiv. for user 12’;
| id | Name | Description | Domain | Type |
Instance |
| 13 | User 12 | ACL equiv. for user 12 | ACLEquivalence | UserEquiv |
12 |
1 row in set (0.01 sec)

Karl

Kenneth Crocker wrote:

Karl,

What do you get from the "GROUPS" table? There could be an 

“equivilancy ID” for that userID.

Kenn
LBNL

One additional bit of info:

When I run the Perl code from Wiki that’s supposed to restore
superuser, I get “Principal 12 not found.” root has id 12 in the
Users table. Here’s the Perl code:

/usr/bin/perl -I/opt/rt3/lib -MRT -e’RT::LoadConfig; RT::Init;

my $u=RT::User->new($RT::SystemUser);
$u->Load(“root”);
($val,$msg) = $u->PrincipalObj->GrantRight(Object=> $RT::System,
Right => “SuperUser”);
print “$msg\n”’

In mysql, a “select * from Principals where id=‘12’;” yields an entry
for root:

±—±--------------±---------±---------+
| id | PrincipalType | ObjectId | Disabled |
±—±--------------±---------±---------+
| 12 | User | 12 | 0 |
±—±--------------±---------±---------+

Karl



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)

smime.p7s (3.18 KB)

Karl,

Now see if the Id number is disabled in the PRINCIPALS Tables.

Kenn
LBNLOn 2/19/2008 12:39 PM, Karl Boyken wrote:

Kenn, is this what you mean?

mysql> select * from Groups where Description=‘ACL equiv. for user 12’;
±—±--------±-----------------------±---------------±----------±---------+

| id | Name | Description | Domain | Type |
Instance |
±—±--------±-----------------------±---------------±----------±---------+

| 13 | User 12 | ACL equiv. for user 12 | ACLEquivalence | UserEquiv |
12 |
±—±--------±-----------------------±---------------±----------±---------+

1 row in set (0.01 sec)

Karl

Kenneth Crocker wrote:

Karl,

What do you get from the "GROUPS" table? There could be an 

“equivilancy ID” for that userID.

Kenn
LBNL

On 2/19/2008 11:30 AM, Karl Boyken wrote:

One additional bit of info:

When I run the Perl code from Wiki that’s supposed to restore
superuser, I get “Principal 12 not found.” root has id 12 in the
Users table. Here’s the Perl code:

/usr/bin/perl -I/opt/rt3/lib -MRT -e’RT::LoadConfig; RT::Init;

my $u=RT::User->new($RT::SystemUser);
$u->Load(“root”);
($val,$msg) = $u->PrincipalObj->GrantRight(Object=> $RT::System,
Right => “SuperUser”);
print “$msg\n”’

In mysql, a “select * from Principals where id=‘12’;” yields an entry
for root:

±—±--------------±---------±---------+
| id | PrincipalType | ObjectId | Disabled |
±—±--------------±---------±---------+
| 12 | User | 12 | 0 |
±—±--------------±---------±---------+

Karl



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Nope not disabled:

mysql> select * from Principals where ObjectID=12;
| id | PrincipalType | ObjectId | Disabled |
| 12 | User | 12 | 0 |
1 row in set (0.00 sec)

Kenneth Crocker wrote:

Karl,

Now see if the Id number is disabled in the PRINCIPALS Tables.

Kenn
LBNL

Kenn, is this what you mean?

mysql> select * from Groups where Description=‘ACL equiv. for user 12’;
±—±--------±-----------------------±---------------±----------±---------+

| id | Name | Description | Domain | Type |
Instance |
±—±--------±-----------------------±---------------±----------±---------+

| 13 | User 12 | ACL equiv. for user 12 | ACLEquivalence | UserEquiv |
12 |
±—±--------±-----------------------±---------------±----------±---------+

1 row in set (0.01 sec)

Karl

Kenneth Crocker wrote:

Karl,

What do you get from the "GROUPS" table? There could be an 

“equivilancy ID” for that userID.

Kenn
LBNL

One additional bit of info:

When I run the Perl code from Wiki that’s supposed to restore
superuser, I get “Principal 12 not found.” root has id 12 in the
Users table. Here’s the Perl code:

/usr/bin/perl -I/opt/rt3/lib -MRT -e’RT::LoadConfig; RT::Init;

my $u=RT::User->new($RT::SystemUser);
$u->Load(“root”);
($val,$msg) = $u->PrincipalObj->GrantRight(Object=>
$RT::System, Right => “SuperUser”);
print “$msg\n”’

In mysql, a “select * from Principals where id=‘12’;” yields an
entry for root:

±—±--------------±---------±---------+
| id | PrincipalType | ObjectId | Disabled |
±—±--------------±---------±---------+
| 12 | User | 12 | 0 |
±—±--------------±---------±---------+

Karl



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)

smime.p7s (3.18 KB)

Thanks very much to Ruslan Zakirov for giving me enough clue to see that
the entry for the ACL equivalence group was missing from the Principals
table. That did the trick!

Karl

Karl Boyken, system administrator
karl-boyken@uiowa.edu
303A MLH, Dept. of Comp. Sci.
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA 52242 319-335-2730 (voice)
319-335-3668 (fax)

smime.p7s (3.18 KB)

Karl,

I'm at a loss. I can only recommend that you try to get more detailed 

info on the error thru logs, etc. Sorry.

Kenn
LBNLOn 2/20/2008 7:02 AM, Karl Boyken wrote:

Nope not disabled:

mysql> select * from Principals where ObjectID=12;
±—±--------------±---------±---------+
| id | PrincipalType | ObjectId | Disabled |
±—±--------------±---------±---------+
| 12 | User | 12 | 0 |
±—±--------------±---------±---------+
1 row in set (0.00 sec)

Kenneth Crocker wrote:

Karl,

Now see if the Id number is disabled in the PRINCIPALS Tables.

Kenn
LBNL

On 2/19/2008 12:39 PM, Karl Boyken wrote:

Kenn, is this what you mean?

mysql> select * from Groups where Description=‘ACL equiv. for user 12’;
±—±--------±-----------------------±---------------±----------±---------+

| id | Name | Description | Domain | Type
| Instance |
±—±--------±-----------------------±---------------±----------±---------+

| 13 | User 12 | ACL equiv. for user 12 | ACLEquivalence | UserEquiv
| 12 |
±—±--------±-----------------------±---------------±----------±---------+

1 row in set (0.01 sec)

Karl

Kenneth Crocker wrote:

Karl,

What do you get from the "GROUPS" table? There could be an 

“equivilancy ID” for that userID.

Kenn
LBNL

On 2/19/2008 11:30 AM, Karl Boyken wrote:

One additional bit of info:

When I run the Perl code from Wiki that’s supposed to restore
superuser, I get “Principal 12 not found.” root has id 12 in the
Users table. Here’s the Perl code:

/usr/bin/perl -I/opt/rt3/lib -MRT -e’RT::LoadConfig; RT::Init;

my $u=RT::User->new($RT::SystemUser);
$u->Load(“root”);
($val,$msg) = $u->PrincipalObj->GrantRight(Object=>
$RT::System, Right => “SuperUser”);
print “$msg\n”’

In mysql, a “select * from Principals where id=‘12’;” yields an
entry for root:

±—±--------------±---------±---------+
| id | PrincipalType | ObjectId | Disabled |
±—±--------------±---------±---------+
| 12 | User | 12 | 0 |
±—±--------------±---------±---------+

Karl



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly
Media. Buy a copy at http://rtbook.bestpractical.com