Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If Jira returns no results for worklogAuthor = currentUser() while your team uses Tempo, the cause may be how Jira receives the worklog—not a typo in the query. In Jira Cloud, Tempo says synced worklogs can appear under the Tempo app user, hiding the individual logger from Jira’s native author search. Jira Data Center 9.0 and later has a separate issue: JQL indexes only the 100 newest worklogs on an issue. Check your hosting model before choosing a fix; these are different problems.
First identify your Jira hosting model
There are two distinct explanations in the documented cases. In Jira Cloud, a Tempo worklog may be attributed to Tempo’s app user rather than the person who entered the time. In Jira Server or Data Center 9.0 and later, JQL can miss an older worklog because Jira indexes only the 100 newest worklogs on each issue. The Cloud behavior concerns identity; the Data Center limit concerns indexing and recency. Tempo describes the Cloud behavior, while Atlassian documents the Data Center limit.
| What to check | Jira Cloud with Tempo | Jira Server/Data Center 9.0+ |
|---|---|---|
| Likely reason for no match | Jira may see the Tempo app user as the author, not the individual logger. | The target worklog may be older than the 100 newest entries Jira indexes for that issue. |
| Clue to inspect | Jira’s worklog author shows “Timesheets by Tempo – Jira Time Tracking,” while Tempo identifies a person. | The issue has more than 100 worklogs, or the symptom began after an upgrade from Jira 8.x. |
| Best next route | Check the Tempo panel, Logged Time Report, or Tempo REST API. | Verify worklog count and recency; have an administrator assess indexing configuration. |
Diagnose the Jira Cloud and Tempo case
Why the human author may not be searchable in Jira
Tempo says its Jira Cloud integration operates as an independent system with a separate database and manages synced worklogs through a Tempo app user. Jira may therefore display “Timesheets by Tempo – Jira Time Tracking” as the author. Tempo’s guidance is that Jira’s REST API returns anonymized Tempo data and JQL searches using worklogAuthor will not identify specific individuals. This is a privacy design described by Tempo, not proof that the query syntax is wrong. Tempo’s explanation and recommended places to inspect worklogs are in its Help Center.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Where to verify who logged the time
- Open an affected Jira issue and note the author shown for its worklog.
- Compare it with the worklog information in the Tempo panel on that issue or in Tempo’s Logged Time Report.
- If you need the data for an integration, use Tempo’s REST API and confirm that your Tempo permissions allow you to view other users’ worklogs.
If Jira shows the Tempo app user while Tempo’s own view identifies the individual, that is consistent with the documented Cloud anonymization behavior. The exact result for your site depends on its deployment and permissions; those details must be checked on your instance.
#1 Best Overall
Check for Jira Data Center’s 100-worklog indexing limit
Atlassian documents a separate limitation for Jira Server and Data Center from version 9.0.0: Jira indexes only the 100 most recent worklogs on each issue. If an issue has more than 100 worklogs and the person’s entry is outside that newest group, JQL using worklogAuthor or worklogDate can miss the issue. Atlassian’s article, updated September 26, 2025, also lists limits of 500 comments and 100 change-history entries; the relevant worklog figure is 100 per issue. See Atlassian’s diagnostic and configuration guidance.
- Confirm whether the instance is Jira Server or Data Center and verify its version.
- Check whether the issue has more than 100 worklog entries and whether the target entry falls outside the newest 100.
- If the symptom appeared after an upgrade from Jira 8.x, include that timing in the administrator’s investigation.
Administrator workaround and trade-off
For this specific Data Center indexing case, Atlassian documents the JVM parameter -Djira.safeguards.indexing.issue.worklogs=-1 to disable the indexed-worklog limit, followed by a project or full reindex. This is an administrator-only, version-specific workaround. Atlassian cautions that it may affect issue-search performance and recommends testing it on a non-production Jira instance first. It does not restore individual authors hidden by Tempo’s Jira Cloud anonymization.
Rank #2
- Used Book in Good Condition
What currentUser() means—and what it does not prove
Atlassian describes currentUser() as a function based on the currently logged-in Jira user. The current Jira Cloud JQL function reference lists supported fields for that function, including Assignee and Reporter, but does not list worklogAuthor in its current-user section. Older Jira documentation and Atlassian examples have used worklogAuthor = currentUser() for native Jira worklogs, so the Cloud reference alone does not establish that every Jira deployment rejects the expression. For a Tempo Cloud worklog, the more relevant question is whether Jira has the individual logger as its author at all. Atlassian’s Jira Cloud function reference explains the documented function behavior.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Use Tempo-specific search and identity carefully
Tempo provides JQL functions for advanced searches involving Tempo fields such as Teams, Accounts, and internal work items. Those functions help search those fields, but Tempo does not describe them as a way to recover an individual author from an anonymized Jira Cloud worklog. See Tempo’s JQL function documentation.
For scripts that need to identify worklogs created by the Tempo app, Tempo recommends filtering by the app user’s accountId rather than its display name, which can change. This identifies Tempo-created worklogs; it does not reveal the end user behind an anonymized Cloud record. Tempo also documents a separate time-zone detail: UI-created worklogs derive startDateTimeUtc from the browser or operating system’s time zone at creation, while public API worklogs use the author’s Jira profile time zone. For reliable UTC conversion, Tempo advises using startDate and startTime with the author’s Jira profile time zone rather than treating the UI-created timestamp as profile-derived. Tempo’s worklog API guidance covers these fields.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
