Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

V2 POST /record-types/{id}/views creates views that crash the Planning UI view switcher ("Unsupported view type")

Open
  • Is something wrong?
#29 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
javascript
Domain
api, frontend

Research direction

Start at POST /v2/record-types/{recordTypeId}/views and compare its returned view with a UI-created view, then inspect ViewIcon.tsx and the view switcher entry point. Verify the initialization difference for API-created TIMELINE and TABLE views; done means those views render in the switcher without the Unsupported view type error.

Written by the indexing model from the issue text.

Description

Summary

Creating a view through the V2 API (POST /v2/record-types/{recordTypeId}/views) returns 201 Created and the view reads back correctly, but the Planning web UI crashes whenever that view is present in the record type's view switcher. The console throws:

Error: Unsupported view type: TIMELINE — at ViewIcon.tsx

and the page shows "Whoops! Something went wrong." Views created in the UI, and the default Table view auto-created with a record type, render normally — so the problem is specific to views created via the public V2 API.

Environment

  • Workfront Planning V2 API — https://<instance>.sb01.workfront.adobe.com/maestro/api/v2 (sandbox)
  • Auth: apiKey header
  • Observed: June 2026

Steps to reproduce

  1. Use a record type that has records with date fields (so a timeline can render).

  2. Create a view via the API:

    POST /v2/record-types/{recordTypeId}/views
Content-Type: application/json

{
  "name": "Roadmap",
  "type": "TIMELINE",
  "recordTypeId": "Rt...",
  "filter": [],
  "grouping": [{ "fieldId": "F...", "direction": "asc" }],
  "sorting": [],
  "metadata": {
    "type": "TIMELINE",
    "startDateKey": "F...startDate",
    "endDateKey": "F...endDate",
    "timelineScale": "MONTH",
    "showRecordColoring": true
  }
}

    → 201 Created. GET /v2/record-types/{id}/views returns the view with type: "TIMELINE", the grouping, and the metadata, exactly as sent.

  3. Open that record type in the Planning UI and open the view switcher dropdown.

Actual result

The UI crashes ("Whoops! Something went wrong.") with a console error:

Error: Unsupported view type: TIMELINE
    at ViewIcon.tsx:25

The same occurs with "type": "TABLE" (Unsupported view type: TABLE). The crash fires as soon as the API-created view is in the switcher list — even when a different (working) view is selected — because the switcher renders an icon for every view.

Expected result

A view created via the API should render in the UI exactly like a view created in the UI.

Notes / investigation

  • I diffed an API-created TIMELINE view against a UI-created TIMELINE view of the same record type: the returned JSON is identical apart from id / name / grouping fieldId. So the property the UI's ViewIcon switches on is not present in the view's stored/returned payload — it appears to be state initialized only when a view is created in the UI (or for the auto-created Table view from record-type creation), and not by POST .../views.
  • The same record type's auto-created Table view renders fine, and UI-created views render fine — only API-created views crash.
  • PATCH /v2/views/{id} works (200). DELETE /v2/views/{id} sometimes returns 403. Setting isHidden: true on the API-created view removes it from the switcher and stops the crash (a usable workaround).

Impact

View configuration (timeline views, grouping, coloring) can't be provisioned via the API — it has to be done by hand in the UI. This blocks automated / templated workspace setup.

Request

Either fix POST /v2/record-types/{id}/views to fully initialize a view so the UI renders it, or document the required additional field/step (and ideally have the docs note that views must currently be created in the UI).

Happy to share request IDs and the exact before/after view JSON. I observed similar "created but not fully initialized" behavior on other V2 create endpoints (e.g. create-field dropping dateOptions / numberOptions), which I can file separately if useful.

Dominant language
JavaScript
Stars
0
Forks
2
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from AdobeDocs/Workfront-Planning-API

All issues in AdobeDocs/Workfront-Planning-API

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.