Hi All
I am sure a lot of you would have migrated from Clearquest to JIRA. I have been thinking of an equivalent solution of Clearquest's Stateless record types in JIRA - This is inclusive of any plugin features (not just native jira), but I haven't found an exact match yet. Appreciate all help.
For those who don't know CQ - Stateless record types are kind of lookup tables in which we can store table like info. The only difference from a regular issue type is that it does not have any status transitions applicable to it. What is so special about it then? We can use these lookup tables to a lot of good benefit in CQ via its scripting (or hooks as it is called there).
Potential solutions or workarounds and related caveats
1) Create separate issue types for each stateless record - Trouble is JIRA Admin page of these will look messy. We have atleast a 100 stateless records in CQ in one instance.
2) Create external tables to store all of these and use some plugin features to pull in data in JIRA scripting as needed - Trouble is we lose CQ's feature to allow users to enter, edit & query data on these (just like other issue types).
Really wondering how many migrations from CQ to JIRA have gone by without a straight forward solution to this. Let's see if we get the right answer.
Cheers
Satish
You could check whether Insight objects can be used to model stateless records.
Those are not issues, therefore will not pollute your issue data, but can be associated with issues via flexible custom fields.
Hi Aron, thanks for the suggestion. Yes, I have used Insight & its so far the closest bet. However, there is one missing feature - Ability to look up Insight object info from the scripting world directly. I managed to work around this a bit using REST API of Insight, but a direct connection would be great - Two major scripting plugins used so far in JIRA are Power scripts for JIRA (Which we use) and Scriptrunner.
I say this, because in Clearquest, this is all possible just using its Perl/VB hooks. Insight does provide some custom field options (like a dependent insight choice list field for example), but in reality (for a big migration from CQ) we need all the flexibility from an admin perspective. Practical use cases include looking up an insight object & setting another insight object custom field from SIL scripts.
Also, Insight may be a heavy solution for this (Given all its Asset management capabilities), but given that there is nothing else at the moment, it should be ok.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Insight supports groovy, also with its own script console.
See javadoc here https://documentation.riada.se/insight/latest/insight-for-developers/insight-app-development/javadoc
Some groovy examples: https://documentation.riada.se/insight/latest/insight-for-developers/groovy-scripting
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Satish, as Rickard wrote you write Groovy scripts against the Insight API.
We use that technique with great success in our apps:
We experienced some performance problems with a massive number of Insight objects and attributes but functionwise their API is definitely working.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
For sure you should use Insight for this!
As Aron says its a very flexible App that can model your stateless records in objects with attributes, stored separated from Issue but associated through custom fields.
Insight also let's you add and modify objects without the requirement to be an Jira Administrator!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Rickard, I agree, but there is at least one missing capability - Check out my reply to Aron above.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Although it may not be entirely in Insight's domain, from a migration perspective, admins would need what I mentioned :-).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.