refactor: migrate system settings pages to ObjectView metadata-driven rendering#1139
refactor: migrate system settings pages to ObjectView metadata-driven rendering#1139
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
… rendering Replace hand-written HTML tables in all 5 system management pages (Users, Organizations, Roles, Permissions, Audit Log) with the ObjectView component from @object-ui/plugin-view. - Create shared SystemObjectViewPage component - Each page driven by systemObjects.ts metadata definitions - Automatic search, sort, filter, and CRUD from ObjectView - Admin-only CRUD controlled via ObjectView operations config - Audit log uses read-only mode (all mutations disabled) - Update 22 tests to validate new ObjectView integration - Update CHANGELOG.md and ROADMAP.md Agent-Logs-Url: https://github.com/objectstack-ai/objectui/sessions/5059a194-c7d8-47c0-a6d8-cafa43dea3e2 Co-authored-by: hotlong <50353452+hotlong@users.noreply.github.com>
…Page Agent-Logs-Url: https://github.com/objectstack-ai/objectui/sessions/5059a194-c7d8-47c0-a6d8-cafa43dea3e2 Co-authored-by: hotlong <50353452+hotlong@users.noreply.github.com>
|
@copilot 是否建议统一到系统标准路由,包括列表表页和记录详情页 |
是的,建议作为下一步增强。当前 PR 已将列表页统一到 ObjectView,接下来可以:
<Route path="users" element={<UserManagementPage />} />
<Route path="users/:recordId" element={<SystemRecordDetailPage objectName="sys_user" />} />这些改动超出当前 PR 的范围(本 PR 聚焦于列表页从手写表格迁移到 ObjectView),建议作为单独的 issue/PR 跟进。 |
|
@copilot 我的意思是每一个系统表就是一个标准的对象,如果把系统设置也定义为一个应用,那岂不是直接可以使用现有的系统路由,根本不用自己开发页面。 |
理解了,这个方向是完全可行的。当前 adapter 对 如果将系统对象注册为标准应用(例如 实现需要:
这个改动涉及 config 层 + metadata 层 + 路由层的联动,超出本 PR 范围。建议作为独立 issue 跟进,本 PR 的 |
There was a problem hiding this comment.
Pull request overview
Refactors the console’s system settings management pages to use the metadata-driven ObjectView (@object-ui/plugin-view) instead of hand-built tables and bespoke CRUD/fetch logic, leveraging systemObjects.ts as the source of truth.
Changes:
- Added a shared
SystemObjectViewPagewrapper that builds anObjectViewSchemafromsystemObjects.tsand rendersObjectViewwith the adapterdataSource. - Migrated Users/Orgs/Roles/Permissions/Audit Log pages to delegate rendering + CRUD gating to
SystemObjectViewPage. - Updated system page tests to mock
ObjectViewand assert schema configuration; updated ROADMAP/CHANGELOG accordingly.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| apps/console/src/pages/system/SystemObjectViewPage.tsx | New shared wrapper that maps systemObjects.ts metadata into an ObjectViewSchema and renders ObjectView. |
| apps/console/src/pages/system/UserManagementPage.tsx | Simplified to delegate to SystemObjectViewPage for sys_user. |
| apps/console/src/pages/system/OrgManagementPage.tsx | Simplified to delegate to SystemObjectViewPage for sys_org. |
| apps/console/src/pages/system/RoleManagementPage.tsx | Simplified to delegate to SystemObjectViewPage for sys_role. |
| apps/console/src/pages/system/PermissionManagementPage.tsx | Simplified to delegate to SystemObjectViewPage for sys_permission. |
| apps/console/src/pages/system/AuditLogPage.tsx | Simplified to delegate to SystemObjectViewPage for sys_audit_log in read-only mode. |
| apps/console/src/tests/SystemPages.test.tsx | Tests updated to mock @object-ui/plugin-view and assert ObjectView schema + dataSource wiring. |
| ROADMAP.md | Documents completion of “ObjectView-Driven System Pages”. |
| CHANGELOG.md | Notes the system pages refactor to ObjectView. |
| </div> | ||
| </div> | ||
|
|
||
| {dataSource && ( |
There was a problem hiding this comment.
ObjectView is not rendered while dataSource is null. Since AdapterProvider initializes the adapter asynchronously, this can leave the page showing only the header (no loading/empty/error state) during initial load or reconnects. Consider rendering a loading indicator or a fallback message when dataSource is null (and/or disabling the page until the adapter is ready).
| {dataSource && ( | |
| {!dataSource ? ( | |
| <div | |
| className="flex items-center justify-center py-10 text-sm text-muted-foreground" | |
| data-testid={`system-page-${objectName}-loading`} | |
| > | |
| Preparing data connection. Please wait... | |
| </div> | |
| ) : ( |
| const viewDef = objDef.views?.[0]; | ||
| const canMutate = !readOnly && isAdmin; | ||
|
|
||
| const schema: ObjectViewSchema = { | ||
| type: 'object-view', | ||
| objectName, | ||
| showSearch: true, | ||
| showFilters: true, | ||
| showSort: true, | ||
| showCreate: canMutate, | ||
| table: { | ||
| columns: viewDef?.columns, | ||
| }, |
There was a problem hiding this comment.
The previous AuditLog page explicitly fetched with $orderby: { createdAt: 'desc' } (newest-first). The new schema does not set any default sort, so audit entries may render in an arbitrary/oldest-first order depending on backend defaults. Add a default sort for audit logs (e.g., via schema.table.defaultSort / view metadata) so the audit log remains chronological by default.
System settings pages (Users, Orgs, Roles, Permissions, Audit Log) used hand-written HTML tables with manual fetch/CRUD logic, duplicating ~500 lines of nearly identical code across 5 files. Replaced with the platform's
ObjectViewfrom@object-ui/plugin-view, driven by existingsystemObjects.tsmetadata.Changes
SystemObjectViewPagecomponent — shared wrapper that builds anObjectViewSchemafromsystemObjects.tsdefinitions and rendersObjectViewwith the adapter dataSourceSystemObjectViewPage(~25 lines each, down from ~140)isAdminviaoperationsconfigreadOnlymode@object-ui/plugin-viewand assert schema props (objectName, operations, columns) rather than testing hand-rolled table rendering22 system page tests pass, 750 total console tests pass. CHANGELOG.md and ROADMAP.md updated.
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.