internal/models/types.go (1)

84-84: Notes column added — consider nullability consistency and DB default

Current choice uses empty string as default. If you intend “optional,” consider either:

• Keep string but add not null explicitly for clarity; or
• Switch to *string to represent nulls consistently across DB and JSON (omitempty).

Minimal GORM tag tweak (if staying non-null) for explicitness:

- Notes        string     `gorm:"type:varchar(255);default:''" json:"notes"`
+ Notes        string     `gorm:"type:varchar(255);not null;default:''" json:"notes"`

web/src/types/models.ts (1)

16-16: Align TS type with backend payload

Backend always returns a string (often empty). Making notes non-optional avoids undefined checks in the UI.

-  notes?: string;
+  notes: string;

web/src/api/keys.ts (1)

109-112: Trim and bound notes client-side to reduce server rejects

Minor UX polish: trim and enforce 255 chars before sending.

   // 更新密钥备注
   async updateKeyNotes(keyId: number, notes: string): Promise<void> {
-    await http.put(`/keys/${keyId}/notes`, { notes });
+    const payload = (notes ?? "").trim().slice(0, 255);
+    await http.put(`/keys/${keyId}/notes`, { notes: payload });
   },

internal/handler/key_handler.go (1)

452-485: Optional: audit trail

Consider logging who changed notes and when (if you have user identity), to aid operational traceability.

web/src/components/keys/KeyTable.vue (4)

34-36: Type safety: make is_visible optional or initialize it

Data from API lacks is_visible. Either mark it optional:

-interface KeyRow extends APIKey {
-  is_visible: boolean;
-}
+interface KeyRow extends APIKey {
+  is_visible?: boolean;
+}

or initialize when loading (see next comment).

---

190-201: Initialize is_visible to avoid undefined at runtime

Set a default when mapping response items.

-    keys.value = result.items as KeyRow[];
+    keys.value = (result.items as APIKey[]).map(k => ({ ...k, is_visible: false })) as KeyRow[];

---

302-313: Trim notes before save for consistent UX

Aligns with API trimming suggestion.

 async function saveKeyNotes() {
   if (!editingKey.value) return;
 
   try {
-    await keysApi.updateKeyNotes(editingKey.value.id, editingNotes.value);
-    editingKey.value.notes = editingNotes.value;
+    const payload = (editingNotes.value ?? "").trim().slice(0, 255);
+    await keysApi.updateKeyNotes(editingKey.value.id, payload);
+    editingKey.value.notes = payload;
     window.$message.success("备注已更新");
     notesDialogShow.value = false;
   } catch (error) {
     window.$message.error("备注更新失败");
   }
 }

---

1082-1091: Unused style block

.key-notes isn’t referenced in the template. Remove or apply it where intended to avoid dead CSS.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

internal/handler/key_handler.go (2)

443-446: Add validation tag to prevent DB constraint violations.

The Notes field lacks server-side validation that could prevent values exceeding the database's varchar(255) constraint, potentially causing 500 errors.

This issue was previously flagged. As suggested in the earlier review, add binding:"max=255" to the struct field.

---

448-481: Trim input and validate length explicitly before DB update.

Without trimming and explicit length validation, oversized or untrimmed notes can hit the database and cause errors or inconsistent data.

This issue was previously flagged. As suggested in the earlier review, trim the input with strings.TrimSpace after binding and validate the length before the DB operation.

web/src/components/keys/KeyTable.vue (2)

309-313: Validate and trim notes before API call.

The function should validate the input before making the API call to provide better UX and catch issues client-side.

Apply this diff:

 async function saveKeyNotes() {
   if (!editingKey.value) return;
 
+  // Trim and validate
+  const trimmedNotes = editingNotes.value.trim();
+  if (trimmedNotes.length > 255) {
+    window.$message.error(t("keys.notesTooLong"));
+    return;
+  }
+
   try {
-    await keysApi.updateKeyNotes(editingKey.value.id, editingNotes.value);
-    editingKey.value.notes = editingNotes.value;
+    await keysApi.updateKeyNotes(editingKey.value.id, trimmedNotes);
+    editingKey.value.notes = trimmedNotes;
     window.$message.success(t("keys.notesUpdated"));
     notesDialogShow.value = false;
   } catch (error) {
     window.$message.error(t("keys.notesUpdateFailed"));
   }
 }

