jira-project-tasks

n8n community node to retrieve tasks for a project from a Jira Cloud-compatible REST API, with email + API key authentication and dynamic project selection.

Package Information

Released: 2 mo ago

Downloads: 0 weekly / 0 monthly

Latest Version: 0.9.0

Available Nodes

Documentation generating…

Jira Project Tasks

Retrieve tasks for a project from Jira

Documentation

n8n-nodes-jira-project-tasks

An n8n community node for retrieving Jira issues. It provides a single
operation, Get Tasks, which returns every issue created for a chosen project within a date
range.

n8n is a workflow automation platform with a fair-code license.

Installation
Credentials
Operations
Usage
Pagination
Error handling
Compatibility
Resources
Development
Version history
License

Installation

From the n8n editor (recommended)

Go to Settings > Community Nodes.
Select Install.
Enter n8n-nodes-jira-project-tasks.
Agree to the risks of using community nodes and select Install.

See n8n's community nodes installation guide
for more detail, including requirements for queue mode and other deployment types.

Manually, for a self-hosted instance

npm install n8n-nodes-jira-project-tasks

Restart n8n afterwards so it picks up the new node.

Credentials

This node authenticates against Jira Cloud with HTTP Basic Auth, using your Atlassian account
email and an API key as the password:

Authorization: Basic base64(email:apiKey)

To set up the credential:

Generate an API key (Atlassian calls this an "API token") at
id.atlassian.com/manage-profile/security/api-tokens.

In n8n, create a new Jira Project Tasks API credential and fill in:

Field	Description
Jira Base URL	Your Jira site's base URL, no trailing slash (e.g. `https://your-domain.atlassian.net`)
Email	The email address of the Atlassian account the API key belongs to
API Key	The key generated in step 1

Select Test to verify the credential. This calls GET /rest/api/3/myself, Jira's "who am I"
endpoint, which only requires valid auth (no project data needs to exist yet).

Operations

Get Tasks

Retrieves every issue (any issue type - Task, Story, Bug, etc.) created in a project within a
date range.

Parameter	Type	Required	Description
Project	Options	Yes	Dynamically loaded from `GET /rest/api/3/project/search`. The dropdown shows the project name; the value sent to the API is the project ID.
Start Date	DateTime	Yes	Only return issues created on or after this date/time.
End Date	DateTime	Yes	Only return issues created on or before this date/time.
Return All	Boolean	No	Whether to fetch every matching issue instead of stopping at Limit. Default `false`.
Limit	Number	No	Max number of issues to return. Only shown when Return All is off. Default `50`.

Internally this builds a JQL query and calls:

POST /rest/api/3/search/jql
{
  "jql": "project = \"<projectId>\" AND created >= \"<startDate>\" AND created <= \"<endDate>\" ORDER BY created ASC",
  "maxResults": 100,
  "fields": ["*all"]
}

and emits one n8n item per issue returned by the API. No issuetype filter is applied, so
issues of every type in the project are returned.

Time zone caveat: Start Date / End Date are converted to a JQL date-time literal
(yyyy-MM-dd HH:mm, since JQL doesn't accept seconds, milliseconds, or a UTC offset) using the
date/time components as-is. Jira then evaluates that literal in the site's configured time zone.
If your workflow's time zone differs from the Jira site's, results near the start/end boundary may
be off by that offset.

Get Work Log Report

Flattens the worklog entries embedded in Jira issue items (as produced by Get Tasks, or any
item shaped like a Jira issue with a fields.worklog property) into report rows, plus per-issue and
per-author summaries. This operation doesn't call the search API itself - it transforms whatever
issue items are already on the node's input, making one API call per issue only when needed (see
below).

