A PostFunction is vanishing from the transition if its worlflow scheme is assigned to a project

[Stanislav Korotky]

I'm trying to customize default workflow of Jira and apply it to a project.

So I made a copy of it, named 'Software development', and added a postfunction into "Resolve issue" transition. Specifically, I added 'Assign the issue to the Lead Developer'. I saved the workflow, and when I open it anew, the changes are persistent.

Then I created a workflow scheme and bind new workflow with all issue types.

Finally I assigned the new workflow scheme to one of our projects.

Now I see that the workflow 'Software development' is active and is used by the project. BUT, when I look at the workflow layout and check the transition postfunctions, my addition is missing, that is there is no 'Assign the issue to the Lead Developer' postfunction in the "Resolve issue" transition.

Am I doing something wrong?

P.S. I did a rollback, that's I returned the project to default workflow, and consequently made my new workflow inactive. After this my addition is back. So it looks like the postfunction is saved somewhere, but gets eliminated when the workflow becomes active.

[Stanislav Korotky · Accepted solution]

The problem has been solved somehow - after switching back and forth it vanished, and postfunction started to work properly. I can admit this was my mistake in applying transition properties.

[Nic Brough -Adaptavist-]

Ah, I've seen this before, although not for a while.

It's possible to write broken post-functions that look like they're working fine until they're actually used. That is, you install the plugin, check it's active in the plugins admin page, you can add the function to workflows, and it all looks good.

Then, when someone executes the transition (or, possibly, although this isn't what I saw, when the migration of workflow happens), Jira runs smack into a problem with it, and disables/unloads it. That helpfully makes it vanish from the workflow editor, but it can then be reloaded by going back to view a workflow after unassociating it.

I know that's not quite what you're seeing, it sounds similar enough to be worth mentioning. I tracked it down by going over the logs - I'd concentrate on the times where you were migrating the project to your new workflow, and what happens the first time a user uses the "resolve" transition that calls the function.

[Stanislav Korotky]

This is much simplier situation than you described. We just started the new project and it's not so much users involved. So I'm pretty sure no one mananged to run the 'resolve' transition between the moments I changed the workflow scheme and looked back to it (I did not try to resolve either). Moreover, this is all about Jira OnDemand, so I do not use 'problematic' 3-rd party plugins. This is the clean Jira out-of-the-box, and the "Assign the issue to the Lead Developer" seems a very well-known and built-in stuff.

Should I move this to support area?

[Nic Brough -Adaptavist-]

Yes, sorry, that's definitely a support call - the situation I've seen it in was caused entirely by my dodgy code. OnDemand has a slightly dubious pointer here for questions that are definitely for support, and I don't really notice the label much, I just answer what I see.

If it's not working in OnDemand, then it's a support call there. Because you'd need the logs to help find it (and more to the point, it really doesn't sound like you've done anything wrong, so it must be system stuff or something we don't know about your setup)