We recently installed a fresh RTC 3.0.1 on AIX6 with DB2 9.7, registering applications initiate databases and everything. I could create project and work items after the installation.

Then I used below scripts to migrate the data from my 2.0.0.2 server to 3.0.1 server.

Export RTC data from V2 server:
repotools -export toFile=rtcData.tar

Import RTC data to V3 server:
repotools-ccm -import fromFile=rtcData.tar
repotools-ccm -migration_exportJTSData toFile=jtsData.tar
repotools-jts -migration_importJTSData fromFile=jtsData.tar createMappingFile=rtc-mapping.txt createTables
repotools-ccm -migration_importUserMapping fromMappingFile=rtc-mapping.txt

And after that, since migration destroys the application registering data in the databases, I have to re-register CCM application in JTS. then run Setup a second time, to reregister all applications.

Now I login RTC and see all my projects are imported, but when I try to create work items in the existing project, I got below error message,

"Items with a protected read access policy must use a public context id, a project id, or a current contributor id but the id "_j8mIoDhGEd-7LdFswMKIqg" was used"

I tried create a query to show my imported work items, the query run and show my work items, I can open each work item, but when I try to save the query or modify any work items, I got same Error message

Hi Rachel,

i am not sure what went wrong. It seems to be related to the user migration to the JTS. The preferred option to migrate is to use the upgrade scripts as described here https://jazz.net/library/article/662

Also, I am not sure what happens if you already add users to the JTS database and then migrate the application users over. In your case my wild guess is that you have new users with the same ID already created in the JTS DB and then migrated the old user ID's over. The new user was not overwritten and has a different contributor ID.

I agree with Ralph.

When you look at this document:
http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/t_update_migrate_2nd_rtc.html

It tells you to point the CCM 3.0.1 to your old 2.x DB, and then do the

repotools-ccm -migration_exportJTSData toFile=jtsData.tar

This guide is for an external JTS though.

If you are also upgrading your JTS at the same time, I think you should use:
http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/index.jsp?topic=/com.ibm.jazz.install.doc/topics/t_upgrade_rtc2_auto_scripts.html

Rachel,

I am not sure how to fix it.

I am especially unsure how to get rid of the user that does not work anymore. Archiving would not help because you would not be able to reuse the ID, I believe. You could work with development on it if you create a work item.

My approach would be to do the upgrade again using the upgrade scripts. Avoid running the setup before running the scripts. If you did not migrate into your old RTC DB you would be fine redoing the migration without a restore to your backup, I guess.

I would recreate the new databases in this case, The JTS DB would have to be recreated in any case to get rid of the wrong user mapping.

Hi Ralph

We are using LDAP for user authentication for both 2.0.0.2 and 3.0.1, all the users in JTS DB are synchronized from bluegroups when setup done, they are not manually created. Do you think we don't have to migrate the application users over ?

Sure you have to migrate the users but you do that before the setup so that the users are in JTS already. Because you ran the setup and kept the JTS DB you have your user newly created with a different internal ID and that stayed when you migrated the users from RTC to JTS using the migration script. At least that is what I believe has happened.

If you had followed the interactive upgrade guide you would NOT have run the setup before running the scripts. Essentially you created a new user in JTS with the same external ID but a different internal id and this is blocking you now.

I am not sure how to fix this.

You could archive your user and create a new user for yourself in LDAP (bad idea) or do the migration following the upgrade guide. If you want to test your deployment before running the upgrade scripts, you would have to drop your database before running the upgrade scripts.

Your situation is similar to the Upgrade Workshop in the library https://jazz.net/library/article/662 , so you should read Lab 2 and 3 and also look here: http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/roadmap_clm_upgrade.html

Hi Rachel,

I agree with Ralph that you should have let the upgrade script take care of creating the users in the JTS. Did you register the CCM app when you ran through the JTS setup ?

You usually get a ""Items with a protected read access policy must use a public context id, a project id, or a current contributor id but the id "_j8mIoDhGEd-7LdFswMKIqg" was used" when the import did not run successfully. Can you create a jazz.net work item and attach all the log files for me to look at.

-- Balaji
Jazz Foundation Team

Hi Ralph

We are using LDAP for user authentication for both 2.0.0.2 and 3.0.1, all the users in JTS DB are synchronized from bluegroups when setup done, they are not manually created. Do you think we don't have to migrate the application users over ?

Sure you have to migrate the users but you do that before the setup so that the users are in JTS already. Because you ran the setup and kept the JTS DB you have your user newly created with a different internal ID and that stayed when you migrated the users from RTC to JTS using the migration script. At least that is what I believe has happened.

If you had followed the interactive upgrade guide you would NOT have run the setup before running the scripts. Essentially you created a new user in JTS with the same external ID but a different internal id and this is blocking you now.

I am not sure how to fix this.

You could archive your user and create a new user for yourself in LDAP (bad idea) or do the migration following the upgrade guide. If you want to test your deployment before running the upgrade scripts, you would have to drop your database before running the upgrade scripts.

Your situation is similar to the Upgrade Workshop in the library https://jazz.net/library/article/662 , so you should read Lab 2 and 3 and also look here: http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/roadmap_clm_upgrade.html

I think we may have found the rootcause of this particular error:
https://jazz.net/forums/posting.php?mode=quote&p=62039

I think we may have found the rootcause of this particular error:
https://jazz.net/forums/posting.php?mode=quote&p=62039

Hi, I am not sure that is the case. There might be a way to unblock, not sure, but it might be possible to change the ID of the blocking user following this thread: https://jazz.net/forums/viewtopic.php?t=18762