Parameter	Type	Required	Description
Filter Start Date	DateTime	No	Only include worklog entries logged on or after this date/time. Leave empty for all.
Filter End Date	DateTime	No	Only include worklog entries logged on or before this date/time. Leave empty for all.
Output Format	Options	No	Detailed (default) or Flat - see below.
Include Issue Type Summary	Boolean	No	Detailed only. Adds `issueTypeSummary` rows - total hours per (issue type, author) pair. Default off.
Include Period Summary	Boolean	No	Detailed only. Adds `periodSummary` rows - total hours per author, bucketed by week or month. Default off.
Period Granularity	Options	No	Shown only when Include Period Summary is on. Week (default) or Month.
Include Estimate Vs Actual	Boolean	No	Detailed only. Adds an `estimateVsActual` row per issue - Jira's estimate vs. hours actually logged. Default off.

All four are independent and off by default - turn on only the ones a given report actually needs;
none of them change the entry rows or existing issueSummary/summary rows.

Output Format: Detailed (default)

For each input item, it emits:

One entry row per worklog entry:

{
  "rowType": "entry",
  "issueKey": "EX-101",
  "issueId": "10001",
  "issueType": "Task",
  "summary": "Fix login validation bug",
  "author": "Jane Doe",
  "authorAccountId": "dummy-account-id-1",
  "started": "2026-07-03T08:03:25.597-0500",
  "timeSpent": "10m",
  "timeSpentSeconds": 600,
  "timeSpentHours": 0.17,
  "comment": "",
  "worklogId": "16482"
}

One issueSummary row per issue that has at least one worklog entry (after filtering) - this is
where multiple contributors on the same task show up together, with a per-author breakdown for
that specific issue:

{
  "rowType": "issueSummary",
  "issueKey": "EX-105",
  "issueId": "10005",
  "issueType": "Bug",
  "summary": "Investigate intermittent timeout on checkout",
  "totalSeconds": 28800,
  "totalHours": 8,
  "entryCount": 2,
  "authorCount": 2,
  "byAuthor": [
    { "author": "Jane Doe", "authorAccountId": "dummy-account-id-1", "totalSeconds": 25200, "totalHours": 7 },
    { "author": "John Smith", "authorAccountId": "dummy-account-id-2", "totalSeconds": 3600, "totalHours": 1 }
  ]
}

One summary row per unique author across the whole report, after all input items have been
processed:

{
  "rowType": "summary",
  "author": "Jane Doe",
  "authorAccountId": "dummy-account-id-1",
  "totalSeconds": 186360,
  "totalHours": 51.77,
  "entryCount": 20,
  "byDateHours": { "2026-07-03": 5.67, "2026-07-06": 2.75 }
}

Use a Filter or IF node downstream on rowType (entry / issueSummary / summary / ...)
to route each kind separately - e.g. entries to a spreadsheet, issue summaries to a per-task report,
author summaries to a Slack message.

Optional extra summaries (Detailed mode only)

Each of these is off by default and adds its own rowType, alongside whichever of the rows above
are already emitted:

Include Issue Type Summary → one issueTypeSummary row per (issue type, author) pair, totaled
across the whole report - e.g. how much of Jane's time went to Bugs vs. Tasks:

{
  "rowType": "issueTypeSummary",
  "issueType": "Bug",
  "author": "Jane Doe",
  "authorAccountId": "dummy-account-id-1",
  "totalSeconds": 42300,
  "totalHours": 11.75,
  "entryCount": 6
}

