Repository navigation
Jira Premium Assessment
Reviewed 2026-10-18 (Asia/Tokyo). Current expanded implementation: Premium workspace; accepted on Helm 224; its installation administration (sandboxes, release tracks, IP allowlist, admin insights) was removed in 1.113.57. Historical delivery slices below remain evidence, not the current feature inventory. This is a capability and delivery inventory, not a claim of complete Jira parity. The owner's screenshot specifically asks for Task → subtask → subtask → further subtasks, with drill-down and project-permission-controlled drag-and-drop.
The colleague says their biggest Jira limitation is being unable to break a parent task down through multiple levels. The example is a recursive task hierarchy, rather than simply initiatives above epics. The earlier message says drag-and-drop becomes available after receiving project permission. ServiceOps already enforces board edits by project membership; it previously rejected subtasks beneath subtasks and hid their child section.
- Reuse
work_item.parent_id; no new parallel task model or migration. - Stories/tasks/bugs can belong to an epic. Subtasks can belong to a story, task, bug or another subtask. Epics remain roots.
- Cycle checks and same-project/tenant validation apply to creation and reparenting. Project-row locks serialize hierarchy changes on PostgreSQL.
- Recursive SQL queries use
UNIONto terminate even on damaged cyclic data. Python traversal, breadcrumb assembly and branch cloning avoid recursive call-stack limits. There is no product depth setting; database and page rendering limits still apply. - Read-only boards explain that member access is required to move cards or edit work items; no editing capability is granted by the message.
- Every subtask shows its children and an Add action, and breadcrumbs include the complete ancestor path.
- Clone includes every descendant when requested; move carries the whole nested branch and preserves moved-key redirects. Converting a parent into a subtask retains descendants when the proposed hierarchy is valid.
- Deleting an intermediate subtask reparents its children to its parent. Deleting a root promotes direct child subtasks to tasks, retaining their descendants and recording the changed parent/type in history.
- Projects → Cross-project planning shows visible-project date rollups, done/total progress, overdue and unscheduled work, and recorded remaining effort. SQL aggregates cover all items, with 50 projects per page.
- The dependency report includes only blocking links whose source and target are visible; hidden projects and link counts are not disclosed. At most 100 links from the current page are shown with an explicit truncation notice.
- The original date-shift preview has been superseded by persistent drafts, named program scenarios, capacity allocation and review/apply. See Project planning.
Validation and deployment evidence is recorded in Nested project work delivery.
Sources checked against Atlassian's current product and support pages. Product packaging changes; this is a dated functional comparison, not a pricing promise. Existing features below are source-inspected; accepted behavior and its limits are recorded in the linked delivery evidence.
| Capability | ServiceOps position | Work still required |
|---|---|---|
| Recursive tasks below subtasks | Implemented in this slice | Deep browser/performance evidence is bounded to tested cases; not an unlimited-scale claim |
| Private/open projects; role-controlled board drag | Existing | Custom permission schemes remain B-455 |
| Project archive/restore | Existing | Work-item archive and trash retention need separate design |
| Cross-project overview | Persistent owned multi-project plans, source scope and summary | Broader configurable portfolio reporting remains open |
| Project date rollup | Derived parent spans, drag/resize proposals, selective apply | Bounded planning, not unlimited scale |
| Dependencies | Visible dependency curves/report, cycle rejection and finish-to-start scheduling | Additional dependency types and scheduling modes remain open |
| What-if planning | Persistent date drafts and named program allocation/settings scenarios | Rich side-by-side scenario diff remains open |
| Hierarchy above epic (initiative, program, custom levels) | Custom named plan nodes with linked work, combined tree and deduplicated rollups | Canonical workflow issue-type schemes remain distinct |
| Team capacity and velocity | Team hours/points per iteration, warnings and conservative auto-allocation; sprint velocity | Leave/absence calendars and optimal leveling remain open |
| Automatic scheduling | Dependency/person-date scheduling plus unit-safe program capacity fitting; review before apply | Bounded engine; availability calendars remain open |
| Multi-project releases | Plan release view across visible project versions | A linked cross-project release entity/lifecycle remains open |
| Planning views and grouping | Timeline, combined structure, program, team, calendar, grouped backlog and saved plan views | Additional configurable grouping remains open |
| JQL and issue navigator | Core navigator and history/reporting continuation accepted on Helm 214 | B-450: WAS/state history, remaining functions, autocomplete and full navigator capabilities remain. Contract |
| Saved/shared filters and subscriptions | Owned/shared definitions and favourites accepted on Helm 213 | Role-specific sharing and scheduled subscriptions remain B-450. Contract |
| Scrum backlog, sprints, parallel sprints | Implemented and accepted on Helm 217/220 | See Sprints and Planning |
| Agile reporting (velocity, burndown, control chart) | Velocity, sprint scope/history, daily burndown, creation/resolution and lead-time reports | Control chart and additional flow analytics remain open |
| Workflow/custom field/screen schemes | Partial: project statuses and ITSM workflows | Project-specific schemes, B-454 |
| Project issue security/custom roles | Partial: project roles and comment visibility | B-455 |
| Configurable project dashboards/gadgets | Partial: platform dashboards and project overview | B-456 |
| Cross-project automation | Work-item event rules, visual conditions/branches/actions, preview, audit, permissions, transactional rollback and budgets | External actions, scheduled triggers and retry queues remain open |
| AI | Existing policy-controlled platform assistance | Project-aware search/drafts and evaluation, B-458; not Rovo parity |
| Development integrations, smart commits, deployment panel | Missing in project module | B-458 |
| Jira import and CSV project import/export | Missing in project module | B-450/B-458; CMDB import is a separate feature |
| Webhooks and API parity | Partial: scoped project/work-item REST API | B-458; schemas and delivery guarantees must be explicit |
| Unlimited storage | Not an application guarantee | Actual storage, quotas, growth monitoring and backup capacity are operator responsibilities |
| 99.9% financially-backed uptime | Not a code feature | Requires HA design, SLO monitoring, incident process and a service contract |
| 24/7 support / response-time commitment | Not a code feature | Requires staffed support and a support agreement |
| Atlassian Marketplace/Guard/Confluence | Separate vendor products | Build documented integrations where needed; do not claim bundled product parity |
The owner explicitly confirmed both Jira project planning and Jira Service Management on 2026-10-17, superseding the earlier project-only restriction. JSM Premium assessment and confirmed gap implementation are in scope. Extend the existing ITSM workflows and shared platform services.
| Area | Existing ServiceOps capability | Premium-specific gap |
|---|---|---|
| Incidents, major incidents, problems and PIR | Existing operational workflows | Revalidate advanced alert correlation, event integrations and incident command UX before claiming equivalent coverage |
| Change management | Existing risk, planned windows, implementation/test/backout, approvals and CCB | Provider-specific AI risk and CI/CD deployment gating need contract and tests |
| Assets/configuration | Existing CMDB, assets, ownership, service relationships and NetBox | Arbitrary Assets object schemas, discovery parity and AQL require a separate inventory |
| Service catalog, requests, SLAs and knowledge | Existing | No assumption that all vendor form, portal and reporting options match |
| AI virtual service agent | Existing human-reviewed assistant | Intent flows, customer-facing resolution tracking, confidence gates and human handoff are not established as equivalent |
| Automation | Existing platform rules | Full cross-project and external-tool orchestration is not verified parity |
| Storage, uptime and support | Not provided; installation administration was removed in 1.113.57 | Product-versus-service distinction applies |
Track JSM Premium assessment and implementation as B-471; reuse the existing ITSM module. This scope confirmation does not mark any unimplemented feature complete.
- B-468: finish the screenshot's nested-task use case, security regressions, browser/accessibility and live acceptance.
- B-469: portfolio baseline: date rollups, dependency report and read-only schedule preview, with tenant/private-project tests.
- B-450 → B-451 → B-452: shared query/filter, sprint and report foundations from the existing plan.
- B-453/B-459: interactive timelines, persistent plans, hierarchy above epic, named scenarios, team capacity and constraint scheduling. Keep work estimates separate from actual capacity; do not double-count parent and child effort as a capacity allocation.
- B-454 → B-455 → B-457: reusable project schemes and cross-project automation with authorization checks at execution time.
- B-458/B-470/B-471: integrations and import, operational Premium capabilities and any confirmed ITSM gaps.
Each slice requires negative authorization/tenant tests, transactional rollback checks, current OpenAPI where interfaces change, accessible desktop/mobile journeys, SQLite/PostgreSQL validation and the repository's MicroK8s acceptance process. Full Premium parity remains open until every applicable row has independently verified implementation and operational commitments have an owner.
- Jira Premium product capabilities
- Jira plan comparison
- Plans in Jira Premium
- Jira advanced planning overview
- Service Collection / Jira Service Management comparison
Sprint lifecycle/backlog and core sprint reports are now accepted on Helm 217. This advances B-450/B-451/B-452 but does not complete them or the broader Jira/JSM programme. Supported scope and remaining work · Acceptance evidence.