10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links

10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links

Quick Summary: Blueprint objective 7.2 covers four site-wide features that Jira admins configure: time tracking (enabling it, and how days and weeks convert to hours), issue linking (link types plus the Link Issues permission), attachments (enablement and size limits), and application links (connecting Jira to other Atlassian products and instances). Each has a global switch and a project-level permission that must both allow the action.

---

Global Time Tracking Configuration

Time tracking lets teams estimate work and log the time they spend. It's enabled by default, and you don't lose existing data if you disable and later re-enable it. Jira admins configure it in Settings > Issues (Work items) > Time tracking (under Issue features).

+--------------------------------------------------------------------------+
|                   GLOBAL TIME TRACKING CONFIGURATION                     |
+--------------------------------------------------------------------------+
|  SETTING                    | DEFAULT VALUE | OPERATIONAL IMPACT         |
|-----------------------------+---------------+----------------------------|
|  Working hours per day      | 8             | Defines '1d' conversion    |
|  Working days per week      | 5             | Defines '1w' conversion    |
|  Time display format        | Pretty        | Pretty, Days, or Hours     |
|  Default unit               | Minute        | Minute, Hour, Day, or Week |
|  Copy comment to work desc. | Configurable  | Copies worklog comments    |
+--------------------------------------------------------------------------+

Conversion Mathematics: Days and Weeks

Jira does not treat a day as 24 astronomical hours or a week as 7 calendar days. Instead, it converts durations based on the administrator's configured work parameters:

• Working Hours per Day: By default, Jira sets this to 8 hours. If a developer logs 1d, Jira registers 8 hours of work. If an organization operates on a 7.5-hour workday, logging 1d will misrepresent capacity unless this setting is updated to 7.5.
• Working Days per Week: By default, Jira sets this to 5 days. If a developer logs 1w, Jira calculates 5 days * 8 hours = 40 hours. If an enterprise shifts to a 4-day workweek, this parameter must be updated to 4 so that 1w equals 32 hours.

Time Display Formats

Administrators control how time values render across issue views, worklog tabs, and reports:

• Pretty Format (Default): Displays human-friendly compound strings (e.g., 2 weeks, 3 days, 4 hours, 30 minutes).
• Days Format: Expresses durations in days and hours (e.g., 13d 4h 30m).
• Hours Format: Expresses all durations strictly in cumulative hours (e.g., 108h 30m). Often preferred by accounting and professional services teams billing clients on hourly contracts.

Default Time Unit

When a user types a bare numeric value into an estimate or worklog field without specifying a unit (e.g., entering 4 instead of 4h):

• If Default Time Unit is Minute, 4 converts to 4m.
• If Default Time Unit is Hour, 4 converts to 4h.
• If Default Time Unit is Day, 4 converts to 4d (32 hours under an 8h workday!). Best practice is setting this to Hour or Minute to prevent catastrophic estimation errors.

[!IMPORTANT] Working hours per day and days per week accept decimal values (for example, 7.5 hours). Marketplace apps can also replace Jira's built-in time tracking as the time tracking provider, selected on the same settings page.

Troubleshooting Time Tracking

---

Issue Linking: Architecture & Link Types

Issue linking establishes semantic, two-way relationships between issues without changing the parent-child hierarchy. Jira admins configure it in Settings > Issues (Work items) > Issue linking (under Issue features).

+--------------------------------------------------------------------------+
|                       ISSUE LINK TYPE ARCHITECTURE                       |
+--------------------------------------------------------------------------+
|   [ SOURCE ISSUE: PROJ-101 ]                                             |
|         |                                                                |
|         |--- (Outward Description: 'blocks') ----------------------->   |
|         |                                                           |    |
|         v                                                           v    |
|   [ TARGET ISSUE: PROJ-202 ]                                             |
|         ^                                                                |
|         |--- (Inward Description: 'is blocked by') ------------------|   |
+--------------------------------------------------------------------------+

Anatomical Structure of a Link Type

