Hi we have a requirement from a client to make the bulk edit, transition, Resolve issue screen, comment text box to be made mandatory. For single issue this is working fine by adding an 'AJS script' in the 'Comment' Field confuguration description.
For bulk Resolution we have created a below script,
<script>
AJS.toInit(function () {
AJS.$(".form-body #cancel").click(function(e){
window.location.href = 'BulkCancelWizard.jspa'
return true;
}
);
AJS.$(".form-body .aui-button").click(function(e){
var comment=AJS.$("#jira #page #content .aui-page-panel .aui-page-panel-inner .aui-page-panel-content #bulkedit .form-body .aui .comment-input #comment").val();
if(comment==""){
AJS.$(".bulk-affects").html("<br/><div id='resErrror' style='color:red;margin-left:30px'>Comment is mandatory</div>");
return false;
}
});
});
</script>
We have two projects sat A and B. We have put the above script in 'Resolution' Field configuration. Actually we have two 'Resolution' field configuration , both of which looks similar. When we put the script in one of the 'Resolution field of one of them, project 'A', bulk Resolution, comment section become mandatory. When i put in the other one Project 'B's, bulk Resolution, comment section become mandatory. Both the resolution field configuration shows, "shared by 2 projects", which include both of them in concern.
Where is this mapping done. I can put in both of them for local, but in our client's environment, when I put in both also, the comment is not gettiing mandatory for any of the projects.
So where is this mapping between project and Buld Resolution made? Please help me with this as soon as possible. it is already late for us. Thanks.
Javascript in a field description is a terrible way to do this. It will fail in the future, probably needing rewriting every time you upgrade (and eventually it simply won't be processed at all, Atlassian are expected to remove the ability to do it soon, as they have in Cloud), it's unreliable as it won't be run if you don't use that particular route for the action, and REST, automation and scripted actions do not run javascript at all.
I would very strongly recommend that you use a validator in the workflow
Thank you Nic Brough.
I appreciate your suggestion, concerns and points. But at the same time the client wants to get this done without a plugin (I find JIRA applications Suite Utilities add-on) is needed for jira-server.
Probably when they upgrade we will look at this option.
But otherwise with the above suggestion, can you guide us on how to figure out the 'Field Configuration' where we need to put this in order to make the Bulk configuration, Resolution comments mandatory?
What will be the starting point?
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
My original advice remains the same - your javascript simply will not work during bulk-edits, you absolutely need to be doing the validation with validators (bulk edit respects validators, but, rightfully, not javascript)
Your client needs to understand that if they want this validation, they need to get an app to provide it in the right way.
Please do not misunderstand my opinion on validators - I personally think it's the right way to do it, but Atlassian have miserably failed to do what most of us need here. There's a metric shed-load of validators and other workflow functions provided by JMWE, Toolkit, JSU and Scriptrunner that really really should be in Jira off-the-shelf.
Much as I'd like a job with Atlassian (I think), I like that I am free to point out such failures.
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.