LITE - Privacy Policy

LITE - Privacy Policy

Last updated: Oct 2, 2026

Summary

Timesheet Management LITE ("the app") is a free Jira app that lets users log and review their own work time. It stores very little of its own. Nearly everything it displays is read directly from your Jira site’s own data, on demand, and almost all of it using your own Jira permissions.

Short answer to "does it store private data": mostly no, with a few narrow exceptions. The app does not persist worklogs, issue data, or user profiles of its own. Those are read live from Jira and never copied into a separate database. The app’s own storage holds site and admin settings (including the list of people or groups given delegated settings access, and the email-digest configuration), saved Timesheet-tab filter views, records that link repeating worklogs together, a short-lived cache of non-personal site configuration, and a troubleshooting error log. See "What the app stores" below for details.

What the app accesses

When you use the app, it calls Jira’s own REST API on your behalf (using your existing Jira session/permissions) to:

  • Read and write worklogs (time entries) on work items

  • Read work item details (summary, status, resolution date, time-tracking fields)

  • Read your own user profile (account ID, display name, avatar, time zone, locale) and, where relevant, other users’ names/avatars for display (e.g. whose worklog a report row belongs to), and search for users (e.g. to name a delegated settings admin)

  • Read the membership of a Jira group, when a group has been given delegated settings access, or to send the daily digest email to its members

  • Read space (project) information

  • Read the site’s active Time Tracking Provider configuration and its working-hours / working-days settings

All of this happens through Jira’s own API, using the permission scopes listed in the app’s Marketplace/install listing. Most calls run with your own Jira session and permissions. A few run under the app’s own access instead, because they have no signed-in user to act as or must give every user the same answer: the daily background job (the digest email and personal data reporting), the lookup of group memberships, the check of whether you are a Timesheet Management admin, and the list of spaces offered in the Space filter. Because of that last one, the Space filter can list the names of spaces you cannot open in Jira. It never shows their work items or worklogs. None of this is copied into the app’s own storage. It is fetched fresh on each request (with the exception of the brief site-config cache described below). The background job writes nothing to Jira.

What the app stores

The app’s own storage (hosted on Atlassian’s Forge platform, in the same infrastructure/data residency as your Jira site) holds:

  1. Site and admin settings: admin-configured options: whether to block worklogs after a work item’s resolution date and the “don’t flag before” cutoff date; which day the week starts on; which days count as the weekend; the account IDs or Jira group IDs of people given delegated settings access (“Timesheet Management admins”); and the email-digest configuration (whether it’s on and which work item it’s sent from). Non-personal apart from the delegated-admin identifiers.

  2. Saved Timesheet views (personal data, user-chosen): each user can save up to 10 named Timesheet-tab filter combinations, each with an optional description. If a saved view’s User filter includes other people, their Jira account ID and display name are stored as part of that view so it can be reapplied later. This is a choice made by the user creating the view, not automatically collected. A view is private to the user who saved it unless they choose to share it. A shared view can be opened by anyone on the site who has its link, and it also stores the owner’s account ID and display name. A view is removed as soon as its owner deletes it (or the app is uninstalled).

  3. Repeating worklogs: when a user repeats a worklog across several days, the app keeps a record that links those worklogs together, so they can later be edited or removed as a group. The record stores the account ID of the person who created the series. It does not store a name.

  4. Error log: up to the last 100 errors encountered by any user, each including a timestamp, the error message/technical detail, and which part of the app it happened in.It records only an account ID for who triggered an error, not a display name. Visible only to Jira admins, who can clear it at any time from the app’s settings.

  5. Cached site configuration: the site’s active Time Tracking Provider status, whether a sibling app is installed, and working-hours/working-days settings. Entirely non-personal and site-wide. Cached for up to 10 minutes to reduce redundant requests to Jira, then automatically refreshed.

The app does not maintain a separate database of your worklogs, time entries, or activity. Every worklog you create through the app is a completely ordinary, native Jira worklog, the same record Jira itself would create if you logged time through its own UI. If you uninstall the app, your worklogs remain in Jira untouched. Only the app’s own storage is removed, as described under "Data retention" below.

Emails

If an administrator enables it, the app asks Jira to send a daily summary email, to Jira site admins and to anyone on the delegated-admin list, on working days when a worklog has been logged after its work item’s resolution date. Jira sends these emails; the app does not use an external email service, and the email contains only a prompt to open the app, not worklog detail.

Account closure and erasure

The app reports the accounts it stores data for to Atlassian once every 7 days. When Atlassian reports an account as closed, the app erases or anonymises that person's data within 7 days. When Atlassian reports that a person's profile changed, the app updates the name it keeps for them in its settings. For each closed account the app then:

  • deletes the saved views the person owned, and removes the person from any other user’s saved view filters;

  • removes the person from the Timesheet Management admins list;

  • removes the account ID from error log entries and from repeating worklog records, and leaves the rest of each record in place.

If a record cannot be updated, the app logs it and retries on the next daily run.

Third parties

The app doesn’t send data to marketing, analytics, or advertising third parties, and has no external network access beyond your own Jira site’s API. Personal data may be processed by RLC Digital personnel in Singapore, by Atlassian’s Forge platform (which hosts the app), and, subject to the restricted-access terms in our DPA, by a US-based freelance developer. See the Data Processing Addendum for full subprocessor and transfer details.

Data retention

  • Settings (including the delegated-admin list and digest configuration) persist until changed by an admin, until a listed person’s Atlassian account is closed, or until the app is uninstalled.

  • Saved Timesheet views persist until the user who saved them deletes them, their account is closed, or the app is uninstalled. There’s currently no other automatic expiry.

  • Repeating worklog records are removed when all but one of their worklogs have been deleted through the app. Otherwise they persist until the app is uninstalled.

  • Error log entries are capped at the 100 most recent and can be cleared manually by an admin at any time; they’re also removed when the app is uninstalled.

  • When the app is uninstalled, Atlassian removes the app’s own stored data from the app and keeps it for up to 28 days before deleting it permanently, so it can be restored if the app is reinstalled and a restore is requested within 21 days.

  • Worklogs and all other Jira data are governed by your Jira site’s own retention policies. The app has no independent retention of its own.

Changes to this policy

We’ll update this page if what the app stores or accesses changes. Check the "Last updated" date above.

Contact

support@rlc.digital