How can we restrict the reordering of subtasks from the parent?

[Nadia Lavigne]

Hello,

When you see the subtasks in the parent screen, you can click and drag a subtask and change its order. Is there a way to prevent it so that always show the subtasks in the order they were created?

[Radek Dostál · Accepted solution]

Not as far as I know, but why would you want to remove a feature which doesn't otherwise have any negative impact? The question I'd ask is why they were reordered, seeing as it is a conscious decision by someone, likely to improve/visualize something.

[Nadia Lavigne]

Hi Radek,

we would like to restrict this feature for one project only. The subtasks created must be completed in the created order only. Right now I validate for prior tasks being closed or cancelled (except for the first task) before starting progress in the next one. When the assignee re-orders them, they can work in any task and management wants to prevent this from happening (a user was able to "cheat" like this).

This is the validator I have right now 

The only idea I have right now, since all these subtasks are created at the same time with a SIL, is to add the number of the task at the beginning of the Summary and validate based on that, and disable the summary. That way it wouldn't matter if they re-order them. My only concern is that this needs to be personalized as not all tasks have the same subtasks (we have for issuetypes and each of them have different number of subtasks). What do you think?

[Radek Dostál]

Mhm, validating the order rather than preventing it might be a way. Even if Jira had something hidden to disable reordering, I totally and absolutely doubt it would be on a per-project basis.

One idea would be to craft javascript to disable the reordering option on issue view, but you could still cheat it by crafting remote POSTs, and if I look at the POST it actually does, it's /rest/api/2/issue/<issueid>/subtask/move so that url isn't connected to a project either.

Perhaps, and this is just a general idea, it would be possible to create a mini-plugin with a Servlet filter (https://developer.atlassian.com/server/jira/platform/servlet-filter), which would intercept the move request, get the issueid, figure out which project that issue belongs to, and if it's the one you want to restrict - stop the request, otherwise for other projects, allow it. Then again a bit of a dev work with possible maintenance in the future, but that might be a way how to achieve it perhaps.

As far as validation goes, your idea might work, I didn't quite catch if you're validating it externally (some script to run outside Jira), or something done in Jira (workflow validator?), but of course it should be possible to do some validation on it.

I think what might also work is adding a validator/condition on the subtasks directly, e.g.

* Trying to finalize subtask by moving to "Done"

* Validator kicks in and compares the subtask's id to see if there are no other lower id subtasks on the parent below this subtask

* Found that there is a lower id subtask below this one, throw an error

That's assuming that each new issue has an incremented ID, so by that token, the first order is that issueid will go up, if at any point in time there is a lower id below the the current subtask, it must mean it was reordered. (and vice versa, higher id above the subtask)

Although I suspect for this you would also need a plugin, such as https://marketplace.atlassian.com/apps/6820/scriptrunner-for-jira?hosting=datacenter&tab=overview which allows scripted validators.

[Nadia Lavigne]

We tried JavaScript as you suggested and I don't think we can work with it. We usually use the workflow validators and point them to our SIL scripts.

My colleague suggested me to link the prior tasks and I would just have to check if they are Done or Cancelled, but I think it would be faster to just add the sequential numbers at the beginning of the summaries (e.g. 1. XXXX). 

Thanks for your help!