apache / apache/rocketmq-dashboard

[Studio][Feature] Edit topic configuration (queues, perm, remark) from the topic page

Open
#4,248 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
1.4k
Forks
683
Avg merge
2d 14h
Merged PRs (30d)
58

Description

## 1. Requested feature and source

Let operators **edit a topic's configuration from the UI** — queue counts, permission and remark — instead of only creating and deleting topics.

Source: the parent classic dashboard ships this as the row action "Topic CONFIG" (`frontend-new/src/pages/Topic/topic.jsx:498-500`), which opens `TopicModifyDialog` in update mode (`frontend-new/src/components/topic/TopicModifyDialog.jsx`, `bIsUpdate`): name and type are disabled while write/read queue counts and perm stay editable, submitting through `createOrUpdateTopic` (`frontend-new/src/api/remoteApi/remoteApi.js:674`).

## 2. Use case and impact

Resizing queues and tightening permissions (RW → RO/WO) is routine topic lifecycle management in the classic dashboard. Studio's topic page offers detail / send / delete only, so these operations require CLI access today.

The gap is an omission, not a design decision:

- The server endpoint already exists and is fully implemented for **all three providers** (`TopicController.updateTopic` → `ApacheInstanceProvider` / `AliyunInstanceProvider` / `TencentInstanceProvider`).
- The project's own API reference documents it as a supported operation (`docs/api-spec.md` §5.4 `POST /api/topics/update`).
- The frontend service wrapper exists (`web/src/services/topicService.ts` `updateTopic`, with demo-mode support) but **no page calls it** — the Apache provider even carries a comment about preserving values "on partial updates (e.g. perm or remark only)", written for update callers that never arrived in the UI.

## 3. Why it matters

- Parity with the parent project's topic management.
- Unlocks the documented, backend-complete update API for UI users without new server code.
- Cloud instances benefit too: the Aliyun/Tencent providers implement remark(-only) updates, matching what those APIs support.

## 4. Expected behavior / acceptance criteria

1. Topic rows expose a config edit action that opens the existing create dialog in edit mode, prefilled with the row's saved values.
2. Following the classic dialog semantics, name and type are disabled in edit mode; write/read queue counts, perm and remark are editable for Apache instances. Cloud instances keep the create dialog's vendor gating (no queue/perm fields — remark-only update, matching the Aliyun/Tencent provider implementations).
3. Submitting calls `updateTopic` with the selected instance id, then reloads the server-paged list; the create flow keeps working exactly as before (a cancelled edit must not turn the next create into an update).

## 5. Related PR

Fix: #4249.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the topic page and dialog behavior cited in the issue: frontend-new/src/pages/Topic/topic.jsx and frontend-new/src/components/topic/TopicModifyDialog.jsx. Then inspect web/src/services/topicService.ts for updateTopic and the API reference at docs/api-spec.md §5.4. Done means row edits follow the stated vendor-specific fields, call updateTopic, refresh the server-paged list, and leave create behavior intact; verify by exercising both flows.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, react, typescript
Domain
frontend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.