Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions skills/lark-approval/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,27 @@ metadata:

**CRITICAL — 开始前 MUST 先用 Read 工具读取 [`../lark-shared/SKILL.md`](../lark-shared/SKILL.md),其中包含认证、权限处理**

## 审批权限不足时的租户兼容性分流

当以 **user 身份**调用审批 API 失败,且错误响应的 `permission_violations` 中包含 `approval:` 开头的 scope(如 `approval:task:read`、`approval:instance:write` 等)时,**必须先检查当前用户的 `tenant_key`** 再决定如何引导:

```bash
lark-cli contact +get-user
```

根据返回结果中 `data.user.tenant_key` 的值进行分流:
Comment thread
coderabbitai[bot] marked this conversation as resolved.

- **`tenant_key` 为 `736588c9260f175d`** → 直接告知用户:
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Hardcoded tenant key in a public repository

The tenant key 736588c9260f175d is hardcoded directly in a versioned, (presumably) public skill file. This exposes a specific customer/tenant identifier to anyone who can read the repository, which is a privacy and security concern.

Beyond the sensitivity risk, this design is also fragile:

  • When more tenants need the same "not yet supported" treatment, each will require a new commit to this file.
  • When the feature is eventually enabled for this tenant, there will be no automated way to remove the exemption — it will silently keep showing the "not yet supported" message forever unless someone manually removes it.

Consider an alternative approach: have the lark-cli tool (or a dedicated endpoint) return a feature-flags/capability field in its response (e.g. data.user.features.approval_enabled: false) so the skill can branch on a boolean flag rather than a raw tenant ID. That way, tenant-specific rollout state lives in the platform, not in this file.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Thanks for the review. A few points:

  1. Privacy: tenant_key is not a secret — it's returned by a public API to any authenticated user within that tenant.

  2. Feature-flag approach: Agreed that a server-side feature flag would be ideal long-term. But that requires platform changes out of scope for this PR. This is a pragmatic stopgap that can be trivially removed once approval is rolled out to this tenant.

  3. Fragility: For a single known tenant, the cost of one hardcoded value is minimal. If more tenants need it, that would be the signal to invest in the flag approach.

> ⚠️ 当前租户暂不支持使用审批 skill,敬请期待。

不要引导用户去开发者后台添加权限,不要建议绕过方案。

- **其他 `tenant_key`** → 按 `lark-shared/SKILL.md` 中的标准权限不足处理流程引导用户添加对应 scope。
Comment thread
greptile-apps[bot] marked this conversation as resolved.

- **若 `lark-cli contact +get-user` 调用失败**(网络错误、缺少 `contact` 权限、返回中无 `tenant_key` 字段等)→ 按 `lark-shared/SKILL.md` 中的标准权限不足处理流程继续,不做租户分流。

---

## API Resources

```bash
Expand Down
Loading