|
History
| Log In
|
|
|
|
I think this is a very important!
Because the permission schemes/required fields combination is more or less useless this way. I run into the same problem with de Security Level field (made a separate issue Regards, Ray JIRA does not try to ensure that permission scheme and field 'required' flags don't interact in harmful ways.
However it sounds like what you're really after is the ability to make a field required only for a specific transition, which as Keith says, is something that may be possible in 3.2. Well, that would probably solve a lot of things. And is probably even a
beter solution. Being able to give some person or group rights to perform a transition combined with the ability to set a 'required' for specific fields would be great. I truly hope this will be possible in 3.2, or sooner ofcourse 
BTW: can I throw in our free consultancy hours (with our Enterprise Edition) for this issue?
What is the status and planning at this moment? It would really be very helpfull when fields can be required for certain transitions. And users would probably only need permission to perform a transition...
A customer ahs posted some code
 that will enable this.It is a validator that will stop a transition if a field has not been entered. Some code modifation will be needed to suit specific needs. Cheers, Dear,
I think the best solution is like that I described here JRA-9439. We'll look into the workarounds above but REALLY want to see the "default" behavior for required fields supported on a per screen basis. This gives us uniform behavior across required fields.
Supporting this functionality would address six of the top ten complaints I recieve from those using our new process. It would also allow us to configure our workflows and screens to require fields that we must now populate and maintain by hand. Of all of the issues I have voted for, only JRA-6747 would add more value than this functionality.
I may be duplicating comments, but here is an example.
I want to require that Engineering/Development include a comment about the fix when they resolve an issue. But comments on other transitions may be optional (and are included on the screen for convenience). We are not a shop that is currently in a position to do custom code (or even implement some from others). We are running 3.5 professional. -carl We really need this feature. Currently, I have to build a workflow validator everytime we need certain fields to be required only on certain transitions. It is rather painful because I would also have to modify the workflow for this and then would have to migrate a bunch of projects into the new workflow. Any ETA on when this issue could be addressed?
Here's how we would use it:
We have a 'fix build number' that needs to be filled in when the bug is resolved (either it was fixed, dupe, whatever). We cannot make it required now as someone would have to enter a fix-build number anytime they were editing the issue (create, edit, update). So for now, we have to rely on the user remembering to enter the fix-build-number field when resolving, which as you can expect, doesn't always work. It would be great to have this field required only when resolving an issue. I really hope this gets into a release but considering it has been open well over a year, I have my doubts. Hi,
We realise that this would be useful and are hoping to address this in the future. At the moment I am hesitant to mention an implementation date as I would not like to make any promises we cannot keep. Our main challenge is choosing which features to implement in the next release, given the resource limitation of time and development effort. I am confident, however, that we will get this done. Thanks, I have a similar request: a custom field which should be required in a subsequent step, but not during creation of the issue:
it is not logical that a field is checked for being required, if it is not shown on the screen. the simple solution for my problem would be, that a field not shown on a screen would also not be checked as required field, even if it is set as a required field; it should just be checked in the screen it appears in. Gerhard,
Try looking at the following plugin: The plugin will allow you to specify required fields on each transistion step. We would use this to determine a specific Reporter or Assignee via webservice code, and are really interested in forwarding this issue ...
We would like to encourage the submission of new issues (and risks), so we want to minimize the number of fields required when a new issue is submitted. However, once the issue transitions from "Submitted" to "Open", we want additional fields to be mandatory. For example, we are not making the Impact (=Priority) a required field for the Submitted state, but we need it to be mandatory once the issue is Open.
I'll have a look at the plugin, but I'd like this feature to be implemented in the baseline. We are actually trilalling JIRA and this is the point my evaluation hangs...
As we are not building a new workflow but try to rebuild our proved old one this (missing feature) is actually a no go for my project  An "internal validation" Of settings would be very usefule so one does not have to play trial an error with configurations leading to errors (described as above by others) Michael Well, the plugin:
http://confluence.atlassian.com/display/JIRAEXT/JIRA+Suite+Utilities does not really help much. Although the plugin prevent users from trigging a transition state change on an issue, the plugin fails to inform users that a certain field must be filled out to continue, and in the jira issue page, the operations for changing issue states will not show the particular operation for trigging the state change. Thus users do not understand why they can't e.g. resolve an issue because they are never explicitly told by the system that for instance the 'Estimated time' field must be filled in to continue. Although this could be done by promting screens e.g. by creating your own 'Do Estimates' workflow step and associate a screen to it, this solution does not work either because if you set 'Etimate Time' to required in the 'Field Configurations' then this will apply to all screens, making it impossible not to create an issue without also estimating the time required to solve the issue. This is really bad because usually those who register bugs have no idea how much time is required to fix it. This functionality is really important, I hope Atlassian will put a high priority on this feature (more an improvement if you ask me!). When this is said, I'm very happy with Jira. I am surprised this isn't implemented. For data integrity reasons you want to be sure that certain attributes have values at certain states in the lifecycle of an issue. Please implement this quickly if you can. Thanks!
I'm using the Workflow Validator plugin
successfully in 3.6.5 to achieve this. I just ran into the issue of having a required custom field that was added to a particular screen being required on all screens. This seems like a fundamental, high priority issue that has been around for a long time (several years) and the workaround using a plugin has not always worked as expected. Would someone from Atlassian care to update us on the current status of a code fix?
The existing plugin is a good workaround but not the best solution:
1. 2. Cheers I agree with Bettina on the importance of implementing this in the JIRA source code and the workflow updates.
I am uncertain as to how the JIRA Suite Utilities does not workaround this field transition issue. I agree with Steinar on:
The Field Configuration Screen is best used for only the Creation Screen and not for other fields later on. However, the JIRA Suite Utilities works around this with the Field Required validator I'm the newbie here and would just like to know if Atlassian is actually going to impliment a resolution to this problem anytime soon. The last comment from someone with Atlassian (as far as I can tell) was more than a year and a half ago. We, like many others, are not in a position to impliment custom code (or plugins) and would like to see the fix come from Atlassian.
I'm repeating Art et al. who are asking when Atlassian is fixing this problem. I'm pretty new, but this seems absolutely fundatmental: we want a required field to be completed in a transition screen, not on the creation screen, and the system won't allow it. Our required field is a "resolution summary" that we require the developer to detail the resolution. Currently, we can't require it without having it filled out on the creation screen, and it's not even ON that page, for obvious reasons.
PLEASE--the plugins sound like incomplete workarounds and this issue has been around for a long time for such a fundamental need. Is there a release date for this fix? Thanks!! Hi,
Please accept our apologies for the delay in replying. We are planning to add this feature to JIRA. However we currently do not have a firm implementation date, it will not be part of JIRA 4.0. While technically it is not that difficult to do, it would add more complexity to the already significant complexity of the fields system. This requires us to do some hard thinking about what and how we deliver, as we have a key responsibility to not make the application worse for existing users when we add something new. We recognise the plug-ins for this purpose are not ideal, however, we know a number of our customers in a similar situation are using them to successfully approach the desired result. Until we can get this work delivered the plug-ins are the best workaround to explore. Thanks, Hello Anton [Atlassian],
Is that development such complicated? As a developer, I thought it should be something like: Current behavior is VERY annoying... Thanks, I apologize for adding to the cacophony but I find the comment from Anton quite puzzling and very un-Atlassian like.
The issue is 3 years old And yet the issue cannot get scheduled or assigned. Guys, what's up with that ? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Open
Critical
Make field required only for one state transition
Many thanks for this report - this is a new feature that we are definitely looking at including in a feature release. We are at present re-implementing the field system which shall allow a greater degree of configurability. WIth this in place, it should be simpler to implement the feature you request - but as yet, this has not been scheduled.
Please watch this issue for further updates.
Regards,
Keith