Users appear deleted after upgrading to Fisheye 2.7.X
This workaround was tested by Atlassian on Fisheye/Crucible versions 2.7.X only. We cannot provide support if the scripts are executed on other versions.
症状
次のいずれかを実行します。
- Users cannot login, or
- In Crucible, users see a "shadow" version of themselves on old/existing reviews, but can interact with newly created reviews normally
原因
Upgrading Asynchronously
Fisheye 2.7 migrated the storage of some user data from FISHEYE_INST into your SQL database. Therefore, upgrading to 2.7.X requires that all data be upgraded at the same time (your SQL database can't be upgraded before or after the other data in your FISHEYE_INST directory). If you "test" your upgrade using a new instance with your production SQL database, your SQL database will be upgraded automatically at server startup using an empty/incorrect FISHEYE_INST folder, and bad user values will be inserted, causing your users to appear "deleted".
Bad connection to external authentication
When there is an error during synchronization with an external authenticator, Fisheye will consider the user being synchronized NOT to have access to Fisheye, and will deactivate/delete the user in the database. An inconsistent connection to your authentication provider is a sufficient error to cause the deletion. This issue is being tracked here:
FE-3787 - 課題詳細を取得中... ステータス
And here:
FE-3961 - 課題詳細を取得中... ステータス
It is recommended that you temporarily turn off user synchronization until upgrading to a version of Fisheye that contains the fix.
ソリューション
Preferred solution
Restore your data from a clean backup.
代替手段
Run the SQL scripts (postgresql, sqlserver, mysql, oracle) for your database to get your database back into a working state. These scripts may need customization for your particular usage. If there are no scripts for your database, please open a Support case.
- Create a backup of Fisheye
- Shutdown Fisheye
- Run the following scripts, in order. NOTE: Knowledge of SQL is required. You should read the in-script instructions and will need to modify the scripts before running them.
- mergeback.sql - If you are seeing "shadow" users, this means that new users were created on top of the old users. Running mergeback will fold the newly created users back into the original "deleted" user. Specifically, it will merge the data for the user WITHOUT _old<#> into the user WITH _old<#>. NOTE: if you have reused a username of an old user for a new, different user, this script will still attempt to merge them together. You will have to add your own exception clause to avoid those users being merged.
- ldapify.sql- This script will allow you to switch a user to LDAP authentication. By modifying the "2" constant, you can switch to other authentication types instead:
- Built-in: 1
- LDAP: 2
- Host-based: 3
- Custom: 4
- AJP: 5
- Crowd/JIRA: 6
- undelete.sql - Finally, your users are in a state where they can be reenabled safely. Run this script to enable any deleted users. Specifically, it will rename the _old<#> user back to its previous name. Note there are 2 different queries in this scipt. One you must edit to manually undelete each user individually by "username" and another – commented out – query which will undelete ALL users with _old<#> in the username.
- Start up Fisheye and verify that your users are restored correctly.
Run the following query on your database and note how many increments of "_old<#>" users are present so that you know how many times you need to run the merge-undelete scripts over your database
SELECT cru_user_name FROM cru_user;To clean up your database, you will have to complete the process once for _old1 users, then again for any other user, e.g. _old2, and then for any remaining users, e.g. _old3 through _old<#> respectively. To modify the queries to merge the _old2 through _old<#> users, please change this line:
where old_user.cru_user_name like '%_old1';... incrementing the _old<#> number each time, e.g.
where old_user.cru_user_name like '%_old2';In the undelete script, change this line:
when cru_user_name like '%_old1'Finally, be aware that you will need to run the merge script immediately followed by the undelete script for each increment of _old<#>. If you attempt to merge multiple times before undeleting, your subsequent merges will fail because they won't find the users to merge with.