nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What happens to custom field pointing to deleted managed user?

KC Wong

I can only find old posts about Data Center on this subject. The custom field will become null.

But in cloud, I notice it will display the deleted user as "former user". How can I search for such values? i.e. customfield_10100 = deletedUser()

What happens to the user field value when the user gets deleted? Does it become EMPTY or something else?

I cannot find any relevant functions in this page:
https://support.atlassian.com/jira-software-cloud/docs/jql-functions/

Accepted answers

Matthew Sinclair

The UserID# (hexidecimal string or something) I think stays in place in terms of what's in the data - but that's it.

There's nothing there really - so not technically null - just former user.

I know this because we imported some Test Cases from Zephry to Testrail and we got a stack of unique ID#'s with no names.

Course I could just be spouting nonsense - but the bottom line is there's not much there but a gravestone so to speak.

You won't have much to recover/move/identify.

Could pull the info via API to see the raw JSON - but that's all I can think of at this point.

All comments

Matthew Sinclair

The UserID# (hexidecimal string or something) I think stays in place in terms of what's in the data - but that's it.

There's nothing there really - so not technically null - just former user.

I know this because we imported some Test Cases from Zephry to Testrail and we got a stack of unique ID#'s with no names.

KC Wong

So the user field should be unchanged, containing the same account ID…

Then to find deleted users, I will need to:

