2.9 KiB
群邀请与入群身份
成员 A 邀请 B,管理员 C 审批时,邀请人、入群者与处理者是三个独立身份。
不要把 group_increase.operator_id 当成邀请人,也不要仅凭 sub_type: invite 推断两者相同。
入群通知
group_increase 保留原有的 user_id、operator_id 和 sub_type,增加:
| 字段 | 含义 |
|---|---|
invitor_id |
QQ 明确提供的独立邀请人 QQ 号;无法确定时为 0 |
invitor_status |
known 表示邀请人 QQ 号已知;unknown 表示无法确定 |
部分审批入群推送提供独立邀请人信息,SnowLuma 从该推送读取并解析身份。
二维码分享者与邀请人分开处理;旧式推送、自身入群通知或缺少来源信息的通知保留 unknown。
不会按同群、同成员或时间接近程度猜测邀请关系,也不会用操作者填充邀请人。
身份查询失败会留下日志,入群事件仍按现有策略上报,未知邀请人不阻断通知。
群申请列表
get_group_system_msg 返回的每条记录增加以下字段:
| 字段 | 含义 |
|---|---|
target_uin、target_nick |
申请或被邀请入群者,始终表示 B |
operator_uin、operator_nick |
处理该申请的操作者;审批场景中表示 C |
target_status、invitor_status、operator_status |
对应 QQ 号为 known 或 unknown |
原有 invitor_uin、invitor_nick 表示 A。requester_uin 保持兼容:普通申请表示申请人,
邀请登录账号入群的记录则表示邀请人。需要区分三方时,应使用 target_uin、invitor_uin、operator_uin。
QQ 只提供 UID 时会查询对应 QQ 号,查询去重并限制并发;查询错误会返回接口错误,不伪装成空列表。
{
"target_uin": 10002,
"target_status": "known",
"invitor_uin": 10004,
"invitor_status": "known",
"operator_uin": 10003,
"operator_status": "known",
"checked": true
}
0 或 unknown 不代表“没有邀请人”。 QQ 未提供身份、记录不可见、身份尚未解析等情况均不能证明没有邀请人。
当前已确认的字段不足以对缺失信息可靠作出“无邀请人”的判断,因此不输出这种推断。
同样,checked: true 只表示已处理,不代表必然审批通过;operator_uin 也可能是拒绝请求的人。
count 限制每个收件箱读取的记录数(最多 100);group_id 在读取后过滤,
并非查询指定群的完整历史。only_pending 默认为 false。空数组表示本次读取范围内没有匹配记录,
不能证明某次入群没有邀请人。调试日志会分别记录收件箱数量、类型筛选和最终筛选数量。
SDK 的 getGroupSystemMessages() 提供相应类型。新增字段在 SDK 中可选,以兼容旧服务端;
连接旧服务端时,缺失的状态也应视为未知。