[shaohuzhang1]

feat: application publish permission

[shaohuzhang1]

Code Review

Issues / Irregularities

1. applicationId dependency risk – applicationWorkflowPermission references applicationId from the outer scope. Make sure it's declared before this function in <script setup> order, otherwise you'll get a temporal dead zone (ReferenceError) at init. Also consider passing it explicitly as a parameter for clarity/testability:

   function applicationWorkflowPermission(method: ..., id: string): boolean

2. Function called in template – re-evaluated on every render. Since permissions rarely change reactively (and perm.application.system[method]() looks like a non-reactive call), wrap it in a computed:

   const canPublish = computed(() => applicationWorkflowPermission('publish'))

   Then use v-if="canPublish".

3. Inconsistent meaning of the API – perm.application.system[method]() is called as a function, while perm.application.workspace[method](applicationId) takes an argument. Verify both are actually functions (the type is only a string union; TS can't check these dynamic accesses). If perm has typed methods, prefer direct calls: perm.application.system.publish() — safer and no string indexing.

4. Import style inconsistency – elsewhere imports drop the .ts extension ('@/utils/resource-context.ts' also has it, but './navigation' doesn't). Standardize — typically omit extensions for module resolution consistency and bundler compatibility.

5. Redundant Boolean() – if the permission functions already return booleans, Boolean(...) wrapping is unnecessary noise. If they may return undefined/truthy values, the cast is fine — but note it explicitly in the permission module's typing instead.

Optimization Suggestions

• UX consideration: hiding the button with v-if vs. disabling with :disabled + tooltip ("no permission"). Hiding is cleaner security-wise, but confirm designers intend hidden (some teams prefer disabled-with-reason).
• Naming: ApplicationWorkflowPermissionMethod is verbose; something like type WorkflowAction = 'publish' is clearer.
• Generalization: if more buttons will need checks (dropdown "more actions" menu likely), export a small composable, e.g. useApplicationWorkflowPermission(applicationId) returning { canPublish, canDelete, ... }, to avoid repeating helper calls in the template.

Overall the change is functionally sound; the main real risks are #1 (declaration order) and #3 (unverified dynamic method existence).