JetTime Work Log Metadata

JetTime enhances standard Jira's API work log object by using work log properties. All JetTime-related data is stored as a custom work log property with the key jettime. Below is a complete example of how JetTime stores its metadata:

Full Example of JetTime Work Log Metadata

{

  // Standard Jira work log fields
  // ...

  "properties": [
    {
      "key": "jettime",
      "value": {
        "schemaVersion": 2,
        "timeSpentSeconds": {
          "BILLABLE": 1800,
          "BILLABLE_OVER": 1200
        },
        "fields": {
          "EXPENSE": 1800,
          "INTERNAL": false,
          "INTERNAL_NOTES": "Just between us, pssst...",
          "TAGS": ["Urgent", "2x Rate"],
          "MILEAGE": 208.56,
          "WORK_TYPE": "Construction"
        },
        "account": {
          "name": "Acme Corp",
          "key": "ACME"
        },
        "team": {
          "name": "Mobile Developers",
          "key": "MOBILE"
        },
        "functionRole": {
          "name": "QA",
          "key": "QA"
        }
      }
    }
  ]
}

Breakdown of the Metadata

Let's go step by step to understand each part of this data structure and what it represents:

1. Schema Version

JetTime uses a schema version field to ensure backward compatibility in case of future changes to the metadata structure. Use schema version 2, the latest version:

"schemaVersion": 2

2. Custom Time Categories

JetTime supports tracking multiple time categories, such as "Billable Time" and "Billable Overtime," recorded in seconds under the timeSpentSeconds object.

Each category key is defined in the app UI when you create and configure that custom time category.

Example:

"timeSpentSeconds": {
    "BILLABLE": 1800,
    "BILLABLE_OVER": 1200
}

3. Custom Work Log Fields

Custom fields defined in JetTime are stored under the fields object. These fields are flexible to accommodate numeric values, strings, tags, or boolean data.

Each field key is defined in the app UI when you create and configure that custom work log field.

Below is a breakdown of the example:

"fields": {
    "EXPENSE": 1800,
    "INTERNAL": false,
    "INTERNAL_NOTES": "Just between us, pssst...",
    "TAGS": ["Urgent", "2x Rate"],
    "MILEAGE": 208.56,
    "WORK_TYPE": "Construction"
}

4. Account Information

JetTime allows associating work logs with specific accounts, clients, or projects. This information is stored in the account object:

"account": {
    "name": "Acme Corp",
    "key": "ACME"
}

5. Team

The team the work was logged under, from JetTime's Teams. Same shape as the account:

"team": {
    "name": "Mobile Developers",
    "key": "MOBILE"
}

6. Function Role

The function role the person worked under on this entry — the axis that lets a report split one person's hours across the roles they play. The role pool is managed in the app UI, and each role has its own key:

"functionRole": {
    "name": "QA",
    "key": "QA"
}

Keys, Not Names

The account, the team, and the function role are all stored the same way: {"name": ..., "key": ...}, or null when the work log carries none. Only the key identifies the object. JetTime matches it against the current accounts, teams, and function roles, so it is the value to group and match on. The name is a readable snapshot of the moment the entry was written and is never read back — rename an account and older work logs still hold the old name.

Change an object's key in the app, though, and older work logs stop resolving to it: they still carry the old key, and reports show no account, team, or role for them. Give the object that key again and the history reconnects.

Next Steps

For more details on retrieving or creating work logs via the API, refer to the articles on Retrieving Work Logs via API and Logging Work via API.