How to resolve "Found more than one contributor with us
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
|
Hi Geoff,
Thank you for the summation. Your memory is good! Earlier today we actually found the 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 We are running RTC 2.0.0.2. A couple of days ago we modified an |
Geoffrey Clemm (30.1k●3●30●35)
| 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 |
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.