Mirrors/super-productivity
1
0
Fork 0
mirror of https://github.com/johannesjo/super-productivity.git synced 2026-07-17 16:37:43 +00:00
Code Issues Projects Releases Wiki Activity
super-productivity/docs/wiki/3.07-Issue-Integration-Comparison.md
Johannes Millan c7d6131db8
feat(plainspace): Collaborate-on-Plainspace discovery + smoother connect (#8649) 
* feat(plainspace): add Collaborate action to project context menu

Surface Plainspace sharing from the project context menu (active, non-Inbox,
not-yet-shared projects) so it can be discovered at the moment of collaboration
intent, reusing PlainspaceShareService. A new selectIsProjectSharedOnPlainspace
selector hides the action once a project is shared to avoid provisioning a
duplicate space on a repeat click.

* docs(plainspace): document collaboration in wiki

Add Plainspace to the issue-integration comparison (matrix + per-provider
section) and a how-to for sharing a project via the project menu, including the
network/privacy caveat.

* feat(plainspace): place Collaborate action below the share-list item

Group the two share/export actions and lift Collaborate higher for
discoverability. Gated to active, non-inbox, not-already-shared projects.

* fix(plainspace): smoother first-run connect and value-first dialog

Pre-check connectivity and revalidate a stored token before the space
picker, so a stale/foreign token routes to the connect dialog and an
offline state shows a calm message instead of the raw 'check your token'
picker error. Make the connect dialog value-first: lead with what you
get, drop the 4-step how-to and email hint in favor of one short pointer
(token-creation guidance moves to plainspace.org).

* docs(plans): dedicated from-Super-Productivity flow on plainspace.org

Open plan for a guided token/connect flow on plainspace.org when a user
arrives from SP (Model A manual token, Model B OAuth-style handoff).

* refactor(plainspace): drop redundant connect pre-check (multi-review)

The space picker already detects a stale token and offers a reconnect
(#8616), so the revalidate() pre-check duplicated that path, cost an
extra GET /me, and forced re-auth on a valid token during a transient
server blip. Keep only the one-line offline guard; drop revalidate(),
the discriminated union, and the unnecessary _isOnline() seam (navigator
.onLine is spyable in the runner). Fix stale doc comments and document
the disabled-provider trade-off in the selector.

* feat(plainspace): show brand icon in the connect dialog title

* feat(plainspace): deep-link connect dialog to the from-SP onboarding flow

Point the dialog's 'Open Plainspace' link at the dedicated
/connect/super-productivity entrypoint (which guides token creation)
instead of the bare marketing host, closing the connect-flow funnel leak.

* feat(plainspace): bounce back to the app after connecting (desktop)

Append a validated `?return=superproductivity://plainspace-connect` deep
link to the connect URL, gated on IS_ELECTRON (only desktop registers the
scheme — web/mobile would get dead buttons). Handle that action in the
Electron protocol handler by surfacing the window, so the connect page's
"Open Super Productivity" button re-focuses the app.

Desktop-only; needs an on-device check.
2026-07-01 16:39:34 +02:00

15 KiB
Raw Permalink Blame History

Issue Integration Comparison

This reference lists which capabilities each issue provider supports: issue import, status transitions, time tracking/worklog submission, comments, subtasks, attachments, filtering options, auto-import to backlog, story points, due dates, and other provider-specific behavior. Use it to compare providers or to see what to expect when you enable one.

For an overview of how integrations work and how to set them up, see 4.24-Integrations and 2.07-Manage-Task-Integrations. For a comparison of sync providers (WebDAV, Dropbox, SuperSync, local file), see 3.08-Sync-Integration-Comparison.

Core Capabilities (All Providers)

Every issue provider supports the same basic operations: checking that the integration is enabled, testing the connection, opening the issue in the external system, fetching an issue by ID, searching issues, and adding an issue as a task in the app. All providers also support refreshing already-imported tasks so that changes in the external system (title, status, etc.) are reflected locally. Each provider has a configurable poll interval (or none) for how often the app checks for updates. Beyond that, support for status transitions, worklogs, comments, subtasks, attachments, and filtering depends on the provider and the external API.

Feature Matrix Summary

Provider Import Status Worklog Comments Subtasks Attachments Filtering Auto-import Story pts Due dates
Jira Yes Yes Yes Yes Yes Yes JQL Yes Yes —
GitHub Yes No No Yes No No Repo, assignee Yes — —
GitLab Yes Auto (closed) Deprecated Yes No No Project, scope — Weight Yes
Gitea Yes No No No No No Repo, scope, labels Last 100 — —
OpenProject Yes Yes Yes No No Yes Scope, status — Yes Yes
CalDAV Yes Config No No No No Category — — Yes
Calendar (iCal) Yes No No No No No Text search Today Duration Yes
Redmine Yes No No No No No Project, scope Last 100 — —
Trello Yes No No No No Yes Board Yes Yes —
Linear Yes Auto (state) No No No Yes Team, project Yes — —
Azure DevOps Yes No No No No No Project, scope, WIQL Config — Yes
ClickUp Yes Auto (status) No No Yes Yes Team Yes — —
Plainspace Yes Two-way No No No No Space Yes — Yes

Legend: Status = configurable or automatic status transitions; Worklog = time tracking submission to the external system; Auto-import = automatic import of new issues into backlog (or "Last 100" / "Today" where noted).

Per-Provider Details

1. Jira

  • Issue import: Full import with JQL search.
  • Status transitions: Configurable workflows (e.g. Open → In Progress → Done).
  • Worklog: Full worklog submission and time-spent tracking.
  • Comments: Comment tracking and display.
  • Subtasks: Subtask relationship tracking and import.
  • Attachments: Attachment mapping and display.
  • Filtering: JQL-based search; auto-import with custom JQL.
  • Story points: Custom field support.
  • Assignment: Re-assignment on task start; assignee update when marking done.

2. GitHub

  • Issue import: Issues and pull requests from repositories.
  • Status transitions: Not supported (issues are read-only from the app).
  • Worklog: Not supported.
  • Comments: Comment tracking with optional filter by username.
  • Filtering: Search within repo; backlog query; username-based comment filtering.
  • Auto-import: Configurable backlog query.

3. GitLab

  • Issue import: Full import from projects (cloud or self-hosted).
  • Status transitions: Issues auto-marked as done when closed in GitLab.
  • Worklog: Previously supported; now deprecated.
  • Comments: Comment tracking with optional filter by username.
  • Filtering: Project-based; scope (All, Assigned, Created); custom filter parameters.
  • Story points: Weight field mapping.
  • Due dates: Due date support.

4. Gitea

  • Issue import: Issues from repositories (self-hosted).
  • Status transitions / Worklog / Comments / Subtasks / Attachments: Not supported.
  • Filtering: Repository-based; scope (All, Created by me, Assigned to me); optional comma-separated label allowlist (AND match) and denylist (NONE match), both applied client-side and supporting scoped labels (scope/name). Also works against Forgejo. The labels= query is still sent to the server as a coarse pre-filter, but Gitea's /repos/{owner}/{repo}/issues and /repos/issues/search endpoints disagree on AND vs OR semantics (go-gitea/gitea#33509), so the client filter is the source of truth.
  • Auto-import: Last 100 issues for the project.

5. OpenProject

  • Issue import: Work packages with project filtering.
  • Status transitions: Full support with configurable workflows.
  • Worklog: Time entry submission with activity types.
  • Comments: Not tracked.
  • Subtasks: Not supported.
  • Attachments: Attachment upload support.
  • Filtering: Scope (e.g. created-by-me, assigned-to-me); status and username filtering.
  • Story points / Time estimates: Story point field and estimated time parsing/display.
  • Due dates: Start date support.
  • Progress: Percentage-done updates.

6. CalDAV

  • What it uses: The app requests VTODO components only. It does not read or display VEVENTs (calendar events). If your calendar has both events and tasks, only the tasks (VTODO) appear in the app.
  • Authentication: Requires login (username and password or equivalent) to the CalDAV server.
  • Issue import: Task/todo import from CalDAV. Sub-tasks may optionally be imported along with parent. Completion status can sync back to the server when enabled in configuration.
  • Status transitions: Supported when enabled in configuration.
  • Worklog / Comments / Subtasks / Attachments: Not supported.
  • Filtering: Category-based filtering.
  • Notes: Task notes/description support.
  • Due dates: Start date with time support.
  • Related tasks: Task relationship tracking.
  • URL format: For Nextcloud, use https://<NC-URL>/remote.php/dav/calendars/<USER>/<CALENDAR_NAME>/ from “Copy private link” (or the CalDAV URL), not the subscription/export link. For Vikunja, use the principal URL shown in Vikunja's CalDAV settings, e.g. https://<VIKUNJA-URL>/dav/principals/<USER>/, and set the CalDAV resource to the project name or project ID. Items without a valid VTODO are skipped.

7. Calendar (iCal)

  • What it uses: The app parses VEVENT components only from an iCal feed. It does not use VTODO (tasks). Events must have a valid start time (DTSTART); otherwise they are skipped. All-day events (date-only start) are included.
  • Authentication: No login. You only provide the calendar URL (subscription or export link).
  • Issue import: Calendar events (VEVENT) from iCal URLs. Events appear in the Schedule/Planner; event description becomes the task note. Completion and time/date changes are not synced back—the feed is read-only from the app’s perspective; if you change the task in the app, the external calendar is not updated.
  • Status transitions / Worklog / Comments / Subtasks / Attachments: Not supported.
  • Filtering: Text-based search in event titles. Calendar provider settings can also apply optional case-insensitive include and exclude regular expressions to event titles. The include filter acts as an allowlist; the exclude filter is applied afterward.
  • Auto-import: Current day events.
  • Time estimates: Event duration used as task time estimate.
  • Due dates: Event start time (all-day or timed).
  • Descriptions: Event description as task notes.
  • URL format (example Nextcloud): Use the “Copy subscription link” so the URL is in the correct form, e.g. https://<NC-URL>/remote.php/dav/public-calendars/<CALENDAR-ID>?export. Paste this in the app under “URL of the iCal source.” Do not use the “Copy private link”—that format is for CalDAV, not iCal.
  • Platform note: The Disable in web or Android app setting suppresses iCal requests in the browser and on Android, where WebView network restrictions can produce similar failures.

8. Redmine

  • Issue import: Issues from projects.
  • Status transitions / Worklog / Comments / Subtasks / Attachments: Not supported.
  • Filtering: Project-based; scope support; task search supports non-Latin subject matches.
  • Auto-import: Last 100 issues for the project.

9. Trello

  • Issue import: Cards from boards.
  • Status transitions / Worklog / Comments / Subtasks: Not supported.
  • Attachments: Attachment mapping and display.
  • Filtering: Board-based filtering.
  • Story points: Supported.
  • Auto-import: Automatic card import to backlog.

10. Linear

  • Issue import: Issues with team/project filtering.
  • Status transitions: Issues auto-marked as done based on state.
  • Worklog / Comments / Subtasks: Not supported.
  • Attachments: Attachment mapping and display.
  • Filtering: Team and project-based.
  • Auto-import: Automatic issue import to backlog.

11. Azure DevOps

  • Issue import: Work items from Azure DevOps Boards.
  • Status transitions / Worklog / Comments / Subtasks / Attachments: Not supported.
  • Filtering: Project-based; scope support (All, Created by me, Assigned to me); optional custom WIQL query for auto-import.
  • Auto-import: Configurable automatic backlog import limit, up to 200 work items. An optional WIQL query can fully override the auto-import query (scope, state filter, and ordering), for example to filter by iteration path, area path, or work item type. When empty, scope-based filtering is used.
  • Due dates: Due date, target date, or start date support.

12. ClickUp

  • Issue import: Tasks with team filtering.
  • Status transitions: Tasks auto-marked as done based on status.
  • Worklog / Comments: Not supported.
  • Subtasks: Full subtask support and relationship tracking.
  • Attachments: Attachment mapping and display.
  • Filtering: Team-based.
  • Auto-import: Automatic task import to backlog.

13. Plainspace

Plainspace is Super Productivity's own collaboration layer (a shared workspace at plainspace.org), so it behaves differently from the read-mostly issue trackers above. You connect a Space with a personal API token (pat_…), and the tasks assigned to you in that Space import into the bound project.

  • Issue import: Tasks assigned to you in the connected Space. A claim pool in the work view also lists unclaimed tasks you can claim into your list.
  • Status transitions: Two-way done sync — completing a task locally marks it done in Plainspace, and a task completed in Plainspace is marked done on the next poll.
  • Title & schedule: Two-way — renaming or rescheduling a task locally pushes back to Plainspace (dueWithTime ↔ scheduledAt), and changes made in Plainspace pull in on poll. Recurring tasks are flagged in the claim pool and task panel; the Plainspace server advances the schedule to the next occurrence.
  • Worklog / Comments / Subtasks / Attachments: Not supported.
  • Filtering: By Space (one provider instance per Space).
  • Auto-import: Assigned tasks auto-import into the bound project's backlog; the poll interval is 5 minutes. A task that leaves your Plainspace list (unassigned or removed) is automatically removed locally.
  • Sharing a project: You can turn an existing local project into a shared Space from the project context menu → Collaborate on Plainspace, or via the Collaborate on this project toggle when creating a project. This provisions a Space and a bound Plainspace provider in one step. See 2.07-Manage-Task-Integrations.

Implementation Notes

  • Broadest feature set: Jira and OpenProject support the most capabilities: configurable status transitions, worklog submission, and advanced filtering. OpenProject adds progress percentage and activity; Jira adds JQL, subtasks, and assignment handling.
  • Comment-focused: GitHub and GitLab offer solid issue import and comment tracking (with optional username filtering) but do not support worklog submission; GitLab worklog support is deprecated.
  • Subtask support: Besides Jira, only ClickUp supports full subtask import and relationship tracking among the listed providers.
  • Calendar-oriented: CalDAV and Calendar (iCal) are geared toward calendar/todo and event integration (categories, event duration, today's events) rather than full issue-tracking features. They are not interchangeable: iCal uses subscription URLs and VEVENT (events) only, with no login and no sync back; CalDAV uses server login and VTODO (tasks) only, with optional completion sync. Using the wrong link type (e.g. Nextcloud “private link” in iCal or “subscription link” in CalDAV) is a common cause of the integration not working; see 4.24-Integrations for the iCal vs CalDAV overview.
  • Auto-import and polling: Most providers support automatic polling for updates and many support auto-import of new issues into the backlog; exact behavior (e.g. "last 100" vs custom query) is provider-specific.
  • Collaboration vs. import: Plainspace is the only provider that is bidirectional and collaboration-oriented — it syncs done state, title, and schedule both ways and lets you share a local project as a shared Space. The other providers are primarily one-way imports from an external tracker.

Optional capabilities (e.g. subtasks, attachments, sending updates back to the external system) are implemented per provider depending on what the external API supports.

Related