Due date limitation based on task category choice

Question

Hello,

I've previously worked with the ticket flow that is set up in a manner which limits the earliest "Due date" choice in the calendar based on task category.

For example

Issue type: Task

Category: Webpage Development

Due date: Calendar function to pick a date - doesn't allow to pick a date that is sooner than 30 days ahead

IssueType: Task

Category: Image Adjustment

Due date: Calendar function to pick a date - doesn't allow to pick a date that is sooner than 2 days ahead

It seemed like a great solution to "bottleneck" the workload in the initial request, afterwards, the deadlines can be discussed but saved a lot of stress to some departments that receive various tasks with various workloads.

How this could be set up and what limitations are there when this has to be set up? E.g, available only on Service Desk platform.

Daniel Ebers · Answer

I came across a use case where an App (I don't remember which exactly but I can ask if you wish) was used to enforce that the due date is greater than the current date (at least: now + 5 days).
This is enforced during approval transition (at the end is was indeed a workflow validator and some logic to calculate on the dates, nothing special).

Drawback: when the approver is not "on time" the due date needs to be adjusted further in the future - some kind of a glitch in this workflow.

Example:

Alice opens an issue 24/12 putting due date 05/01 in.
Her manager Bob (as he must approve everything, due to their process and workflow settings) is on Christmas vacation and he will come back 04/01.
He *cannot* approve (error message appears) as the due date now violates the now + 5 day theory. (He must extend it to let's say 10/01).

And yes, the acting department, COULD have processed the issue some time in between - but this is another topic as per approval processes.

For the (very good) remark this is wasting time: yes, for that the workflow knows a step "escalate". Some magic happen than to request a faster processing. Okay, this could have prevented also the above mentioned scenario - but the users must accept it and get familiar with it all (as it writes some mails to top managers some users prefer not to use it - what leads back to the misery referred to as "wasting time").

So, once again, Jira handles everything pretty nicely but there comes a point when extra documentation on all of this is crucial (as in: process documentation, but also on the logic).

Nothing is set in stone, though - if the above does not make sense to you (what is fully acceptable) your team probably works just another way.

Radek Dostál · Answer

Well, I've put that in a weird way.

Due Date (system field) and Date Picker or Date Time Picker (custom field types) do not allow any such limitation or restriction what Dates you can input. They simply just are the way they are and you cannot modify what dates they provide. Much less so Jira will not allow you to set up any conditions "if field X then this field should do Y" out of box -- there's no way to achieve this without plugins and/or javascript.

What I meant by custom is more akin to a "plugin" way -- i.e., a different field type from what you have available on your instance altogether.

I must say though that this is probably an overkill and you would be fine with the javascript -- ScriptRunner behaviours can be quite interactive in a way that they can run each time you change something on the screen. It just won't let the user create an issue until it is satisfied that the due date passes it's condition. So, based on the Category selected, it can decide what the minimum due date should be, and not let the user create the issue otherwise.

You could do a similar thing with a workflow validator, but it would not be so interactive as workflow validator will only run when you press the 'Create', so that should be worse user experience I would think.

Armands Brimmers · Answer

In my previous experience, it was working quite good since each task had a stable delivery time and work was planned according to that.

Some urgent out of the box requests might end up requested but overall it was well organized. Maybe didn't put the best example "tasks" in the initial post but the actual tasks are relatively "stable" in terms of the delivery time.

Custom customfield allows setting rules based on some field?