Twist on "User could not be created: Email address in use"

RT Users
1

I’m very fortunate to have had our old ticketing system crash so I can
quickly bring RT into production :slight_smile:

The problem is a few bugs in the build RT 3.03 (RedHat 7.3, Perl 5.61,
Apache2, FastCGI, MySql 4.013)
Yes I know, I should update Perl and RT (which is in progress on a
FreeBSD machine) but I need a work around now.

So I have a common problem of trying to transform someone who submitted
an email into a privelged user.
The typical fix for this is Configuration:Users:Select Users and check
the “include disabled users in search” box.
However this doesn’t seem to work in my particular build. You search
and it doesn’t display anything.

Because the typical fix doesn’t work for me I started browsing the db
tables:
Users, GroupMembers, CachedGroupMembers, and I can’t figure out what
flags allow a user to be priveleged.
Do they need become a member of a priveleged users group (which ID?)
What’s the deal with CachedGroupMembers? If I modify GroupMembers
what needs to restart for the update to happen?

Thanks,
Mike

2

Have you tried to search in the user list by e-mail address or part of
it?

Samuel-----Original Message-----
From: Mike Patterson [mailto:mikep@uclink.berkeley.edu]
Sent: Tuesday,23 September,2003 15:45
To: rt-users@lists.fsck.com

I’m very fortunate to have had our old ticketing system crash so I can
quickly bring RT into production :slight_smile:

The problem is a few bugs in the build RT 3.03 (RedHat 7.3, Perl 5.61,
Apache2, FastCGI, MySql 4.013) Yes I know, I should update Perl and RT
(which is in progress on a FreeBSD machine) but I need a work around
now.

So I have a common problem of trying to transform someone who submitted
an email into a privelged user.
The typical fix for this is Configuration:Users:Select Users and check
the “include disabled users in search” box.
However this doesn’t seem to work in my particular build. You search
and it doesn’t display anything.

Because the typical fix doesn’t work for me I started browsing the db
tables:
Users, GroupMembers, CachedGroupMembers, and I can’t figure out what
flags allow a user to be priveleged.
Do they need become a member of a priveleged users group (which ID?)
What’s the deal with CachedGroupMembers? If I modify GroupMembers what
needs to restart for the update to happen?

Thanks,
Mike

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

3

Subject: RE: [rt-users] Twist on “User could not be created: Email address in use”
From: “Senoner Samuel” Samuel.Senoner@eurac.edu
Have you tried to search in the user list by e-mail address or part of
it?

Yes I’ve searched by email address. It still doesn’t work for me (and yes I’ve verified that those emails are in the User table). I need some kind of workaround (e.g. tips on manipulating directly through mysql).

BTW has a schema for the RT3 tables been documented ( similar to the RT2 schema http://fsck.com/rtfm/article.html?id=158 )?

Thanks,
Mike

4

I found a workaround for this situation that I wanted to share.

I have a common problem of trying to transform someone who was
autocreated by submitting an email into a priveleged user.
The typical fix for this is through WebRT is Configuration:Users:Select
Users and check the “include disabled users in search”, search for their
email, and then make them a priveleged user.

However in my build this is broken (RT 3.0.3, Apache2.x, FastCGI, Perl
5.61, RedHat 7.3) and I probably shouldn’t whine too much since I
wandered from the recommended and latest build. :stuck_out_tongue:

Using MySql I looked in the “Users” table to find the “Id” of my
autocreated by email user, in this case user I wanted to update had Id=210.
Upon browsing the “Groups” table I discovered that membership in group
5=unpriveleged and membership in group 4=priveleged.

Now I need to change all of my GroupId=5 to GroupId=4 where MemberId=210
in both the CachedGroupMembers and GroupMembers tables.

Note: look at the tables before running the update, MemberId=210 had
quite a few entries including some type of self-group membership
(GroupId=211).
So only change 5 to 4, for that MemberId, don’t change any other
GroupId’s for that MemberId.

Now that I’ve made this change, I can go to Configuration:Users:Select
and select my user and update them with a password, etc…