---

1096-1105: Remove unused CSS class.

The key-notes class is defined but never used in the template. Consider removing it to reduce code clutter.

Apply this diff to remove the unused class:

-/* 备注信息行 */
-.key-notes {
-  font-size: 12px;
-  color: var(--text-secondary);
-  margin-top: 8px;
-  padding: 4px 6px;
-  background: var(--bg-secondary);
-  border-radius: 4px;
-  line-height: 1.4;
-}
-
 /* 底部统计和按钮行 */

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

web/src/components/keys/KeyTable.vue (3)

293-299: Clarify the notes display priority logic.

The function shows notes when they exist AND the key is hidden (!key.is_visible). When the key is visible (is_visible=true), it always shows the actual key value instead of notes. This means users must toggle visibility to switch between viewing notes and the actual key.

Consider documenting this behavior with a comment, or evaluate if notes should be displayed regardless of visibility state:

 // 获取要显示的值(备注优先,否则显示密钥)
 function getDisplayValue(key: KeyRow): string {
+  // Notes are shown only when the key is hidden; when visible, always show actual key
   if (key.notes && !key.is_visible) {
     return key.notes;
   }
   return key.is_visible ? key.key_value : maskKey(key.key_value);
 }

---

309-320: Improve error handling with logging.

The error handler in saveKeyNotes shows a generic error message but doesn't log the error details. This makes debugging production issues difficult.

Apply this diff:

   try {
     await keysApi.updateKeyNotes(editingKey.value.id, editingNotes.value);
     editingKey.value.notes = editingNotes.value;
     window.$message.success(t("keys.notesUpdated"));
     notesDialogShow.value = false;
   } catch (error) {
+    console.error("Failed to update key notes:", error);
     window.$message.error(t("keys.notesUpdateFailed"));
   }

---

1096-1105: Remove unused CSS class.

The .key-notes CSS class is defined but never used in the template. Notes are displayed through the getDisplayValue() function within the existing .key-text input field, not as a separate element with the .key-notes class.

Apply this diff to remove the unused CSS:

-/* 备注信息行 */
-.key-notes {
-  font-size: 12px;
-  color: var(--text-secondary);
-  margin-top: 8px;
-  padding: 4px 6px;
-  background: var(--bg-secondary);
-  border-radius: 4px;
-  line-height: 1.4;
-}
-
 /* 底部统计和按钮行 */

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

web/src/locales/ja-JP.ts (1)

401-406: Consider using "備考" instead of "注釈" for better UX alignment.

The current translations use "注釈" (annotation), which is more formal/academic. Since the PR title references "备注" (remark/memo in Chinese), consider using "備考" (bikō) in Japanese, which is more commonly used in business and UI contexts for user notes/remarks.

Apply this diff:

-    notesUpdated: "注釈が更新されました",
-    notesUpdateFailed: "注釈の更新に失敗しました",
-    editNotes: "注釈を編集",
-    notes: "注釈",
-    editKeyNotes: "キー注釈を編集",
-    enterNotes: "注釈を入力してください...",
+    notesUpdated: "備考が更新されました",
+    notesUpdateFailed: "備考の更新に失敗しました",
+    editNotes: "備考を編集",
+    notes: "備考",
+    editKeyNotes: "キー備考を編集",
+    enterNotes: "備考を入力してください...",

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

web/src/components/keys/KeyTable.vue (1)

308-322: Add loading state and improve error handling.

The save operation lacks a loading state, which could lead to duplicate submissions if users click the save button multiple times. Additionally, the error is not logged, making debugging difficult in production.

Consider this enhancement:

