Yesterday I upgraded Jira from 6.0.4 to 6.0.6., and for some reason there was a corruption in the DB. If I enter in Jira to see the custom fields, most of them are gone. Also the basic custom fields types (like multicheckboxes) are gone. I can only see the custom fields that have a custom field type (like 'Colour of Epic' from Jira Agile plugin).
I checked in the DB itself and indeed the custom fields are there, I didn't manage to find any obvious problem in the DB. I searched in the logs and found something like this:
2013-08-29 01:30:18,465 TP-Processor10 ERROR agonzale 90x2350x1 1rpaxf5 137.XX.XX.XX /secure/admin/ViewCustomFields.jspa [jira.issue.managers.DefaultCustomFieldManager] Could not load custom field type plugin with key 'com.atlassian.jira.plugin.system.customfieldtypes:multicheckboxes'. Is the plugin present and enabled?
The strange thing is that if I repeat the migration from an old copy of Jira in our developer instance, that has the same code as the production ijnstance, it works just fine. I tried to load several XML backups of JIRA from different points in time and it is very consistent: before migration backups work but after migration backups don't. So I am 95% sure it is not the code or any other file in the file system.
I hope there is a mising magic entry in the DB that I can change to load the com.atlassian.jira.plugin.system.customfieldtypes plugin or something like this.
I found the answer.
The trees didn't let me see the forest. The problem was not a corrupted DB at all. The problem was that the migration process disabled the customfieldtypes plugin. So when I went to the Add-ons page, select system plugins and enble the customfieldtypes plugin, everything started to work fine.
I am sorry for the noise, my bad, but if I can do a recomendation for the integrity checker: "It is mislesading that the integrity check says that the custom field doesn't exist, it should take into account the customfieldtype issue and perhaps even activate it or offer that solution to the user".
Anyway thank you very much for your help.
Hey there, Alvaro.
Can you try to perform the following steps to see if it can help to retrieve the custom fields that were missing? As you mentioned, the database corruption might have caused this issue to occur. So, let's see if these steps can help:
Give it a try and share the outcome here. Good luck!
Thank you for your answer. But the problem with that is that I get quite a lot of ERROR lines like this:
ERROR: The field layout item with id 12607 has a reference to the deleted custom field with id customfield_10614. (JRA-4423)
I can click in 'Fix', but that will remove the information in the issues regarding the custom fields, isn't it? So I will lose that information, and this is the opositte of what I want.
Hey there, Alvaro.
You are welcome. So, we can confirm that there are some inconsistency in your database. Since the custom field is already deleted from the instance, it should not cause any issues as far as I am concerned. Just to be safe, you can also perform an XML backup first before proceeding with the steps.
I am doing the test in a copy of the production instance. I will let you know. Anyway I am not convinced that this is the answer. My concerns are:
I can not even create new custom fields with the standard custom field types (like datepicker) and I don't see how this solution will fix that.
Also I can see in the customfields table in DB the supposedly deleted custom fields.
Hey there, Alvaro.
Thank you for the clarification. However, we need to ensure that the database is in the consistent state first before proceeding with the rest of the steps. Since you are performinig this on a copy of your production instance, we hope that it will help. Let me know how it goes for you.
Just few logs that I they can have something to do with the problem:
jira.option.rpc.allow : true
jira.option.timetracking : true
jira.option.user.crowd.allow.rename : false
jira.option.user.externalmanagement : false
jira.option.voting : true
jira.option.watching : true
jira.option.web.usegzip : false
jira.path.attachments : /var/jira-home/data/attachments
jira.path.attachments.use.default.directory : true
jira.path.backup : /var/jira-home/export
jira.path.index.use.default.directory : true
jira.plugin.state-.com.atlassian.jira.plugin.system.customfieldtypes : false
jira.plugin.state-.com.atlassian.jira.plugin.system.renderers.wiki.macros:code : false
jira.plugin.state-.com.atlassian.jira.plugin.system.renderers.wiki.macros:noformat : false
jira.plugin.state-.com.atlassian.jira.welcome.jira-welcome-plugin:show-whats-new-flag : true
jira.plugin.state-.com.atlassian.jira.whatsnew.jira-whatsnew-plugin:show-whats-new-flag : true
jira.project.summary.max.issues : 3
jira.projectkey.description : admin.projects.key.description
jira.projectkey.maxlength : 10
jira.projectkey.pattern : ([A-Z][A-Z]+)
jira.projectkey.reservedwords.list : PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, CON, LPT1,
LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9
jira.projectkey.warning : admin.errors.must.specify.unique.project.key
jira.projectname.maxlength : 80
jira.releasenotes.default : Html
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs