apache / apache/rocketmq-dashboard
[Studio][Feature] Edit topic configuration (queues, perm, remark) from the topic page
- 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