How can I rollback deletion of a LexoRank field?

[dmitri]

Related to https://answers.atlassian.com/questions/43719532

I think I've determined that all important filters use "Rank" so I want to delete the other two. Would re-inserting the row in the customfield, fieldconfiguration, and configurationcontext tables be sufficient to rollback if needed?

In query form, these rows:

select *
  from configurationcontext cc, fieldconfiguration fc, customfield cf
  where cc.customfield = fc.fieldid
  and fc.fieldid = concat('customfield_', cf.ID)
  and cf.ID = <id to be deleted>

[MattS]

I would treat the deletion of the custom fields as a one-way action. You can recreate them as new custom fields of that type if needed. I don't recommend having more than one Rank field of type Global Rank since it takes more time to build the Lexorank values. I don't recommend keeping any of the older kind of Rank fields either.

[dmitri]

Indeed I think we've made some mistakes that I'm trying to undo by deleting 2 of our 3. I just don't know of a good way to thoroughly test before doing the deletion, hence it would be nice if it were un-doable.

[Nic Brough -Adaptavist-]

No, the issue content goes as well.  I'd take a backup before you do this.

[dmitri]

Do you mean as stored in customfieldvalue or is there another table? It turns out lexoranks have their own table AO_60DB71_LEXORANK and the ranking data itself is not deleted https://jira.atlassian.com/browse/JSW-13098?src=confmacro&_ga=1.80024983.1470128015.1477686267

[Nic Brough -Adaptavist-]

Ah, sorry, I misread it and got the context wrong.  Didn't realise it was the Software ranking field.

No, that does not get cleared, so, in theory, yes, you could replace the custom field entry.  But you'll need to check the field configurations and contexts are added back correctly as well, and, as usual, reindex the whole system.

[dmitri]

Thanks. Added clarification query to the question.

[Nic Brough -Adaptavist-]

That query looks good to me.

I'm not actually sure of the effects on the field config and context because it's not a standard custom field.  I suspect they'll actually be fine, but I'd want to check and test it before relying on my instinct.