Include Period Summary → one periodSummary row per (author, week-or-month) bucket, instead of
the daily byDateHours already in the summary row. Period Granularity picks Week (Monday-
starting bucket, keyed by that Monday's date) or Month (YYYY-MM):
```
{
  "rowType": "periodSummary",
  "periodGranularity": "week",
  "period": "2026-07-06",
  "author": "Jane Doe",
  "authorAccountId": "dummy-account-id-1",
  "totalSeconds": 66600,
  "totalHours": 18.5,
  "entryCount": 7
}
```
Include Estimate Vs Actual → one estimateVsActual row per issue, comparing Jira's
timeoriginalestimate/timeestimate fields against hours actually logged within this report's
scope (i.e. loggedHours respects Filter Start Date/End Date, so variance reflects what this
report covers, not the issue's all-time logged total). originalEstimateHours and
varianceHours are null when the issue has no original estimate set:
```
{
  "rowType": "estimateVsActual",
  "issueKey": "EX-101",
  "issueId": "10001",
  "issueType": "Task",
  "summary": "Fix login validation bug",
  "originalEstimateSeconds": 288000,
  "originalEstimateHours": 80,
  "remainingEstimateSeconds": 287400,
  "remainingEstimateHours": 79.83,
  "loggedSeconds": 600,
  "loggedHours": 0.17,
  "varianceSeconds": 287400,
  "varianceHours": 79.83
}
```
A positive varianceHours means under the original estimate; negative means over.

Output Format: Flat (CSV-ready)

Emits only the entry-level data - one row per worklog entry, every row with identical columns and
no rowType field:

{
  "issueKey": "EX-101",
  "issueId": "10001",
  "issueType": "Task",
  "summary": "Fix login validation bug",
  "author": "Jane Doe",
  "authorAccountId": "dummy-account-id-1",
  "started": "2026-07-03T08:03:25.597-0500",
  "timeSpent": "10m",
  "timeSpentSeconds": 600,
  "timeSpentHours": 0.17,
  "comment": "",
  "worklogId": "16482"
}

No issue-level or author-level summary rows are emitted in this mode - use it when you want to feed
the output straight into Convert to File (CSV) or a spreadsheet node without a Filter/Switch
step first. Switch to Detailed if you want the issueSummary/summary rollups instead.

comment is plain text, flattened from Jira's Atlassian Document Format (rich text) - formatting is
lost, but the text content is preserved.

Truncated worklogs: Jira's search endpoints embed at most 20 worklog entries per issue
(fields.worklog.maxResults). If an issue's fields.worklog.total exceeds that, this operation
automatically fetches the complete list via GET /rest/api/3/issue/{issueId}/worklog (paginated)
before building rows, so no worklog entries are silently dropped for high-activity issues.

Usage

A typical workflow:

Add a Jira Project Tasks node and attach your Jira Project Tasks API credential.
Set Operation to Get Tasks.
Pick a Project from the dropdown (or supply a project ID directly via an expression).
Set Start Date / End Date to the range you want tasks for.
Leave Return All off and set a Limit for quick tests; turn it on to pull every task in
the range once you're ready.

Each output item is the raw Jira issue object as returned by the API — pass it directly into a
Filter, Set, or downstream node to shape it further.

To turn that into a work log report, add a second Jira Project Tasks node after it (same
credential), set its Operation to Get Work Log Report, and connect the first node's output
into it. No further configuration is required unless you want to narrow the date range further with
Filter Start Date / Filter End Date.

A ready-to-import example wiring this up end to end - trigger → Get Tasks → Get Work Log Report →
split entries/issue summaries/author summaries by rowType (via a Switch node) - is at
workflows/get-tasks-and-worklog-report.json. This
is optional: the node itself needs no file, just a live connection from Get Tasks (or any item
shaped like a Jira issue) - importing the example only saves you from wiring the canvas by hand.
Import it via n8n's Import from File (or paste its contents via Import from URL/Clipboard),
then reassign the credential on both Jira Project Tasks nodes and adjust Project/dates to
your own project. Connect the three NoOp placeholder nodes to wherever each part of the report
should actually go (Google Sheets, Slack, email, etc.).

If you're new to n8n, see the Try it out documentation for a
general introduction to building workflows.

Pagination

Projects (GET /rest/api/3/project/search) page via startAt/maxResults, continuing until
the response reports isLast: true. The dropdown always loads the full project list.
Issues (POST /rest/api/3/search/jql) page via a nextPageToken cursor rather than
offset/limit - Jira's current search endpoint doesn't return a total count. Fetching continues
until a response omits nextPageToken.
When Return All is off, fetching stops as soon as Limit issues have been collected, and
the last page's results are truncated to exactly Limit.

See nodes/JiraProjectTasks/GenericFunctions.ts for
the implementation.

Error handling

Failed HTTP requests are wrapped in NodeApiError, surfacing the API's status code and response
body in the workflow error.
Missing or invalid parameters (e.g. no project selected) raise NodeOperationError before any
request is made.
If Continue On Fail is enabled on the node, per-item errors are emitted as
{ error: <message> } items instead of stopping the workflow.

Compatibility

Requires n8n's programmatic-style community node architecture (n8nNodesApiVersion: 1).
Built and tested against n8n-workflow ^1.70.0.
No known version-specific incompatibilities.

Resources

Development

npm install
npm run build    # compile TypeScript and copy icons into dist/
npm run lint     # eslint, including n8n community node rules
npm run format   # prettier --write

To try the node locally, link the package into your n8n custom nodes directory
(~/.n8n/custom/), or follow n8n's
node development environment guide.

Version history

Version	Changes
0.9.0	Added three independent, off-by-default report additions to Get Work Log Report: Include Issue Type Summary (`issueTypeSummary` rows), Include Period Summary (`periodSummary` rows, weekly/monthly), Include Estimate Vs Actual (`estimateVsActual` rows). None change existing row shapes.
0.8.0	Added Output Format to Get Work Log Report: `Detailed` (existing entry/issueSummary/summary rows) or `Flat` (CSV-ready, one uniform row per worklog entry, no summaries).
0.7.1	Added `issueType` (Task/Bug/Story/etc.) to Get Work Log Report's `entry` and `issueSummary` rows. README examples now use placeholder names/data instead of real ones.
0.7.0	Added `issueSummary` rows to Get Work Log Report: per-issue totals with a per-author breakdown, so multiple contributors on the same task show up together. Updated the example workflow's split to 3-way (entries/issue summaries/author summaries).
0.6.1	Added example workflow (`workflows/get-tasks-and-worklog-report.json`) wiring Get Tasks → Get Work Log Report → entry/summary split.
0.6.0	Added Get Work Log Report operation: flattens issue worklog entries into report rows plus a per-author summary, with auto-fetch for truncated worklogs.
0.5.0	Get Tasks now calls real Jira issue search (`POST /rest/api/3/search/jql`), filtering by `created` date, all issue types, cursor pagination.
0.4.1	Fixed Project dropdown: now calls the real Jira `GET /rest/api/3/project/search` endpoint (paginated) instead of the placeholder `/projects`.
0.4.0	Renamed package/node/credential to Jira Project Tasks (`n8n-nodes-jira-project-tasks`, `jiraProjectTasks`, `jiraProjectTasksApi`).
0.3.0	Renamed credential field `apiToken` to `apiKey` (Base URL, Email, API Key).
0.2.1	README overhaul: installation steps, usage walkthrough, compatibility, resources, version history.
0.2.0	Switched credential from a Bearer API key to Jira Cloud-style Basic Auth (Base URL, Email, API Token).
0.1.0	Initial release: Get Tasks operation, dynamic Project dropdown, pagination, error handling.

License

MIT

jira-project-tasks

Package Information

Available Nodes

Documentation

n8n-nodes-jira-project-tasks

Table of contents

Installation

From the n8n editor (recommended)

Manually, for a self-hosted instance

Credentials

Operations

Get Tasks

Get Work Log Report

Output Format: Detailed (default)

Optional extra summaries (Detailed mode only)

Output Format: Flat (CSV-ready)

Usage

Pagination

Error handling

Compatibility

Resources

Development

Version history

License

Discussion

jira-project-tasksInstall

Package Information

Available Nodes

Documentation

n8n-nodes-jira-project-tasks

Table of contents

Installation

From the n8n editor (recommended)

Manually, for a self-hosted instance

Credentials

Operations

Get Tasks

Get Work Log Report

Output Format: Detailed (default)

Optional extra summaries (Detailed mode only)

Output Format: Flat (CSV-ready)

Usage

Pagination

Error handling

Compatibility

Resources

Development

Version history

License

Discussion

jira-project-tasks