FileComment model includes is_whole/quote fields but they are silently ignored when creating comments on docx files
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start with the generated file_comment.py model and FileCommentBuilder, then reproduce POST /open-apis/drive/v1/files/{file_token}/comments with file_type=docx using the provided request. Compare the request fields with the resulting List API response and the official “Add a Global Comment” documentation. Done should mean the limitation or supported behavior is clearly resolved without silently ignoring the fields.
Written by the indexing model from the issue text.
Description
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
- Dominant language
- Python
- Stars
- 559
- Forks
- 102
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from larksuite/oapi-sdk-python
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
larksuite/oapi-sdk-python#163 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
larksuite/oapi-sdk-python#162 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 94/100
larksuite/oapi-sdk-python#161 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
larksuite/oapi-sdk-python#160 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
larksuite/oapi-sdk-python#159 ·
All issues in larksuite/oapi-sdk-python
Similar issues
-
bug confirmed issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
open-webui/open-webui#30750 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
good first issue
Difficulty 1/5 Under an hour Newbie friendliness 90/100