You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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
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.
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.
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
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.
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?
Well, I've put that in a weird way.
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.
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.
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.
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.