Inspect all work items
Check if user field is empty (shouldn't happen, but why not do so too)
Check if said account ID really exists
In case it still exists, check its active flag

Since you need to send REST API calls, automation is the only option. Doing so is going to be annoying:

Can only do 100 at a time.
Now cost you by steps.

Matthew Sinclair

When an account is "Deleted" (not deactivated) - it will simply be "Former User"

Deactivated will show "Deactivated" next to the name (still populated) however.

Not empty - never empty unless you make it so (within reason like the assignee).

API wise it will likely show the Unique ID# and not be considered active in any fashion.

The troublesome part is even with knowing the ID - you have no real point of reference other than its a cluster of whatever the former user "owned."

Jonas Nilsson | Unitlane

Hi KC, you may not need the REST loop. inactiveUsers() has no section of its own on that page, but it works on custom user fields: cf[10100] in inactiveUsers() finds every work item where that field holds someone who is no longer active.

It should catch deleted accounts too, not only deactivated ones. The same page, under customerDetail(), says its results include deleted or deactivated customers and that NOT IN inactiveUsers() removes them. Add the field as a column in the search results and you can tell the two apart: deactivated people still show their name, deleted ones show "Former user".

And as Matthew said, the field keeps the account ID, so cf[10100] is EMPTY won't find them.

Matthew Sinclair

Now the real question - what happens if the user comes back - new unique ID# or is it reassigned the previous?

suspect such things are not so simple.

KC Wong

Found this page:
https://support.atlassian.com/jira/kb/find-inactive-jira-cloud-users-without-using-third-party-apps/
The problem is, does a deleted managed user count as inactiveUsers()?

From this page:
https://confluence.atlassian.com/servicedeskcloud/deactivate-or-delete-managed-accounts-1097175889.html
I'm guessing it doesn't count. According to the page, when you delete a user from IdP, Atlassian deletes its data too.

So I think I need to do this:

Rule 1:

Scheduled.
Use REST API to get total count of work items.
Call Rule 2's web hook, passing along the data:
1. Current startAt (0)
2. Total count

Rule 2:

Web hook.
Get all work items sorted by key ascending, at specified startAt.
Process work items in a branch. Handle empty user field as well as user field pointing to non-existant accounts.
If startAt < total count, call itself, with next startAt.

That should be the minimal amount of steps while still processing everything… oh wait, there's a limit for 10 of automation calling itself too right?

Then if I have a lot of work items, I have no choice but to use a single rule on repeat, using a field to store the processed status, and eat the cost of repeatedly running the JQL query on the processed status?

KC Wong

It gets worse.

I have a user field, I need a monthly report on work items where that field contains: no user, inactive user or deleted user. User wants to collect that information and send a single email.

The single email part simpy isn't possible given automation has no method of doing a sequential for-loop.

Sami Shaik

Hi @KC Wong ,

The single email is possible, and you do not need a loop. Automation builds the list for you.

The rule

Trigger: Scheduled, monthly, with “Run a JQL search and execute actions for each work item” left unticked. You want one run, not one per item.
Action: Lookup work items with your JQL, for example:
project = ABC AND (cf[10100] is EMPTY OR cf[10100] in inactiveUsers())
Action: Send customized email (the plain Send email action is marked deprecated on the actions page). In the body, the list is one smart value block:
{{#lookupIssues}}{{key}}: {{summary}} ({{customfield_10100.displayName}}){{/}}
with a line break or <br> before {{/}} so each item lands on its own line.

That block repeats once per returned item inside a single message. Atlassian’s own KB Writing a rule that sends daily emails about JSM backlog is exactly this shape: Scheduled trigger, Lookup, one email with a {{#lookupIssues}} table.

Two things to know before you rely on it

Lookup work items returns a maximum of 100 items per the actions page. If the monthly result can exceed that, split the rule by project or by condition (one lookup for EMPTY, one for inactive) and send the two blocks in the same email, or add ORDER BY created and accept a cap.
Deleted versus deactivated in JQL. Jonas is right that cf[10100] in inactiveUsers() is the function to use, and the customerDetail() note on the JQL functions page confirms the pattern (results “include deleted or deactivated customers”, excluded with NOT IN inactiveUsers()). What Atlassian does not state anywhere I can find is that inactiveUsers() itself includes deleted accounts for a custom user field. Test it once with a work item you know points at a deleted account before you trust the monthly number. In the email, {{customfield_10100.displayName}} will read “Former user” for deleted accounts and still show the name for deactivated ones, which is as close as you get to telling them apart without the REST loop.

If the recipient only wants a count plus a link, {{lookupIssues.size}} and a link to the saved filter in the email body keep it to two lines.

Mertcan Karabaş (WERARE)

In Jira Cloud the field doesn't become EMPTY. When a managed account is deleted, Atlassian removes the personal data (name, email, avatar) and the account shows as "Former user". Issues and field values stay as they are. As far as I can tell, the field still holds the old account ID, which is why Jira shows "Former user" and not a blank. There's no deletedUser() function, but you can try these:

Check that the value is still there: cf[10100] is not EMPTY should still return those issues.
Use inactiveUsers(). Atlassian's KB says it works with user picker fields as well as assignee and reporter: cf[10100] in inactiveUsers(). The KB only mentions deactivated users, though, so try it on one issue you know has a deleted user before you rely on it.
Search by account ID. JQL can't match the "Former user" label, but it can match the ID: cf[10100] = "‹accountId>". To get the ID, open an affected issue through the REST API (/rest/api/3/issue/KEY?fields=customfield_10100), or look in admin.atlassian.com under the deactivated/former users list.

KB:

https://support.atlassian.com/jira/kb/find-inactive-jira-cloud-users-without-using-third-party-apps/

Matthew Sinclair

Keep in mind "Former User" is just a "gravestone" marker - a Unique ID# - with no information attached what-so-ever.

Its a deleted account - for that reason.

So if your looking to recover any information off of it? You won't get any in account terms

An "inactive user" is an "deactivated" account - those are accounts that still exist (for now - org level countdown clock will self delete if its configured) - Just "inactive".

KC Wong

So if your looking to recover any information off of it? You won't get any in account terms

Pretty obvious isn't it? I'm looking for work items associated with it.

It's not my AAD. It's my client's. I don't get to tell them when to deactivate and when to delete, but I need to be prepared when such cases happen.

Presumably an account would be deactivated before deletion, but if it can happen, I want my code to be able to handle it.

Matthew Sinclair

Oh…well then take a look at this.

https://community.atlassian.com/forums/discussion/686192/finding-issues-owned-by-inactive-users-with-jql-without-buying-additional-stuff

Various methods of "negation" in JQL - just might do the trick.

Update for current roles/groups - may have better luck here.

Joseph Chung Yin

@KC Wong

I agreed with @Matthew Sinclair multiple replies and he is right on the target as regarding to the user field.

Best, Joseph

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jql