In Jira 5, how can I do Javascript validation on the “Quick Edit” edit and create screens?

[CEDRIC ZABEL]

My organization is currently using Jira 4.4, with several plugins designed in-house. One of these plugins implements a specialized custom field. In that plugin, I have some Javascript validation that prevents our users from entering obviously incorrect or incomplete input. Our users are careless and lazy, but they are not malicious, and this Javascript validation has proven itself useful.

We want to move to Jira 5, so we want to update all of our plugins. This Javascript validation, though simple, is giving me problems. It’s not the Javascript or Jquery that’s giving me problems — it’s the AUI part.

For Jira 4.4, I put the Javascript in the “edit” velocity template of the field, so it automatically gets loaded whenever there’s a create or edit screen. The code looks something like this:

<script type="text/javascript">
  function validate_spiffy_field() {    
    var tests_passed = 0;
    // Do a bunch of tests
    if (tests_passed >= 10) {
        return true;
    } else {
        return false;
    }
  }

  jQuery(document).ready(function(){
    jQuery('#issue-edit,#issue-create,form[action="BulkEditDetailsValidation.jspa"]').submit(validate_spiffy_field);
  });     
</script>

The details of all the tests aren’t important, so I’ve omitted them. As you can see, when the form is submitted, it triggers a function that returns true or false. If the function returns false, the form submission event stops bubbling, and the form is not submitted to the server. The user also sees an error message, which I’ve also omitted. (It’s generated as part of the tests.)

Of course, in Jira 5, we now have the “Quick Edit” pages, so my Javascript has to change. Since the Javascript is part of the edit template, it gets loaded as part of the “Quick Edit” load, so I don’t have to change much to get it to run. Here’s what I came up with:

<script type="text/javascript">
  function validate_spiffy_field() {   
    var tests_passed = 0;
    // Do a bunch of tests
    if (tests_passed >= 10) {
        return true;
    } else {
        return false;
    }
  }
 
  jQuery(document).ready(function(){
    jQuery('#issue-edit,#issue-create,form[action="BulkEditDetailsValidation.jspa"],#edit-issue-dialog form.aui[name="jiraform"]').submit(validate_spiffy_field);
  });    
</script>

This code actually runs in the “Quick Edit” edit and create screens. When I hit the “Update” or “Create” button, I can see that the validate_spiffy_field() function gets called and returns false correctly. However, to my horror, I see that the “Update” and “Create” buttons aren’t regular form submit buttons. Instead, when they are clicked, they fire off other functions, and it’s one of these functions that does the actual form submission. Moreover, these functions are called before validate_spiffy_field(), so by the time it figures out that the values do not validate and it returns false, it’s too late to stop the form submission!

How can I get around this? I’m pretty sure there is a way around this, because I think Jamie Echlin’s Behaviours plugin does Javascript validation, and it’s compatible with Jira 5. So there’s some technique I can use, if I could only discover what it is.

[frother · Accepted solution]

Unfortunately there is no good way of doing this at the moment. You can toy with the events data object as Jamie suggested but this is pretty error prone, there is nothing stopping another custom field doing the same and messing it all up.

The code on the JIRA side of things to fix this however is quite simple. I will try my best to have this scheduled in the next bug fix release. I have created a bug so you can track the progress of this issue.

https://jira.atlassian.com/browse/JRA-28241

[CEDRIC ZABEL]

Thanks for creating this bug! The fix will be really helpful in the future.

[JamieA]

there is nothing stopping another custom field doing the same and messing it all up.

I don't really understand that comment... so long as all fields/plugins register their event handler before the submit-form, they all get a chance to prevent submission, which is what we want. I don't think it matters the order that different plugins' handlers fire.

[frother]

I don't really understand that comment... so long as all fields/plugins register their event handler before the submit-form, they all get a chance to prevent submission

Yeah of course if all the fields/plugins register before the submit handler this will work fine. But you are relying on other plugins/fields (unaware of your field/plugin) ordering these events in the correct order. I think a more concrete, future proof solution should be provided by JIRA here.

I have made a fix which will work consistentently across all form implementations, normal forms, dialogs & inline edit. See JRA-28241 for more info. Let me know if you have any problems with the API. This should be available in the upcomming 5.0.6 release.

[JamieA]

I think a more concrete, future proof solution should be provided by JIRA here

I completely agree, thanks for entering the bug and adding the fix.

