feat: add linux_do_id field to EditUserModal form - #2534
Conversation
WalkthroughAdd field-based user search and propagate a new searchField/filter parameter across frontend hooks and UI; extend backend SearchUsers to accept explicit filters (including Changes
Sequence Diagram(s)sequenceDiagram
participant Browser as Browser (UI)
participant Frontend as Frontend Hook
participant Server as API Server (controller)
participant Model as Model Layer
participant DB as Database
Browser->>Frontend: user selects searchField + value
Frontend->>Server: GET /api/users?{<searchField>=value}&group=&start=&size
Server->>Model: SearchUsers(keyword="", group, filters{<searchField>:value}, start, size)
Model->>DB: Build query -> apply exact-match filters + keyword/group conditions -> execute
DB-->>Model: rows, total
Model-->>Server: users list, total
Server-->>Frontend: 200 OK {users, total}
Frontend-->>Browser: render results
note over Model,DB: Filters (e.g., linux_do_id) applied as exact matches
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR adds the linux_do_id field to the EditUserModal form in the admin panel's user management section, enabling administrators to view which Linux DO account a user has bound.
Key Changes
- Added 'linux_do_id' to the array of third-party account binding fields displayed in the user edit modal
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
web/src/i18n/locales/en.json (1)
1252-1252: Align capitalization with existing “Display Name” usageThe English label is correct, but elsewhere this project uses “Display Name” (capital N). To keep UI text consistent, consider:
Proposed capitalization tweak
- "模糊搜索 (ID/用户名/显示名/邮箱)": "Fuzzy search (ID/Username/Display name/Email)", + "模糊搜索 (ID/用户名/显示名/邮箱)": "Fuzzy search (ID/Username/Display Name/Email)",web/src/components/table/users/UsersFilters.jsx (1)
20-21: Search-field selector is correctly wired to backend filtersThe
filterFieldsoptions align with the backend’s allowed filter keys, and the newsearchFieldselect integrates cleanly with the form anduseUsersDatahook. This gives a clear toggle between fuzzy search (empty value) and exact field filters (GitHub/Discord/OIDC/WeChat/Email/Telegram/LinuxDO), which is exactly what the new API expects.If you want full i18n coverage later, consider localizing the non-default labels (
'GitHub ID','Discord ID', etc.) and ensure the'输入搜索值'placeholder key exists in all locales, but this is not blocking.Also applies to: 38-47, 75-83, 88-88
controller/user.go (1)
290-304: SearchUsers controller correctly forwards structured filtersThe new
filtersmap cleanly whitelists the supported ID/email fields and passes them tomodel.SearchUsers, which keeps field names under server control while allowing the frontend to send dynamic filters. This matches the model’s column definitions and the newsearchFieldclient logic.If this list grows, consider centralizing the allowed filter keys (e.g., a shared constant or helper) to avoid drift between controller and model.
model/user.go (1)
222-290: SearchUsers filter logic matches the new API contractThe refactored
SearchUserscorrectly combines:
- exact-match filters from a server-controlled
filtersmap,- optional fuzzy keyword search (with numeric support for
id),- and optional group scoping,
all within a single query that omits the password field. Column names in
filtersmatch theUsermodel’s gorm tags, so the generated SQL is valid for the new controller wiring.For future safety, you might consider mapping a fixed set of logical filter keys to column names (rather than using the map key directly in
Where(field+" = ?", ...)) and, if you don’t depend on transactional semantics here, dropping the explicit transaction to simplify the read path; these are quality-of-implementation tweaks, not blockers.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
controller/user.gomodel/user.goweb/src/components/table/users/UsersFilters.jsxweb/src/hooks/users/useUsersData.jsxweb/src/i18n/locales/en.jsonweb/src/i18n/locales/fr.jsonweb/src/i18n/locales/ja.jsonweb/src/i18n/locales/ru.jsonweb/src/i18n/locales/vi.jsonweb/src/i18n/locales/zh.json
🧰 Additional context used
🧬 Code graph analysis (3)
model/user.go (1)
controller/user.go (1)
SearchUsers(290-313)
controller/user.go (2)
common/page_info.go (1)
GetPageQuery(41-82)model/user.go (1)
SearchUsers(222-290)
web/src/hooks/users/useUsersData.jsx (1)
web/src/hooks/channels/useChannelsData.jsx (1)
getFormValues(303-310)
🔇 Additional comments (7)
web/src/i18n/locales/ru.json (1)
1269-1269: Fuzzy-search Russian translation is accurate and consistentThe Russian string correctly reflects the Chinese key and matches the style of surrounding entries. No functional issues here.
web/src/i18n/locales/ja.json (1)
1192-1192: LGTM! Translation is accurate and consistent.The Japanese translation for the fuzzy search feature is correct:
- "あいまい検索" accurately conveys "fuzzy search"
- Field names (ID/ユーザー名/表示名/メール) are properly localized
- Formatting and structure align with existing entries
web/src/i18n/locales/fr.json (1)
1260-1260: LGTM! Translation is accurate and follows French conventions.The French translation for the fuzzy search feature is correct:
- "Recherche floue" accurately translates "fuzzy search"
- Field names (Nom d'utilisateur/Nom affiché/Email) are appropriately localized
- Keeping "Email" in English is standard practice in French localization
- Formatting and structure align with existing entries
web/src/i18n/locales/vi.json (1)
2439-2439: Fuzzy-search label translation looks correct and consistentThe new Vietnamese entry for the fuzzy-search label is accurate and matches the cross-locale key structure; no changes needed.
web/src/i18n/locales/zh.json (1)
1242-1242: Chinese fuzzy-search key wired correctlyThe added zh entry for “模糊搜索 (ID/用户名/显示名/邮箱)” is consistent and enables i18n lookup for the new UI label.
controller/user.go (1)
456-482: linux_do_id is now exposed in GetSelf as intendedAdding
"linux_do_id": user.LinuxDOIdto the self payload is consistent with theUserJSON tags and allows the admin UI to display the LinuxDO binding without exposing any new sensitive data.web/src/hooks/users/useUsersData.jsx (1)
47-51: Hook correctly propagates searchField to the search API
useUsersDatanow threadssearchFieldfrom form state intosearchUsersand encodes it as either a fuzzykeywordor an exact field filter in the URL, depending on whethersearchFieldis empty. The pagination handlers and refresh path all reusegetFormValues, so search behavior stays consistent across page changes and reloads.Also applies to: 56-64, 91-104, 113-126, 207-214, 243-249
|
草 忘branch了 |
管理员面板>用户管理>编辑用户缺失了linux_do_id
加上能有效帮助管理员查看newapi用户绑定了哪个linux do账号
Summary by CodeRabbit
New Features
Localization
✏️ Tip: You can customize this high-level summary in your review settings.