Anton Mazkovoi [Atlassian] - 03/Oct/07 09:47 PM Dominick, It is not possinle to have conditions and functions on a step as the OSWorkflow Engine does not allow this. I believe you are after the ability to set a field to required for certain statuses. This is related JRA-5783, but different, as you would like to protect the requirebility of the field even after the transition is performed, i.e. such that when the issue is Edited in a status the field stays required. I will change the summary of this issue to reflect this and will leave this issue open. However, adding this functionality would increase the complexity of JIRA, and this is something that we would like to avoid. Therefore, at the moment I cannot promise the delivery of this feature. I think the reuse of conditions and post functions can be achieved by JRA-6975. Please vote for JRA-6975. Please let me know if I have misunderstood what you were saying. Cheers, Anton

Dominick Moré - 04/Oct/07 04:56 AM I believe that the reporter of Issue JRA-5783 has a similiar intention as I do but the dicussion drifted off topic and wound up trying to solving this problem with State Transition Validators. MY ISSUE DOES NOT HAVE TO DO WITH STATE TRANSITION VALIDATION... My argument of putting the Conditions and Validators in the "Step" instead of the "Step Transition" attempts to demonstrate a way to solve this problem. First it allows you to reduce redundency and secondly it allows you to customize "Step Transitions" as well as "Standard Actions" (i.e. A Condition that requires a particular project Role could prevent certain users from creating certain Issue types or a Validator on Status "In Progress" could insure that all "Transitions" leading to state development require a "Fix Version" as well as when editing the Issue in status "In Progress" ) The reuse of validators and conditions in Issue JRA-6975 is therefore only a side effect of this kind of implementation. Basically I need a solution for handling the field requiredness in a "built-in" action (i.e. Edit, Bulk Edit). As I see it, the field requiredness/modiability is architecturally coupled with the screen layout and the permissions manager. Ultimately the class com.atlassian.jira.issue.fields.layout.field.FieldLayoutItemImpl isRequired() method must return the correct requiredness. There appears to be two camps here as to how this Issue should be dealt with: Some work has already been done in the "Step" configuration through property settings (i.e. jira.field.resolution.exclude). A property called jira.field.required = 10040,... could be set on the step, but this is not a very elegant solution. Another possibility would be to make it possible to set the options "required,optional" on each field of the screen editor. Considering the current jira design this would probably be the best place to handle this issue, although configuring the "Step" has more interesting possibilities.

Anton Mazkovoi [Atlassian] - 04/Oct/07 10:17 PM Dominick, Thanks for the update. I agree with you. I would prefer to actually implement "requiredness" on per step basis. However, as you have mentioned, this is not very easy. Therefore we are likely to opt for "requiredness" per transition, i.e. JRA-5783. Again, thanks for your feedback! Cheers, Anton