Troubleshooting

“The run was blocked” at confirm

The app re-checks your Administer Jira permission and your per-project access before any write. If a project fails that check, the whole run is blocked with the project named — it is not partially applied. This is intentional: it's safer to stop than to write a half-finished result.

• What to do: make sure you still have admin access to every project involved, then start again. If you only need to reassign content outside the failing project, narrow the run to a different departed user/scope.

Some items show as “unreachable”

During the scan, items the app can't read on your configuration are marked unreachable and are shown, not silently dropped. They are excluded from the reassignment (the app won't act on something it can't read), and the evidence notes them so your record stays honest.

• Common cause: content the app's permissions don't extend to on your site.

A run “completed with failures”

If an individual item can't be reassigned, it's shown as failed with a reason, and the run reports completed with failures rather than hiding the problem behind a green result. The “reassigned” count excludes failed items.

• What to do: review the failed rows in the evidence, resolve the cause (for example, a target that can't own that specific item), and re-run for those items — re-running is safe and won't double-apply changes that already went through.

A run is “paused / resumable”

A run can pause itself if the permission picture changes while it's running (a time-of-check/time-of-use safeguard) — for example, if your access to a project is changed mid-run. You'll see a paused state with the reason.

• What to do: resolve the cause, then select Resume. The run continues from where it stopped and rebuilds its counts correctly.

“A run is already in progress on this site”

Only one reassignment run can be active at a time. If you reload the page mid-run, or another administrator started a run, the first screen shows a banner: A run is already in progress on this site — select Watch its progress to follow it live, or wait for it to finish before starting a new scan. A run that paused before completing shows A paused reassignment run needs attention instead — select Review and resume.

• Note: Start over only resets the screens in front of you — it does not cancel or affect a run that is already executing.

“Can it reassign dashboards?”

Not in this version — dashboards are out of scope. Transferring a dashboard's owner can't be done reliably in a way the app can read back to produce an honest record on Jira Cloud today, so the app never reassigns or evidences a dashboard (it shows them at preview for completeness, marked out-of-scope; the listing and evidence say so). The app focuses on issues (assignee/reporter), filters, component leads, and project leads. (Native Jira can change a dashboard's owner via its admin screens.)

“What about automation rules / project-role members / watchers?”

These are out of scope in this version, on purpose:

• Automation-rule actors — Jira natively transfers these (admin → Transfer automation rules), so the app doesn't duplicate it.
• Project-role memberships, board admin, group memberships — different object models / a different job (closer to license-and-lifecycle management).
• Watchers, mentions, comment/worklog authorship — these are participation or authorship, not ownership, and aren't reassignable in Jira.

The evidence record names what's out of scope so “closure evidence” is never read as “everything.”

The app says it lacks a permission it needs

Use Check app permission status (under Diagnostics on the first screen). The app uses Administer Jira (received from the Atlassian-managed add-on admin group at install) to reach a departed user's private filters. If that's missing, private filters are shown as unreachable rather than acted on — the app degrades gracefully instead of failing the run.

Still stuck?

See the app's support link on its Marketplace listing, or write to info@wayflare.eu.