Due date limitation based on task category choice

[Armands Brimmers]

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.

[Radek Dostál]

I don't think that you are addressing this in the right way, to be honest,

What I get from this is that you want to put later due date on tasks so that users do not get stressed about how much they have due. Your workaround now puts false due dates, which will have to be addressed at some point anyway. All that you have done here is put a false date or caused that a required item gets done later than it was actually required.

This to me sounds like a disfunctional way to use due dates.

Now there would probably be a way to do this, I think I've come across a javascript or a plugin doing this in the past - and I can imagine that there is a use case for not allowing due date to be "too early" - it's just the rationale why you want this that I'm a bit curious of.

For example ScriptRunner behaviour could set up a validator on the field, you can find more about an example here https://community.atlassian.com/t5/Jira-Software-questions/How-to-set-a-restriction-on-changing-the-due-date/qaq-p/1168696

However ScriptRunner is a paid plugin. There might be others or even more specific to due dates. ScriptRunner behaviours are javascript-based, so you can accomplish the same functionality without the plugin but it would be quite difficult to implement from the scratch I imagine.

Other than javascript (therefore, frontend web browser facing only), I don't know myself of any other plugin from the top of my head that can change the due date behaviour "internally" - i.e., in a better way like for example graying out the date selection, rather than just a validator/error message "please set later date" and similar.

I think this would have to be a different and custom customfield other than the system Due Date, but again that's just my guess.

[Armands Brimmers]

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?

[Radek Dostál]

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.

[Daniel Ebers]

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.