Details
-
Bug
-
Resolution: Unresolved
-
Low
-
None
-
5.1.5, 5.2.5, 5.3.4, 5.4.4
-
JIRA 6.1.9, Confluence 5.3.4 (was also tested with JIRA 6.0.8 and Confluence 5.1.5+5.2.5)
-
Severity 3 - Minor
-
Description
Creating this issue as per the outcome of a lengthy support inquiry.
Steps to reproduce:
1. Go to admin/do-force-upgrade.action
2. Select jiraIssueMacroServerParamsUpgradeTask
3. Click on "Force Upgrade"
4. Check-out the Confluence log file
Actual result:
The front-end shows "Upgrade succeeded. Check the log for details.". The log reports success, but also contains a bunch of failure notes (see full log attachment) like:
2015-08-12 11:51:09,477 INFO [jira-issue-macro-migration:thread-1] [xhtml.migration.macro.JiraIssueMacroServerParamsMigrator] processParams Failed to update JIRA issue macro: the macro params did not define a server name
and the summary reports:
85 JIRA Issue macro(s) could not be updated
Expected result:
The front-end shows "Upgrade succeeded. Check the log for details." and the log reporting no failures to update any issue macro.
It turns out that in-fact all of the relevant entries in the DB are correctly migrated and contain the proper serverID-parameter.
Running the following query on the DB shows no longer any matches after running the upgrade task:
SELECT *
FROM (SELECT * FROM bodycontent where body like '%<ac:structured-macro ac:name="jira">%') AS sb
WHERE body not like '%<ac:parameter ac:name="serverId">%'
and contentid in (SELECT contentid FROM CONTENT WHERE CONTENTTYPE = 'PAGE' AND PREVVER IS NULL);
My suspicion would be that the log report simply glitches with old entries in the DB which are not touched intentionally by the upgrade process. Namely these entries would be:
- from pages which were removed
- older versions of a page
Both of these don't get their entries updated by the upgrade task (as I've been told by support this is intentional) and doesn't cause any problem (of course up until u try to restore that old page/version, but that's known behavior of Confluence and by design as far as I'm aware).
Could it be that the log simply does report these entries (incorrectly)? If so, I guess the bug would be that these matches are still reported in the log and counted into the statistics, which they should not.
Attachments
Issue Links
- relates to
-
CONFSERVER-25329 Renaming Application Links cause rendering problem: "Couldnt find an application link with the name {0}."
- Closed