|
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 Shouldn't the Component be "Workflow" ??
John illustrates our use-case exactly.
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 ? Have to agree that the current behaviour is weird and irritating. A required custom field I added to the resolving screen stopped everyone from logging tasks, as the field wasn't visible on the issue creation screen and couldn't be filled.
Guys I can't believe this one has been around for so long and hasn't been addressed properly (I was sent a workaround). This is a fundamental problem which makes the whole "Field Configurations/Field Configuration Scheme/Custom Screens" function severely lacking (if not useless)! Please fix asap.
Here's a variation on this that I don't think anyone's mentioned. It's stopping us right now.
--Need 2 screens in a project, one for each issue type Using validators won't help. It's not a question of when the field is required in a workflow (although that's a good issue, too). Some fields aren't relevant for different issue types. I'm wondering if we've overlooked something in front of our noses because it seems like a very obvious requirement for required fields. Currently, if you have mutliple screens, you can't have required fields except for very basic fields like "Reporter" that might be needed on every screen. We're stumped. Please tell me there's a fix for this. Bob - I might be wrong, but I think JIRA does handle that. A field configuration scheme is used to define which field configuration is used for which issue type. Each field configuration can have a different set of required fields. Hence, for the same project, different issue types could have different required fields. At least that's how I understand the documentation.
Neal--Thanks. Actually, this weekend I started wondering if setting the "context" might be the solution. We use contexts between diff. PROJECTS so we can reuse fields, but I was wondering if I could use diff. contexts within one project, since you associate by issue type. SO.......I'm going to give this a try. Thanks for your brainpower. I'll follow up and let you know how it turns out.
The other idea my coworker suggested was to prepopulate the required fields. They would see a little irrelevant to our users who didn't need to fill them in, but we could probably make it work. But the context idea is the first/better method. On Mon, Jun 2, 2008 at 3:07 PM, Bob Zasuly (JIRA) <jira@atlassian.com>
– After thinking about this further (I misunderstood Neal), there might be 2 ways about this: Neal's suggestion of creating a separate configuration in the scheme for the two diff. issue types; and creating a second context based on the issue types. I'm not sure which is better, if any, but without having tried either right now they both SEEM like options.
Hi All,
Kaamelot provides a solution for this Issue. The feature will be available since 3.10.1.30 and 3.12.1.30. Vincent Hello,
when is this feature going to be implemented? we´d love to see this in the next version. it´s a mandatory requirement for us. Thanks!! Markus Required Fields That Are Not Included On a Screen Are Treated As Required: This issue makes it impossible to require a field on other screens, when the field is not needed or relevant at Creation of an issue. If the field the custom field is not part of the Create screen, it should not be required on the screen. I noticed the error message requiring the field, does not happen for a similar scenario with the Edit screen. My work around for now is to make the field Not Required. Unfortunately, this results in uses sometimes not updating the field.
Abwesenheitsnotiz:
Vielen Dank für Ihre Mitteilung. Momentan bin ich abwesend. Ich bin ab 11.08.2008 wieder für Sie da. Ihre Mail wird nicht automatisch weitergeleitet. Falls Ihr Anliegen vorher Aufmerksamkeit erfordert, wenden Sie sich bitte an +41 41 727 2131 oder support@systransis.ch Notice of absence: Thank very much you for your inquiry. At the moment I am away from my desk and my e-mail. I will be back on 11 August 2008. Your e-mail will NOT be forwarded automatically. Should you need to contact someone before this date, please call +41 41 727 2131 or send a message to support@systransis.ch Any Update?
We really need this!! My users need it too.
Thank Catherine |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
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