合并受阻
开始进行AI检视！
AI review has been started, please wait...
| check type | result | report |
|---|---|---|
| start ai_review | pass | - |
感谢提交 Pull Requests ！此PR未通过DCO校验。
校验失败可能原因：
1. 未签署“DCO协议”（开发者原创声明协议），在线签署、查看签署状态。
2. Commits 中未包含 Signed-off-by信息，参考FAQ处理。
修复上述问题后，在PR的评论框输入“check dco” ，单击”评论”，系统将再次进行DCO校验。
当前检测到如下Commits的Signed-off-by邮箱未签署DCO协议：
Thanks for submitting a pull request. This pull request has not passed the DCO check.
Possible causes:
1. You have not signed the Developer Certificate of Origin (DCO). Sign the DCO and check DCO status.
2. The commits do not contain the Signed-off-by information. To resolve this issue, see FAQs.
After resolving the preceding issues, enter check dco in the comment box of this pull request and click Comment. The system will check DCO status again.
The Signed-off-by emails in the following commits have not signed the DCO:
⚠️ 🤖 AI 代码检视报告 ⚠️
总体评估: NEEDS_ATTENTION
问题统计:
- 总问题数: 6
- 严重问题: 0
- 高危问题: 1
摘要:
本设计文档针对 MDM 管控场景下应用通知开关固定能力进行了基础设计，但在安全权限控制、多用户架构及具体接口约束上存在关键细节缺失，需进一步明确以避免实现阶段的安全漏洞和歧义。
📊 详细报告
查看完整的审查详情，包括具体的问题描述、建议和代码位置：
🔗 查看详细报告
此评论由 OpenHarmony Insight 代码审查系统自动生成
🤖 AI 代码检视意见（回复本评论可解决检视意见，点击被检视代码行左侧的小头像可收起检视意见）
🟠 Inner API 缺失 EDM 进程级权限校验设计
位置: L181 | 严重程度: High
❓ 问题描述
在“待确认事项”中，Inner 设置接口的权限被标记为待确认。如果该接口仅校验 NOTIFICATION_CONTROLLER 权限，则任何拥有此权限的系统应用均可修改通知开关固定状态，这绕过了 MDM 管控入口，会导致严重的越权管控漏洞。管控类接口必须严格限制调用源。
💡 修复建议
修改建议：在设计阶段明确该 Inner API 必须校验调用方为 EDM 进程，并叠加 EDM 专用权限，而不能仅凭 NOTIFICATION_CONTROLLER 放行。
181: 2. inner 设置接口的权限：必须校验调用方为 EDM 进程并叠加 EDM 专用校验，不得仅凭 NOTIFICATION_CONTROLLER 放行
🤖 AI 代码检视意见（回复本评论可解决检视意见，点击被检视代码行左侧的小头像可收起检视意见）
🟡 未明确固定为关时 requestEnableNotification 的行为
位置: L135 | 严重程度: Medium
❓ 问题描述
对于存量接口的约束，仅说明了固定为开时 requestEnableNotification 的行为，遗漏了固定为关时的行为描述。如果固定为关，应用调用此接口应当直接返回失败，不应拉起弹窗或无响应。行为不明确会导致实现时产生歧义。
💡 修复建议
修改建议：在设计文档中补充固定为关时 requestEnableNotification 的明确行为（如直接返回失败或对应错误码）。
135: | requestEnableNotification | 固定为开的应用直接返回成功，不再拉起授权弹窗；固定为关的应用直接返回失败 |
🤖 AI 代码检视意见（回复本评论可解决检视意见，点击被检视代码行左侧的小头像可收起检视意见）
🟡 Slot 级开关不受约束可能导致管控失效
位置: L182 | 严重程度: Medium
❓ 问题描述
如果应用级开关被 MDM 固定为开，但 Slot 级开关仍可被用户或应用关闭，将导致应用实际上无法发布通知，破坏了 MDM “强制授权”的管控意图。这属于策略层级不一致的架构风险。
💡 修复建议
修改建议：在设计文档中明确固定策略对 Slot 级开关的影响，建议固定为开时强制所有 Slot 开关为开且不可关闭，以保障管控策略生效。
182: 3. Slot 级开关（setNotificationEnableSlot）同样受固定约束（固定为开时强制开启，固定为关时强制关闭）
🤖 AI 代码检视意见（回复本评论可解决检视意见，点击被检视代码行左侧的小头像可收起检视意见）
🟡 全局包名策略可能导致多用户越权管控
位置: L174 | 严重程度: Medium
❓ 问题描述
设计文档中规定“策略按包名全局管理”。在 OpenHarmony 多用户场景下，不同 userId 可安装相同包名的应用。设备级全局包名管控会导致 A 用户的 MDM 固定策略波及到 B 用户的同名应用，这可能不符合 MDM 针对特定用户管控的预期。
💡 修复建议
修改建议：明确管控策略的生效范围。如果确实为设备级全局生效，需说明副作用；若 MDM 意图仅管控当前用户，建议按 userId + bundleName 维度存储策略。
174: 策略存储建议按 userId + bundleName 维度管理，或明确说明全局策略对所有用户的同名应用均生效的副作用。
变更说明
新增 MDM 管控场景下应用通知开关固定（Fixed）能力的开发设计文档。
需求背景
MDM kit 需要支持设置应用通知权限静默授权打开，ANS 需根据 MDM 配置的应用列表强制固定通知开关状态，SystemUI 查询固定列表用于设置页开关屏蔽展示。
设计要点
SetNotificationSwitchFixedForBundles/GetNotificationSwitchFixedForBundles，纯包名vector<pair<string, bool>>，全量替换语义（空列表清空策略），设置固定时同步强制生效（静默授权）getNotificationSwitchFixedBundles(): Promise<Map<string, boolean>>，仅 Promise，@systemapi+ohos.permission.NOTIFICATION_CONTROLLER1600030 - 应用通知开关已被固定，无法修改SetNotificationsEnabledForSpecifiedBundle返回 1600030；IsNotificationEnabled/发布授权链路/requestEnableNotification读取固定状态变更内容
Issue: #4351