Why worklogAuthor = currentUser() finds nothing when your team uses Tempo

#jira #atlassian #productivity #api

Plenty of people keep this as a saved filter in Jira:

worklogAuthor = currentUser() AND worklogDate >= startOfWeek()

On a Jira Cloud site with Tempo Timesheets it comes back empty for anyone who logs time through Tempo, even after a full week of logging, and there's nothing wrong with the query. If you open the Work log tab on any issue, the entries are by "Timesheets by Tempo - Jira Time Tracking" (older sites and screenshots show "Tempo Timesheets"), and each one has "time tracking" as its comment.

What Tempo does on Jira Cloud

Tempo Cloud keeps worklogs in its own database. When you log time in Tempo, it also creates a worklog in Jira so the issue totals stay right, and that Jira worklog goes under Tempo's own app account. Tempo's help center says, "This worklog is created without user attribution to respect view privileges for worklogs."

This has been the behavior since at least 2018. Back then a Tempo staff member explained in the Atlassian Community that Tempo has its own rules for who can see whose time, and Jira shows worklog authors in too many places for Tempo to enforce those rules there, so the real author stays in Tempo and Jira gets an anonymous copy.

Through Jira's REST API that copy looks roughly like this, based on the examples in Tempo's own docs (trimmed):

{
  "author": {
    "accountId": "557058:…",
    "displayName": "Timesheets by Tempo - Jira Time Tracking",
    "accountType": "app"
  },
  "updateAuthor": {
    "displayName": "Timesheets by Tempo - Jira Time Tracking",
    "accountType": "app"
  },
  "timeSpentSeconds": 7200,
  "properties": [
    { "key": "tempo", "value": { "shadow": "true", "tempo_id": 9701 } }
  ]
}

The duration and date are real, but nothing in the record tells you whose time it is. The comment is a placeholder, and the tempo property holds only Tempo's internal ID, with no account ID or name.

What breaks

Anything that asks Jira instead of Tempo who logged the time:

worklogAuthor in JQL can't match people who log through Tempo, and Tempo's KB says so. Tempo's own JQL functions on Cloud don't help either, since they cover teams and accounts but not the worklog author.
On the issue, the History tab and the Activity stream show Tempo as the one who created and edited each entry.
Users on the Atlassian Community reported in 2022 that {{worklog.author.displayName}} in Jira Automation returns the Tempo app.
Scripts and exports built on /rest/api/3/issue/{key}/worklog, or on the issue CSV export. ScriptRunner users and at least one Forge app vendor ran into this, and the answer they got was to switch to Tempo's API.
Anything else that reads Jira's data to work out who did what. A June 2026 review on Tempo's Marketplace page lists native reports, BI tools, audits and Atlassian Rovo.

Time spent on the issue and the time tracking bar still add up correctly, because the shadow worklogs carry real durations.

Check your own site in one call

Don't match on the display name, since it has already changed once (Tempo's docs say the same). Look at the account type and the tempo property instead:

curl -s -u "you@company.com:$JIRA_API_TOKEN" \
  "https://your-site.atlassian.net/rest/api/3/issue/PROJ-123/worklog?expand=properties" \
  | jq '.worklogs[] | {author: .author.displayName, type: .author.accountType, tempo: ((.properties // []) | any(.key == "tempo")), seconds: .timeSpentSeconds}'

Rows with "type": "app" and "tempo": true are Tempo's shadow copies, and anything with "type": "atlassian" was created by a person, either in Jira's own dialog or through something that writes to the API as that person.

If you're keeping Tempo

Build your reports on Tempo's data instead. Tempo's REST API v4 returns the real author.accountId on every worklog. GET /4/worklogs/user/{accountId} gives you one person's time, and POST /4/worklogs/search takes a list of authorIds. If a script starts from a Jira worklog (an Automation rule, for example), Tempo's documented recipe is to read properties.tempo.tempo_id and fetch GET https://api.tempo.io/4/worklogs/{id} with it.

There's no fix on the JQL side, so the nearest thing to a "my worklogs this week" filter is a Tempo report filtered by user.

If you want your name on your worklogs

A worklog created in Jira by the user keeps that user as its author, whether it comes from the Log work dialog or from a REST call made with the user's own credentials. Jira's API marks author as read-only, so no app can rewrite it afterwards. According to Tempo's sync docs, those worklogs get copied into Tempo too, so finance still sees them in Tempo reports.

When Tempo is set as the site's time tracking provider, though, Jira hides its own Log work dialog everywhere except workflow transition screens, so in practice "log in Jira" means the REST API or a tool built on it. And I couldn't find anything from Tempo about what happens to the Jira author if someone later edits one of those entries inside Tempo. Try it on a single entry before you change how a whole team logs time.

That REST route is what Planim Time uses; it's the desktop tracker for Jira. It sits in the menu bar or tray, and Push sends each entry through your own Atlassian login as a normal Jira worklog, so the author is you and worklogAuthor = currentUser() finds it again. The timer, Push and two-way sync are on the free tier. Old Tempo rows stay anonymous in Jira, though, and since Jira doesn't attribute them to you, the app doesn't show them either. If you're leaving Tempo, export from Tempo's API before you cancel; the migration steps are in a separate post.

If you're choosing a tracker, I compared ten of them on LinkedIn, including how each one handles this, who has to install it and what you end up paying for.

DEV Community