Every issue link type consists of three distinct attributes:

1. Name: The internal administrative label (e.g., Blocks, Relates, Cloners, Duplicate).
2. Outward Description: Describes the relationship looking from the source issue toward the target issue (e.g., blocks, relates to, clones, duplicates).
3. Inward Description: Describes the relationship looking from the target issue back toward the source issue (e.g., is blocked by, relates to, is cloned by, is duplicated by).

Standard System Link Types

Global Activation vs. Project Permissions

A key exam point involves the two-tier governance of Issue Linking:

• Global Feature Enablement: Issue Linking must be enabled globally under Issue features. If disabled, the entire linking interface disappears instance-wide.
• Project Permission Scheme: Even when enabled globally, a user cannot link issues unless they hold the Link Issues project permission. Linking issues in two different projects requires Link Issues in both projects.
• Deleting a link type: Jira asks what to do with existing links of that type. You can move them to another link type or delete them.

---

Attachment Settings & Upload Limits

File attachments allow teams to attach screenshots, logs, documents, and specifications to issues. Attachments are enabled by default. Jira admins manage them in Settings > System > Advanced > Attachments (Edit settings).

+--------------------------------------------------------------------------+
|                       GLOBAL ATTACHMENT SETTINGS                         |
+--------------------------------------------------------------------------+
|  SETTING                    | JIRA CLOUD DEFAULT | MAXIMUM LIMIT         |
|-----------------------------+--------------------+-----------------------|
|  Attachments Enabled        | ON (Enabled)       | Toggle ON / OFF       |
|  Maximum size per file      | 1 GB               | Admin can change it   |
|  Thumbnail Generation       | ON (Enabled)       | Toggle ON / OFF       |
|  ZIP Support (Archive View) | ON (Enabled)       | Toggle ON / OFF       |
+--------------------------------------------------------------------------+

Key Parameters

• Attachment Size Limit: By default, the maximum size of any one file is 1 GB, and a Jira admin can change this limit. A changed limit applies to new uploads, not to files already attached.
• Other limits: an issue can hold up to 2,000 attachments. Total file storage depends on the plan: 2 GB per app on Free, 250 GB per app on Standard, and unlimited on Premium.
• Create screen: to attach files while creating an issue, the Attachment field must not be hidden in the field configuration for that issue type.
• Thumbnail Generation: Automatically renders inline thumbnail previews for common image formats (.png, .jpg, .gif). Disabling thumbnails displays files as plain download links.
• ZIP Support: When enabled, users can click on a .zip attachment to inspect the archive's internal folder and file contents directly in the Jira issue view without downloading the archive.

Required Permissions for Attachments

Regardless of global settings, users must hold explicit permissions within the project's permission scheme:

• Create Attachments: Required to upload files to an issue.
• Delete Own Attachments: Allows a user to delete files they personally uploaded.
• Delete All Attachments: Required to remove files uploaded by other team members (typically granted to Project Administrators or Leads).

---

Application Links and Instance Links

Blueprint 7.2 also names application and instance links. An application link connects Jira to another application so the two can exchange information. Examples include Confluence, Bitbucket, or another Jira instance, including self-managed Data Center products. Links make possible features such as showing Confluence pages on issues, displaying development information, and linking issues across instances.

Key points for the exam:

• Atlassian Cloud products on the same site connect automatically. You don't create an application link between Jira and Confluence when both run on the same Cloud site.
• You configure application links (Jira admin, in the products/apps area of Jira settings) when connecting to products outside your site, such as a Jira or Confluence Data Center instance, or another Cloud site.
• Remote issue links (links from an issue to an issue on another linked instance, or to a web page) are subject to the same Link Issues permission as ordinary links.
• Troubleshooting: if cross-product features stop working, check that the application link is still connected and that the authentication between the two applications is still valid (for example, after a URL change or certificate update).

---

Global Switch Plus Project Permission

Each feature in this section has two gates, and exam questions often break one of them: