I’m running into a problem with my Jython post-function script. When I try to set a due date on a newly created JIRA issue, the workflow fails to initialize properly.
Here’s my current script:
from java.util import Calendar
from java.util import Date
import com.atlassian.jira.component.ComponentAccessor
from com.atlassian.jira import ComponentManager
from com.atlassian.jira.issue import Issue
from java.sql import Timestamp
import java
import time
current_time = long(time.time())
ticket.setDueDate(java.sql.Timestamp(current_time))
ticket.store()
The error message I keep seeing is:
Issue workflow initialization error: unable to find Issue created with workflowId ‘10694’. Did the IssueCreateFunction run successfully on workflow.initialize() ?
This only happens when I include the due date setting code. Without it, the issue creates fine. Has anyone encountered this before? What’s the correct way to set due dates in post-functions without breaking the workflow?
Been there, done that. You’re calling ticket.store() directly, which screws up JIRA’s internal workflow state tracking. JIRA wants the workflow engine handling persistence, not your script.
Your timestamp conversion’s also wrong - you’re passing milliseconds but JIRA needs a proper Date object.
Honestly? Skip fighting JIRA’s weird post-function limits. Move this logic outside the workflow completely. Set up an automation that triggers after issue creation and handles due dates through the REST API.
I’ve fixed similar problems by creating a webhook listener that catches issue creation events, then updates the due date using proper API calls. Avoids all the workflow initialization headaches.
Latenode makes this dead simple. Create a webhook endpoint that receives JIRA events, calculates your due date, and sends it back via JIRA’s REST API. Takes 5 minutes to set up and never breaks workflow initialization.
This happens because you’re messing with the issue object after JIRA’s already saved it to the database. Calling ticket.store() basically does a second save that fights with what the workflow expects.
I hit this same thing last year. Fix it by using IssueManager’s updateIssue method instead of storing directly. Here’s what worked:
from com.atlassian.jira.component import ComponentAccessor
from java.sql import Timestamp
import time
issueManager = ComponentAccessor.getIssueManager()
current_time_ms = long(time.time() * 1000)
due_date = Timestamp(current_time_ms + (7 * 24 * 60 * 60 * 1000)) # 7 days from now
issue.setDueDate(due_date)
issueManager.updateIssue(user, issue, com.atlassian.jira.event.type.issue.IssueEventType.ISSUE_UPDATED_ID, false)
This way respects JIRA’s workflow state management but still lets you set the due date during creation. That false parameter stops extra events from firing and causing workflow conflicts.
This is a timing issue. Your script tries to modify the issue before JIRA finishes initializing the workflow, which creates a race condition. Don’t use ticket.store() - work with the MutableIssue interface instead and let JIRA’s workflow engine handle saving. Try this approach:
from java.util import Calendar
from java.sql import Timestamp
import time
cal = Calendar.getInstance()
cal.setTimeInMillis(long(time.time() * 1000)) # Convert to milliseconds
cal.add(Calendar.DAY_OF_MONTH, 7) # Add 7 days or whatever you need
mutableIssue = issue
mutableIssue.setDueDate(Timestamp(cal.getTimeInMillis()))
Key changes: skip the manual store() call, convert to milliseconds properly, and use Calendar for date math. This works because you’re modifying the issue object that JIRA automatically persists after the post-function runs. I’ve used this pattern in production - it fixes those workflow initialization failures.