End to End Business Logic Support

Big companies work differently than small companies. If JIRA is to be effectively used by large, reliable, predictable, accountable companies, and not small ad hoc development teams "where anything goes", then JIRA must have support for business logic that goes beyond a required field here, or a workflow condition there.

Proper support for business logic means allowing the tool to have custom logic applied before any edit happens, so that changes to issues can be validated against business logic, appropriate for the enterprise JIRA is being used in.

Some examples:

• You might want fields to be valid in the context of values of other
  fields.

• You might want dynamic conditions.

• You might want approval processes to be invoked, a certain role
  may be able to lock/unlock certain fields, potentially at different
  points in the lifecycle.

• You may want fields to conform to certain formats for legal reasons.

• etc.

Support business logic at the enterprise level comes down to allowing plugin authors to gate/stop edits before they are made to JIRA issues.

We are not asking you to implement business logic in JIRA, we are asking you to make it possible for that class of problems to be addressed by plugins.

JIRA must provide the ability to stop or alter all edits, not just provide notification that changes are happening.

How JIRA is failing to do this now:

Plugins can listen to changes but not actually stop or alter them. All edits (all of them) need to be preceded by a pending edit hook of some kind to give plugins a chance to gate the edit or alter it.

This can not be done right now. The closest you can get is using the JIRA Behaviors plugin or writing something similar where you can control the edits being made in the browser via Javascript validation, and/or in combination with server side processing.

This fails to provide complete support though. A user can easily subvert business logic enforced through JavaScript:

1) do a bulk edit

2) do inline editing (if the javascript doesn't handle inline editing)

3) do edits through remote API

4) do edits through plugins (like GreenHopper)

So while a plugin such as JIRA Behaviors (which is awesome by the way), works great, it can't possibly provide true business logic support, no plugin can. There is no way to gate/stop edits to issues in a way that is consistent and guaranteed to always apply.

So, ideally JIRA should provide an internal hook to plugins, which allows plugins to gate/stop/alter edits before they are made.

For now though, you could solve 90% of the problem by providing a pre-edit hook inside Bulk edit. JIRA Behaviors will likely add inline edit support, GH is using the built in edit screens now I think, and if they do remote editing...well we can tolerate that.

So just adding a Bulk Edit pre-edit hook for plugins would solve most the problem.

Again, I want to be clear, this is absolutely necessary for enterprise customers. Large companies focus on being predictable, reliable and accountable. To do this, we have to enforce certain practices in JIRA, that can not be enforced simply by adding workflow conditions or configuring a few field screens. We don't expect you to implement business logic, just that you make it possible for us to get it done, either by plugin providers or on our own.

If Atlassian is serious about addressing the enterprise market, this feature should be at the top of your queue. Big companies work differently than small companies.

Even if you don't believe the enterprise argument (which you should), then for Agile to be a mature and disciplined approach, you still need this. Otherwise I don't think you can claim Agile is maturing.