+const savingNotes = ref(false);
+
 // 保存备注
 async function saveKeyNotes() {
-  if (!editingKey.value) {
+  if (!editingKey.value || savingNotes.value) {
     return;
   }
 
+  savingNotes.value = true;
   try {
     await keysApi.updateKeyNotes(editingKey.value.id, editingNotes.value);
     editingKey.value.notes = editingNotes.value;
     window.$message.success(t("keys.notesUpdated"));
     notesDialogShow.value = false;
-  } catch (_error) {
+  } catch (error) {
+    console.error("Failed to update notes:", error);
     window.$message.error(t("keys.notesUpdateFailed"));
+  } finally {
+    savingNotes.value = false;
   }
 }

Then update the save button to show loading state:

-    <n-button type="primary" @click="saveKeyNotes">{{ t("common.save") }}</n-button>
+    <n-button type="primary" @click="saveKeyNotes" :loading="savingNotes">{{ t("common.save") }}</n-button>

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

web/src/components/keys/KeyTable.vue (2)

309-324: Consider adding a loading state to prevent double-submission.

While the current implementation handles errors correctly, there's no loading state to prevent users from clicking the save button multiple times while the API call is in progress. This could lead to duplicate requests.

Consider adding a loading state:

+const isSavingNotes = ref(false);
+
 async function saveKeyNotes() {
-  if (!editingKey.value) {
+  if (!editingKey.value || isSavingNotes.value) {
     return;
   }
 
+  isSavingNotes.value = true;
   try {
     const trimmed = editingNotes.value.trim();
     await keysApi.updateKeyNotes(editingKey.value.id, trimmed);
     editingKey.value.notes = trimmed;
     window.$message.success(t("keys.notesUpdated"));
     notesDialogShow.value = false;
   } catch (_error) {
     window.$message.error(t("keys.notesUpdateFailed"));
+  } finally {
+    isSavingNotes.value = false;
   }
 }

Then disable the save button while loading:

-    <n-button type="primary" @click="saveKeyNotes">{{ t("common.save") }}</n-button>
+    <n-button type="primary" @click="saveKeyNotes" :loading="isSavingNotes">{{ t("common.save") }}</n-button>

---

743-790: Consider consolidating action buttons to improve layout for invalid keys.

The maintainer reported that for invalid status keys, multiple action buttons in the bottom row cause text overlap with the statistics display. The maintainer suggested moving bottom buttons to the top row and using icon-only buttons to improve the layout and prevent text from being obscured.

Based on PR comments reporting UI layout issues with button overlap.

Current layout:

• Top row (lines 713-739): Icon-only buttons for Notes, Show/Hide, Copy
• Bottom row (lines 758-789): Text buttons for Test, Restore (conditional), Delete

Possible improvements:

1. Move Restore and Delete buttons to the top row as icon-only buttons and keep only the Test button (or a combined "More actions" dropdown) at the bottom
2. Use a dropdown menu for less-frequent actions (Restore, Delete) to reduce button count
3. Reduce button padding or use smaller button sizes for the bottom row to prevent overlap

The maintainer referenced screenshots showing the overlap issue. Would you like me to generate a specific UI refactor proposal based on one of these approaches?

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

web/src/components/keys/KeyTable.vue (1)

847-861: LGTM! Modal implementation is correct.

The notes editing modal properly uses:

• v-model:show for dialog visibility control
• Internationalized strings for title, placeholder, and buttons
• maxlength="255" matching the database field size
• show-count for user feedback
• Proper action buttons (Cancel/Save) with correct handlers

Optional: Consider adding a loading state to the Save button during the API call to provide visual feedback and prevent double-clicks.

Apply this diff to add loading state:

+const isSavingNotes = ref(false);
+
 // 保存备注
 async function saveKeyNotes() {
   if (!editingKey.value) {
     return;
   }
 
   try {
+    isSavingNotes.value = true;
     const trimmed = editingNotes.value.trim();
     await keysApi.updateKeyNotes(editingKey.value.id, trimmed);
     editingKey.value.notes = trimmed;
     window.$message.success(t("keys.notesUpdated"));
     notesDialogShow.value = false;
   } catch (_error) {
     window.$message.error(t("keys.notesUpdateFailed"));
+  } finally {
+    isSavingNotes.value = false;
   }
 }

Then update the Save button:

-    <n-button type="primary" @click="saveKeyNotes">{{ t("common.save") }}</n-button>
+    <n-button type="primary" :loading="isSavingNotes" @click="saveKeyNotes">{{ t("common.save") }}</n-button>

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro