It's all about the answers!

Ask a question

How to resolve "Found more than one contributor with us


Tim Mulligan (22633214) | asked Jul 12 '11, 1:38 p.m.
We are running RTC 2.0.0.2. A couple of days ago we modified an advanced property setting under com.ibm.team.repository.service.internal.ContributorService section, namely: "Use case insensitive user ID matching". The default is 'false'. We changed it to 'true'.
This advanced property setting change resolved a long-standing RTC login annoyance factor but apparently has introduced an unforseen side effect. Let me explain. All of our userids begin with an "a" followed by 6 digits. We refer to this as the "corpid". Many of our RTC end-users have long complained that they are unable to login whenever they enter an uppercase "A" at the RTC login screen. Changing this advanced property resolved that issue but we now have 1 reported user who can not login. He is getting the following error message:
"Could not init workbench. Error fetching initialization data: Found more than one contributor with user id a999999".
Upon closer inspection, we identified four cases of "duplicate" userids in RTC - one with an uppercase "A" and another with lowercase "a". At this point we aren't certain if these "duplicate" userids existed prior to the config change or were caused by the config change. When we tried to archive the userid with the uppercase "A", we received the following error message:
"Error archiving user: Found more than one contributor with userId a999999"
My question is how should we resolve this issue? Should we connect to
the backend Oracle database (directly) and delete the row with the
uppercase "A" from the contributor table?

2 answers



permanent link
Geoffrey Clemm (30.1k33035) | answered Jul 13 '11, 12:07 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
As I recall, you need to disassociate your RTC server from LDAP, at
which point you can edit the user entries directly, and then
re-associate your RTC server with LDAP.

In 3.0.1, I believe this is done by running jts/setup, and stepping
through until you get to the "Setup User Registry", and select "Non-LDAP
External Registry". Make your changes to the registered names (change
them to some non-conflicting name if it won't let you delete them), and
then use jts/setup to set it back to "LDAP".

It's been a while since I've used 2.0.0.2, so you might want to get
support on the phone to confirm this is (a) correct (:-), and (b) the
way it is done in 2.0.0.2.

Cheers,
Geoff

On 7/12/2011 1:53 PM, timothy.mulligan wrote:
We are running RTC 2.0.0.2. A couple of days ago we modified an
advanced property setting under
com.ibm.team.repository.service.internal.ContributorService section,
namely: "Use case insensitive user ID matching". The
default is 'false'. We changed it to 'true'.
This advanced property setting change resolved a long-standing RTC
login annoyance factor but apparently has introduced an unforseen
side effect. Let me explain. All of our userids begin with an
"a" followed by 6 digits. We refer to this as the
"corpid". Many of our RTC end-users have long complained
that they are unable to login whenever they enter an uppercase
"A" at the RTC login screen. Changing this advanced
property resolved that issue but now we are seeing
"duplicate" userids (in RTC) for 4 people (so far). One
userid with an uppercase "A" and the other with a lowercase
"a". And now when one of these 4 people attempts to login to
RTC, he is getting the following error message: "Could not init
workbench. Error fetching initialization data: Found more than one
contributor with user id a999999". So we tried to archive the
userid with the uppercase "A" (most recently created) but
received the following error message:

"Error archiving user: Found more than one contributor with
userId a999999"
My question is how should we resolve this issue? Should we connect to

the backend Oracle database (directly) and delete the row with the

uppercase "A" from the contributor table?

permanent link
Tim Mulligan (22633214) | answered Jul 13 '11, 12:34 p.m.
Hi Geoff,

Thank you for the summation. Your memory is good! Earlier today we actually found the exact relevant tech note for 2.0.0.2 which describes the situation at hand and the solution perfectly. Here is link:

https://www-304.ibm.com/support/docview.wss?lang=all&cc=us&rs=0&q3=user&q2=ldap&loc=en_US&cs=utf-8&uid=swg21417670&q1=jazz

We already tested out this procedure in our "Production Mirror" environment and it worked beautifully. We are planning to execute the same procedure in our production environment tonight (after hours). The fix is simple. No risk. No bounce of RTC will be necessary. And we can retain our recent advanced property config change ("Use case insensitive user ID matching" set to true).

It should also be noted that we determined the four 'duplicate' userids (those that began with uppercase "A") in fact existed prior to us applying the config change (case insensitivity = true). The config change actually EXPOSED the issue and did not cause the issue. It then became a matter of determining how best to deal with the four 'duplicate' userids. We have every intention to keep our confi change in effect going forward.

-Tim



As I recall, you need to disassociate your RTC server from LDAP, at
which point you can edit the user entries directly, and then
re-associate your RTC server with LDAP.

In 3.0.1, I believe this is done by running jts/setup, and stepping
through until you get to the "Setup User Registry", and select "Non-LDAP
External Registry". Make your changes to the registered names (change
them to some non-conflicting name if it won't let you delete them), and
then use jts/setup to set it back to "LDAP".

It's been a while since I've used 2.0.0.2, so you might want to get
support on the phone to confirm this is (a) correct (:-), and (b) the
way it is done in 2.0.0.2.

Cheers,
Geoff

On 7/12/2011 1:53 PM, timothy.mulligan wrote:
We are running RTC 2.0.0.2. A couple of days ago we modified an
advanced property setting under
com.ibm.team.repository.service.internal.ContributorService section,
namely: "Use case insensitive user ID matching". The
default is 'false'. We changed it to 'true'.
This advanced property setting change resolved a long-standing RTC
login annoyance factor but apparently has introduced an unforseen
side effect. Let me explain. All of our userids begin with an
"a" followed by 6 digits. We refer to this as the
"corpid". Many of our RTC end-users have long complained
that they are unable to login whenever they enter an uppercase
"A" at the RTC login screen. Changing this advanced
property resolved that issue but now we are seeing
"duplicate" userids (in RTC) for 4 people (so far). One
userid with an uppercase "A" and the other with a lowercase
"a". And now when one of these 4 people attempts to login to
RTC, he is getting the following error message: "Could not init
workbench. Error fetching initialization data: Found more than one
contributor with user id a999999". So we tried to archive the
userid with the uppercase "A" (most recently created) but
received the following error message:

"Error archiving user: Found more than one contributor with
userId a999999"
My question is how should we resolve this issue? Should we connect to

the backend Oracle database (directly) and delete the row with the

uppercase "A" from the contributor table?

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.