larksuite / larksuite/oapi-sdk-python
FileComment model includes is_whole/quote fields but they are silently ignored when creating comments on docx files
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 559
- フォーク
- 102
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
Summary
The FileComment model and its FileCommentBuilder expose is_whole and quote fields, suggesting that inline (non-whole-document) comments can be created via the API. However, when calling POST /open-apis/drive/v1/files/{file_token}/comments with file_type=docx, these fields are silently ignored — the API always creates a global (whole-document) comment regardless of the values passed.
Steps to Reproduce
import httpx
body = {
"is_whole": False,
"quote": "目标是验证文档导入与结构化展示", # exact text from the document
"reply_list": {
"replies": [{
"content": {
"elements": [
{"type": "text_run", "text_run": {"text": "This should be an inline comment"}}
]
}
}]
}
}
resp = httpx.post(
"https://open.larksuite.com/open-apis/drive/v1/files/{file_token}/comments",
headers={"Authorization": f"Bearer {tenant_access_token}"},
params={"file_type": "docx"},
json=body,
timeout=15,
)
Expected Behavior
The comment should be created as an inline comment anchored to the quoted text, with is_whole=False in the response.
Actual Behavior
The API returns code: 0 (success), but when retrieving the comment via the List API:
{
"comment_id": "...",
"is_whole": true,
"quote": "",
...
}
The comment is always a global comment (is_whole=true, quote=""), no matter what is_whole or quote values are sent in the request.
Test Details
Tested with 5 different quote values against a real docx document:
| quote value | Result |
|---|---|
| Exact substring with punctuation | is_whole=true, quote="" |
| Full sentence from document | is_whole=true, quote="" |
| Partial text match | is_whole=true, quote="" |
| Heading text | is_whole=true, quote="" |
| Empty (no quote) | is_whole=true, quote="" |
All 5 comments were created as global comments.
The Problem
The SDK's auto-generated FileComment model uses the same class for both request and response, so it exposes builder methods for is_whole() and quote():
# file_comment.py (auto-generated)
class FileCommentBuilder(object):
def is_whole(self, is_whole: bool) -> "FileCommentBuilder":
self._file_comment.is_whole = is_whole
return self
def quote(self, quote: str) -> "FileCommentBuilder":
self._file_comment.quote = quote
return self
This is misleading because:
- Developers assume these fields are functional for creation since the builder exposes them
- The API accepts the request without any error or warning — it just silently ignores the fields
- The official documentation page is titled "Add a Global Comment" but this isn't obvious when using the SDK
Suggestion
One or more of the following would help:
- Document the limitation — Clarify in the API docs that
is_wholeandquoteare response-only fields, not accepted in the create request body fordocxfiles - Separate request/response models — Use a dedicated
CreateFileCommentRequestBodythat only includesreply_list, instead of reusingFileComment - Support inline comments — If this is a missing feature, it would be very useful to support creating inline comments via the API (the UI already supports this)
- Return an error — If
is_whole=Falseorquoteis passed but not supported, return an error code instead of silently ignoring
Environment
- SDK version: latest (
lark-oapifrom PyPI) - API base:
https://open.larksuite.com/open-apis - Document type:
docx(New Doc) - Auth:
tenant_access_token
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
生成された file_comment.py モデルと FileCommentBuilder から始め、提供されたリクエストを使用して file_type=docx を指定した POST /open-apis/drive/v1/files/{file_token}/comments を再現します。リクエストのフィールドを、得られた List API のレスポンスおよび公式の「Add a Global Comment」ドキュメントと比較します。フィールドを黙って無視することなく、制限またはサポートされている動作が明確に解決されていれば完了とします。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- api
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100