Some unknown process is duplicating the same 2 Epics over months w/Inactive user as Reporter.

[Jason M.]

I've already tried support and they are just as confused as there is no reference to these tickets in logs that are duplicating the same 2 Epics in our Jira Server instances for the last 6 months.

I'm not sure how Jira perms allow these tickets to be created in the first place as the user in the Reporter field has been Inactive for over 6 months, the user is not searchable. Whatever process is creating these tickets seems to kick off same time overnight, but it's not happening every night. To make things worse, when it does run it seems to run dozens of duplicates in batch, even though the Created date is 1/2, 1/3, 1/4, etc, they only all show up all at once, overnight, after a period of days (or weeks)...this defies all logic for troubleshooting.

There are absolutely no references whatsoever in any of the Jira logs to help me reference an IP address, process, something....they all just APPEAR at random intervals.

I am at my wits end here, can anyone point me in the right direction to pinpoint what process (in Jira or external) is creating these mysterious %&#$!! duplicate Epics?

Thank you.

[Jack Brickey]

have you checked any automation/scripting you might have. Many times the automation is set to run as a certain user. I'm not exactly sure what would happen if the user that initially setup the automation to run as them leaves and is inactive. It might still run.

[Jason M.]

Definitely leaning towards that as root cause. The user is Inactive and they are not searchable in Jira, yet this process is still creating issues under the User's account. That makes me think the script is kicked off from another host...but when reviewing the logs for the "Created" timestamp range, there's no reference (that I can find) to this user, job, or issue keys getting created for some source IP address. 

Tried bumping Logging & Profiling from Administration console, but that didn't seem to have any effect. Perhaps I'm doing it wrong...

[Randy]

The reporter field can be different from the account that actually creates the epic.  If you view the history of the epic, does it show a different user as the creator?  That may help point you towards where to look at next.

[Jason M.]

Thanks for your response Randy, unfortunately the issue history still shows the same Inactive User as the Creator of the duplicates...as follows in History/Activity:

Bob Lastname [X] (Inactive) created issue - 24/Dec/19 1:00 AM

The timestamp indicates some cron/scheduled job, but there's nothing in the logs around that timestamp to reference an IP address...

Any other possible suggestions on where to look?

[Randy]

Try taking over the account and seeing if there are any api keys setup for it and disable them if so.  (assuming api keys are part of server - my expertise is more on the cloud side)

[Jason M.]

That's an excellent idea, I did try that using Scriptrunner but as the user is Inactive, they are not listed as an account to impersonate. I'm looking into any way of getting around that for now....

[Randy]

If you're using scriptrunner, you can rule out that it's SR by looking at the logs to see if SR is running during those timeframes.  If it is, one additional place to look would be workflow post functions assuming you've already checked the obvious scripting places like scheduled tasks and listeners.

You're on server...do you have access to the webserver?  if it's an option, maybe bump up logging verbosity on requests during that window of time so you can see if the API is being hit.

Another place to check...because you're server would be at the DB layer.  Perhaps someone hacked something in at that layer.