refactor: move mail flag logic to backend

This commit is contained in:
dreamhunter2333
2026-08-25 20:47:09 +08:00
parent 6fe31df05a
commit de8920ccfd
14 changed files with 206 additions and 122 deletions
@@ -21,27 +21,27 @@ res = requests.get(
## Mail Flags API
After enabling `ENABLE_MAIL_FLAGS` and running the database migration, each mail response includes an integer `flags` bitmask. Bit 0 currently means `UNREAD`: `1` is unread, while `NULL` or `0` is treated as read.
After enabling `ENABLE_MAIL_FLAGS` and running the database migration, each mail response includes `mail_flags`, for example `{"unread": true}`. The backend owns bitmask mapping, historical `NULL` compatibility, and state calculation; clients do not need to know bit positions.
With an Address JWT, use `PATCH /api/mails/flags` to add or remove flags for up to 100 mail IDs. Only the `UNREAD` bit is currently mutable.
With an Address JWT, use `PATCH /api/mails/flags` to update up to 100 mail IDs. The supported flag is currently `unread`, and its action can be `set`, `clear`, or `toggle`.
```python
requests.patch(
"https://<your-worker-address>/api/mails/flags",
headers={"Authorization": f"Bearer {your-JWT-password}"},
json={"ids": [1, 2], "add": 0, "remove": 1}
json={"ids": [1, 2], "flag": "unread", "action": "clear"}
)
```
With a User JWT, send the same body to `PATCH /user_api/mails/flags`. Only mail belonging to addresses bound to that user can be changed. Other flag bits are always preserved.
With a User JWT, send the same body to `PATCH /user_api/mails/flags`. Only mail belonging to addresses bound to that user can be changed. The response contains the updated `mail_flags`, and all unrelated bits are preserved by the server.
Mail-list endpoints accept generic flag filters: `flag` is the bit position (`0-30`), and `flag_state` is either `set` or `unset`. For example, list unread mail with:
Mail-list endpoints use the semantic `read_status` filter. For example, list unread mail with:
```text
GET /api/mails?limit=20&offset=0&flag=0&flag_state=set
GET /api/mails?limit=20&offset=0&read_status=unread
```
Use `flag=0&flag_state=unset` for read mail. `/user_api/mails` accepts the same parameters, and future custom flags can use bits 10 through 19 directly.
Use `read_status=read` for read mail. `/user_api/mails` accepts the same parameter. Future system and custom flags will still be mapped from names to bits by the backend.
## Admin Mail API
@@ -21,27 +21,27 @@ res = requests.get(
## 邮件 Flag API
启用 `ENABLE_MAIL_FLAGS` 并完成数据库迁移后,邮件响应中的 `flags` 为整数位掩码。当前 bit 0 表示 `UNREAD`:值为 `1` 时未读,`NULL``0` 按已读处理
启用 `ENABLE_MAIL_FLAGS` 并完成数据库迁移后,邮件响应会包含 `mail_flags`,例如 `{"unread": true}`。数据库位掩码、历史 `NULL` 兼容和状态计算全部由后端处理,客户端不需要了解具体 bit
地址 JWT 使用 `PATCH /api/mails/flags` 批量增删状态。每次最多传入 100 个邮件 ID;当前仅允许修改 `UNREAD`
地址 JWT 使用 `PATCH /api/mails/flags` 批量操作状态。每次最多传入 100 个邮件 ID;当前支持 `unread`,操作可为 `set``clear``toggle`
```python
requests.patch(
"https://<你的worker地址>/api/mails/flags",
headers={"Authorization": f"Bearer {你的JWT密码}"},
json={"ids": [1, 2], "add": 0, "remove": 1}
json={"ids": [1, 2], "flag": "unread", "action": "clear"}
)
```
用户 JWT 使用相同请求体访问 `PATCH /user_api/mails/flags`,只能修改该用户已绑定地址的邮件。服务端始终保留请求未涉及的其他 Flag 位。
用户 JWT 使用相同请求体访问 `PATCH /user_api/mails/flags`,只能修改该用户已绑定地址的邮件。接口返回更新后的 `mail_flags`服务端始终保留请求未涉及的其他 Flag 位。
邮件列表接口支持通用 Flag 查询参数:`flag` 为 bit 位置(`0-30`),`flag_state``set``unset`。例如查询未读邮件:
邮件列表使用语义化的 `read_status` 查询已读状态。例如查询未读邮件:
```text
GET /api/mails?limit=20&offset=0&flag=0&flag_state=set
GET /api/mails?limit=20&offset=0&read_status=unread
```
查询已读邮件使用 `flag=0&flag_state=unset``/user_api/mails` 支持相同参数后续自定义 Flag 可以直接使用 bit 1019
查询已读邮件使用 `read_status=read``/user_api/mails` 支持相同参数后续扩展其他系统或自定义 Flag 时仍由后端负责名称到 bit 的映射
## admin 邮件 API