Skip to content

fix: switch for the knowledge image list - #7892

Merged
peslyn merged 1 commit into
v3from
pr@v3@fix_switch_for_the_knowledge_image_list
Nov 13, 2026
Merged

peslyn merged 1 commit into
v3from
pr@v3@fix_switch_for_the_knowledge_image_list

Conversation

@shaohuzhang1

Copy link
Copy Markdown
Contributor

fix: switch for the knowledge image list

@peslyn
peslyn merged commit d2a71a3 into v3 Nov 13, 2026
3 of 4 checks passed
@peslyn
peslyn deleted the pr@v3@fix_switch_for_the_knowledge_image_list branch November 13, 2026 07:25
:disabled="operationLoading || !canImage('edit')"
:before-change="() => handleChangeActive(row)"
/>

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change from && to || is a logic bug and likely incorrect.

Analysis of the original (&&):

  • Switch is disabled only when data is loading AND the user lacks edit permission.
  • If not loading, or if user has permission, the switch stays enabled.
  • This allows a user with edit rights to toggle even during loading (which can be risky), but lets users see/toggle when idle.

Analysis of the new (||):

  • Switch is disabled when data is loading OR user lacks edit permission.
  • More importantly: if the user lacks edit permission, it's always disabled — good.
  • But during loading, it's disabled for everyone — also reasonable.
  • The real question is intent: does canImage('edit') mean "user CAN edit"? If yes, then !canImage('edit') = "cannot edit" → || = "disabled if cannot edit OR loading" — this is arguably the more correct/intuitive behavior.

Potential issues to verify:

  1. Semantics of canImage('edit'): Confirm it returns true when the user has permission. If it actually returns whether an image editing operation is allowed (naming is ambiguous), negating it may behave unexpectedly.

  2. operationLoading scope: Is it per-row or global? If global, one row's save disables switches on all rows. Consider a per-row loading flag (e.g., row._loading) for better UX.

  3. before-change vs disabled redundancy: handleChangeActive(row) presumably performs the API call. With :disabled, the switch won't fire before-change when disabled — so make sure permission checks in handleChangeActive are still present as defense-in-depth (server-side authorization must exist regardless).

  4. Read-only display: When disabled due to lack of permission, consider showing a tooltip explaining why (better UX than a silently inert control).

Optimization suggestion:

:disabled="isRowBusy(row) || !canImage('edit')"

Create a helper isRowBusy(row) that tracks per-row operations rather than a shared operationLoading, avoiding cross-row lock-outs.

Verdict: The || change is defensible and probably intentional (fixing cases where unauthorized users could interact), but verify: (a) the meaning of canImage('edit'), and (b) whether operationLoading is global — if global, prefer per-row loading to avoid disabling unrelated rows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants