I am loading item numbers from a foreign database, into a JIRA custom field. I would like the user to be able to create new values (that match a regex) but that do not collide with existing item numbers, be they loaded from the initial import, or created using the JIRA interface post-import. These item numbers (eg 123456A or 889923BB) need to be unique across all projects (or even better, multiple projects but not all). The numbers could be auto-increment but large swaths of numbers in the 6 digit range have already been used.
Any thoughts on the best practice for doing something like this?
Community moderators have prevented the ability to post new answers.
> but large swaths of numbers in the 6 digit range have already been used
Why don't you just insist on a 7-digit alpanumeric then... for a simple scripted validator it would be something like:
(cfValues["Name of field"] =~ /\d{7}[A-Z]}/).matches()
(untested)
I like the simplicity of the simple scripted validator. {code} (cfValues["Item #"] =~ /\d{6}[A-Z]?/).matches() {code} This does prevent creating issues with an item number that doesn't match 6 numbers and zero or one letters. Would a second simple script validator allow me to disallow the creation of an issue with an Item # that already exists?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
yes but slightly (but not much) more tricky... you need to execute a jql query with the item value and make sure you don't get any hits other than the current issue (potentially).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yep, thats a very quick solution. It'd be nice if I could suggest the next number, but there some arcane and inane business rules that have governed the Item # historically. I'd rather not bother figuring out how to enforce those rules in the system, so the prevention of duplication is good enough for now.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Brian Bishop
I'd say the best way would be to leverage the old built in sequencing value creator and append the sequence value to each custom field value in the field. The call to reference the old sequence api was very simplistic - a single line call worked taking a single string parameter which identified the sequence value.
The table used in the database (JIRA database) is sequence_value_item. If you'd like a bit of example code I'll dig some up and edit this answer - let me know.
-wc
William Crighton
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
ok, perhaps 'best' way is a _bit_ pretentious...must more accurate would be to say 'one way'
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks William, I've gone with a couple of validators to prevent duplication, rather than the more elaborate solution you suggested.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
what exactly is meant by database custom field ?
any field from a plugin ?
Thanks,
Sumit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Sumit, https://marketplace.atlassian.com/plugins/org.deblauwe.jira.plugin.database-values-plugin is one of the plugins i was referring to when I said database custom field. Though that might be a way to implement this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.