-
Bug
-
Resolution: Fixed
-
Highest
-
None
-
3.3.1
-
260
-
Severity 2 - Major
-
220
-
Description of Problem:
JIRA Server instances that have had JSD in the past may have trouble installing JSD 3.2+ if they ever had JSD in the past and did not go through JSD 3.0/3.1 to complete the necessary upgrade tasks.
Or, they might be able to install JSD 3.2+, but they won't be able to create any new Service Desk Project, and will see the following error in the logs:
2019-01-29 02:14:05,217 JIRA-Bootstrap ERROR [bootstrap.lifecycle.server.ServerPluginLifeCycle] '2.0.2' version of Service Desk cannot be upgraded to '3.9.2-REL-0010'. Upgrade to '3.0.0' <= <version> < '3.2.0' first. com.atlassian.servicedesk.bootstrap.lifecycle.server.UnsatisfiedVersionRequirementException: '2.0.2' version of Service Desk cannot be upgraded to '3.9.2-REL-0010'. Upgrade to '3.0.0' <= <version> < '3.2.0' first. at com.atlassian.servicedesk.bootstrap.lifecycle.server.UpgradeRequirementsChecker.checkVersionRequirementForUpgrade(UpgradeRequirementsChecker.java:47)
In some cases JSD data is unwanted and can be deleted. For example when JSD was previously installed as a trial.
Suggestion
Add a supported method for removing all JSD data from the instance.
Use case and suggestion:
- Customer upgrading from JSD 2.5.9 or under and does not wish to keep any JSD data (JSD was a trial, or any other reason)
- If desired, customer is able to remove all JSD data so that they can install JSD anytime in the future
- Customer who is currently running JIRA 7.2 and up and is trying to install JSD. Unbeknownst to the customer JSD was installed in earlier version and 3.0/3.1 upgrade tasks were not completed.
- Customer is able to drop all JSD data so that they can install JSD without having to attempt downgrade.
Suggesting adding a startup flag that tells JSD to drop all JSD data
Workaround
We have documented a method for deleting data from old Jira Service Desk versions (3.2 and below) to unblock upgrades to modern versions.
If you’re using one of the earlier versions of Jira Service Desk (3.2 or below), some data might be incompatible and can block you from upgrading to the latest version or migrating to Jira Service Management Cloud. This often happens when an instance is upgraded without going through versions 3.0 and 3.1, which run important upgrade tasks.
Please follow the steps on the documentation to manually remove the Jira Service Desk add-on, related directories, and other incompatible data.
- causes
-
JSDSERVER-4239 As a JIRA Service Desk administrator, I would like to be able to upgrade from JSD 2.5.9 to 3.2 directly
- Closed
- is related to
-
-
- Closed
-
-
- Closed
-
- Gathering Interest
-
SSE-360 You do not have permission to view this issue
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
- Closed
-
- Closed
- blocks
-
SDS-42681 Loading...
- is cloned by
-
- mentioned in
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- was cloned as
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-4732] Unable to install JSM if data exists from version prior to 3.2 upgrade steps
We are having this problem at the end of 2020, and I can see it exists at least since 2017. We can't install JSD (or we do, but it doesn't have any effect), because a few years ago someone installed and uninstalled an old version. Pretty critical bug I would say...
Building off David Yu above, the below SQL Server 2014 script worked on a Jira 7.6 to Jira 7.10 and Jira SD 3.13 upgrade. I'm not sure what residual Service Desk version caused the issue for me, it was an inadvertent install or possibly a remnant from the Cloud version we migrated to Server a few years back.
Change "jiraschema" to your schema name!
IF OBJECT_ID('jiraschema.AO_54307E_CAPABILITY', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_CAPABILITY IF OBJECT_ID('jiraschema.AO_54307E_CONFLUENCEKBENABLED', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_CONFLUENCEKBENABLED IF OBJECT_ID('jiraschema.AO_54307E_CONFLUENCEKBLABELS', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_CONFLUENCEKBLABELS IF OBJECT_ID('jiraschema.AO_54307E_CONFLUENCEKB', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_CONFLUENCEKB IF OBJECT_ID('jiraschema.AO_54307E_EMAILSETTINGS', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_EMAILSETTINGS IF OBJECT_ID('jiraschema.AO_54307E_GOAL', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_GOAL IF OBJECT_ID('jiraschema.AO_54307E_GROUPTOREQUESTTYPE', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_GROUPTOREQUESTTYPE IF OBJECT_ID('jiraschema.AO_54307E_IMAGES', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_IMAGES IF OBJECT_ID('jiraschema.AO_54307E_METRICCONDITION', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_METRICCONDITION IF OBJECT_ID('jiraschema.AO_54307E_QUEUECOLUMN', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_QUEUECOLUMN IF OBJECT_ID('jiraschema.AO_54307E_SERIES', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_SERIES IF OBJECT_ID('jiraschema.AO_54307E_STATUSMAPPING', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_STATUSMAPPING IF OBJECT_ID('jiraschema.AO_54307E_TIMEMETRIC', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_TIMEMETRIC IF OBJECT_ID('jiraschema.AO_54307E_VIEWPORTFIELDVALUE', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_VIEWPORTFIELDVALUE IF OBJECT_ID('jiraschema.AO_54307E_VIEWPORTFIELD', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_VIEWPORTFIELD IF OBJECT_ID('jiraschema.AO_54307E_VIEWPORTFORM', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_VIEWPORTFORM IF OBJECT_ID('jiraschema.AO_9B2E3B_EXEC_RULE_MSG_ITEM', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_EXEC_RULE_MSG_ITEM IF OBJECT_ID('jiraschema.AO_9B2E3B_IF_COND_CONF_DATA', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_IF_COND_CONF_DATA IF OBJECT_ID('jiraschema.AO_9B2E3B_IF_COND_EXECUTION', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_IF_COND_EXECUTION IF OBJECT_ID('jiraschema.AO_9B2E3B_IF_CONDITION_CONFIG', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_IF_CONDITION_CONFIG IF OBJECT_ID('jiraschema.AO_9B2E3B_IF_EXECUTION', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_IF_EXECUTION IF OBJECT_ID('jiraschema.AO_9B2E3B_PROJECT_USER_CONTEXT', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_PROJECT_USER_CONTEXT IF OBJECT_ID('jiraschema.AO_9B2E3B_RSETREV_PROJ_CONTEXT', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_RSETREV_PROJ_CONTEXT IF OBJECT_ID('jiraschema.AO_9B2E3B_RSETREV_USER_CONTEXT', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_RSETREV_USER_CONTEXT IF OBJECT_ID('jiraschema.AO_9B2E3B_THEN_ACT_CONF_DATA', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_THEN_ACT_CONF_DATA IF OBJECT_ID('jiraschema.AO_9B2E3B_THEN_ACT_EXECUTION', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_THEN_ACT_EXECUTION IF OBJECT_ID('jiraschema.AO_9B2E3B_THEN_EXECUTION', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_THEN_EXECUTION IF OBJECT_ID('jiraschema.AO_9B2E3B_THEN_ACTION_CONFIG', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_THEN_ACTION_CONFIG IF OBJECT_ID('jiraschema.AO_9B2E3B_WHEN_HAND_CONF_DATA', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_WHEN_HAND_CONF_DATA IF OBJECT_ID('jiraschema.AO_9B2E3B_WHEN_HANDLER_CONFIG', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_WHEN_HANDLER_CONFIG IF OBJECT_ID('jiraschema.AO_54307E_GROUP', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_GROUP IF OBJECT_ID('jiraschema.AO_54307E_QUEUE', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_QUEUE IF OBJECT_ID('jiraschema.AO_54307E_REPORT', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_REPORT IF OBJECT_ID('jiraschema.AO_54307E_SERVICEDESK', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_SERVICEDESK IF OBJECT_ID('jiraschema.AO_9B2E3B_IF_THEN', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_IF_THEN IF OBJECT_ID('jiraschema.AO_9B2E3B_IF_THEN_EXECUTION', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_IF_THEN_EXECUTION IF OBJECT_ID('jiraschema.AO_9B2E3B_RULE', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_RULE IF OBJECT_ID('jiraschema.AO_9B2E3B_RULESET_REVISION', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_RULESET_REVISION IF OBJECT_ID('jiraschema.AO_9B2E3B_RULE_EXECUTION', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_RULE_EXECUTION IF OBJECT_ID('jiraschema.AO_9B2E3B_RULESET', 'U') IS NOT NULL DROP TABLE jiraschema.AO_9B2E3B_RULESET IF OBJECT_ID('jiraschema.AO_54307E_VIEWPORT', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_VIEWPORT IF OBJECT_ID('jiraschema.AO_54307E_CUSTOMTHEME', 'U') IS NOT NULL DROP TABLE jiraschema.AO_54307E_CUSTOMTHEME
You'll also need to run the table cleanup as specified in this post: https://community.atlassian.com/t5/Jira-Service-Desk-questions/Jira-Service-Desk-unable-to-create-project/qaq-p/740346
--Queries to delete Service Desk upgrade history: delete from jiraschema.propertytext where id in (select id from jiraschema.propertyentry where entity_name like 'com.atlassian.servicedesk%' and propertytype='6') delete from jiraschema.propertyentry where entity_name like 'com.atlassian.servicedesk%' and propertytype='6' DELETE FROM jiraschema.pluginstate where pluginkey like 'com.atlassian.jira%' OR pluginkey like 'com.atlassian.servicedesk%'
Gergory, several ways. On a new test Jira instance, turn on DB query logging on your database, and then install JSD (the version you installed in the past). You can also turn on SQL logging on Jira itself. This should produce a list of all DB writes it performs during an installation.
Guys, where did you get all table names? I wanted to double-check that it removes everything that JSD added, but I can't find documentation on its schema.
Can you document what were the steps you followed to carry out the change? Maybe I can see if you did something different to us. We had to take the app offline and run the SQL commands a few times to make sure all the tables were actually removed.
Hi, we tried this but things like raise a request and the JSD project portal page is blank.
Just to let others know, the above SQL worked in our V7.3.7 Core/Software instance.
I followed steps posted on June 2nd by Karl-König Königsson and it allowed me to successfully reinstall Service Desk. There was only one table that couldn't be removed due to foreign constraints (AO_54307E_SERVICEDESK), but that didn't bother the newly installed SD.
Good point, Huw Evans, I've been surprised by magically appearing fields when installing some plugins, to find out that that plugin was installed moons ago. I think there should be an option to uninstall plugin and clean all associated data (with triple warnings)
JIRA is sold as an enterprise level tool. I'd expect the removal of a plugin/addon/application or whatever it's called this month to remove all of the smell it installs and not leave behind a pile of booby traps waiting for us poor admins to find later.
This is applicable to lots of addons available in the marketplace though, so it's not just an Atlassian problem.
Hi everyone,
Thank you for your interest in this issue.
We have documented a method for deleting data from old Jira Service Desk versions (3.2 and below) to unblock upgrades to modern versions.
If you’re using one of the earlier versions of Jira Service Desk (3.2 or below), some data might be incompatible and can block you from upgrading to the latest version or migrating to Jira Service Management Cloud. This often happens when an instance is upgraded without going through versions 3.0 and 3.1, which run important upgrade tasks.
Please follow the steps on the documentation to manually remove the Jira Service Desk add-on, related directories, and other incompatible data.
Kind regards,
Jira Service Management, Server & Data Center