I'm probably asking for the moon on a stick now, but as well as the above, it would be nice to be able to hook into additional field events, mainly "value changed". This is not necessarily straightforward for date pickers, user pickers, and then custom field types like nFeed etc.

[frother]

Not necessarily straightforward

Agreed! This would be quite a complex task. Would love to supply an api for this but it is not scheduled for now. Is there any particular fields that you are finding it difficult to detect change on? I will try and add a hook next time I am in the area...

[JamieA]

Heh... you also need to worry about the next quantum leap which is inline editing in 5.1, again completely different. Although if you're only validating the contents of a single field, maybe you can make it work.

So you could look at the code for my "solution". As you say, the order that the submit event handlers fire is not right, and it's not easy to prepend your handler to the list.

So you could write your validation in groovy and use the behaviours plugin of course. Or with javascript, I used this technique for ordering the submit events: http://stackoverflow.com/a/4700103/1018918

Quick question... why are you doing this in JS and not server-side... is it because there are no edit validators in jira?

[CEDRIC ZABEL]

The primary reason for doing this in Javascript is as you say: there are no edit validators in Jira. Perhaps this could be done using your Behaviours plugin, but I currently have little experience with it. When I first wrote this plugin, I was completely ignorant of it.

Another reason is that I already do a bunch of things in Javascript for Jira besides input validation. I have Javascript that turns certain formatted strings in some fields into hyperlinks to other tools that we use internally, for example. My users like this. For this particular plugin, I not only validate combinations of fields, but I dynamically show what affect the combinations of fields will have on other computed fields, so my users can adjust the fields if they don’t like the result. Since I was already using Javascript for this purpose, it was only natural to use it for validation as well.

Another reason was that I was worried about people using bulk edits. I was afraid that if I did use some sort of server-side validation (perhaps in the custom field plugin) and some issues in the bulk edits turned out to not validate, and some did validate, the result would be some issues would get updated, some would not, and the error message returned to my users would not provider sufficient detail to my users about what got changed and what didn’t. My users are picky about such things.

I thought it would be better to be more restrictive in the bulk edit input and possibly disallow some safe bulk edits than to risk having a bulk edit go bad. I may be unnecessarily worried about bulk edits, but I didn’t know what to do to reassure myself. (I still don’t.)

Perhaps when 5.1 comes out with all of its changes, I’ll have to revisit this decision. But right now, it looks like I’ve gotten things working for 5.0. Thanks!

[CEDRIC ZABEL]

Yeah, I’ve heard about the inline editing in 5.1. I’m going to cross that bridge when I come to it. (And, in fact, I do validate the combination of contents of multiple fields.)

I took a look at the technique you used, and adapted it for my purposes. Well, I say “adapted,” but really I just changed the name to avoid a conflict and changed the formatting. It worked for me, although for some reason I have to pass the “event” parameter to my validation function, and before the “return false;” I had to add “event.preventDefault(); event.stopImmediatePropagation();” The jQuery docs say I shouldn’t have to do that, but it didn’t work without it.

As to why I did this in JS and not server-side: well, there were several reasons. I’m not saying that any of them were necessarily good reasons, but I had reasons. Perhaps if I started doing this now, I’d do things differently. My knowledge of Jira has increased greatly in the past several months, growing by fits and starts with periods of admiration and frustration.

I’ll explain some of those reasons in my next comment.

[JamieA]

” I had to add “event.preventDefault(); event.stopImmediatePropagation();”

Not sure whether you "should" need that or not, but I have to use that too.

I wasn't really asking why you're not using the behaviours plugin, as that's client-side too in some respects. Some future release of script runner will have edit validators, which is safer, although it's not going to do things on the fly as you can do with js/behaviours.

The problem with using JS is that if you had been doing this since 3.x you would need to already have rewritten the code several times, and now again to deal with inline editing, plus handle separately the case of greenhopper card edit, bulk edit, etc.

[CEDRIC ZABEL]

I’m kind of glad to hear that you needed to add those event method calls as well. If you had to do it, I figure it means I’m not making any obvious mistakes!

I didn’t interpret your question as asking why I wasn’t using the Behaviours plugin. I was definately considering it once I discovered it. (Well, once my teammate introduced it to me.) I’m trying to expand my toolset beyond the hammers I already use, because not everything is a nail. (Even though I’ve got some versitile hammers.)

I do see your point about the problem with using Javascript. This is the first major version jump I’m going through, and it’s more work than I expected.