fix: display auth window when the password need be checked before shu…

[yixinshark]

…tdown or reboot

when the password need be checked before shutdown or reboot, if the lock is showing, need show auth window.

Log: display auth window when the password need be checked before shutdown or reboot
Pms: BUG-353333 BUG-338545

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: yixinshark

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[deepin-ci-robot]

deepin pr auto review

这段代码变更存在严重的逻辑错误，会导致功能异常。以下是对该变更的详细审查意见：

1. 代码逻辑审查

问题描述：
原代码的意图是判断 m_powerAction 不等于 RequireShutdown 且 不等于 RequireRestart 时执行进入锁屏界面的逻辑。
修改后的代码逻辑变成了：只有当 m_powerAction 等于 RequireShutdown 或 RequireRestart 并且 gsCheckpwd() 返回真时，才执行该逻辑。

这是一个逻辑反转的严重错误，完全改变了原有的业务逻辑。

具体分析：

• 原代码：

  && m_powerAction != SessionBaseModel::RequireShutdown
  && m_powerAction != SessionBaseModel::RequireRestart

  这表示：如果是普通的关机或重启操作（且不满足前述特定条件），则允许进入锁屏/登录界面。

• 新代码：

  && ((m_powerAction == SessionBaseModel::RequireShutdown || m_powerAction == SessionBaseModel::RequireRestart) && m_model->gsCheckpwd()))

  这表示：只有当是关机或重启操作并且通过密码检查时，才允许进入锁屏/登录界面。

结论：这会导致除了特定的关机/重启+验证密码场景外，其他原本应该进入锁屏界面的场景全部失效。

2. 语法与代码质量

• 括号嵌套复杂：修改后的代码使用了多层嵌套的括号 && (( ... || ... ) && ... )，降低了代码的可读性。
• 版权年份：将版权年份从 2022 修改为 2026 是合理的，属于常规维护。

3. 改进建议

如果目的是在关机或重启前增加一个密码验证（gsCheckpwd）的步骤，那么不应该修改进入锁屏界面的条件，而应该在执行关机/重启动作的前置逻辑中进行拦截。

假设确实需要修改这里的逻辑（例如：只有验证过密码的关机/重启才允许进入锁屏，否则直接关机），建议如下：

修正方案 A（如果意图是逻辑反转）：
如果确实需要反转逻辑，请务必确认业务需求。如果确认需要，建议提取变量以提高可读性：

bool isStandardPowerAction = (m_powerAction == SessionBaseModel::RequireShutdown || 
                             m_powerAction == SessionBaseModel::RequireRestart);

// 只有是标准电源操作 且 通过了密码检查，才进入锁屏
if ( ... && isStandardPowerAction && m_model->gsCheckpwd()) {
    // ...
}

修正方案 B（如果意图是原逻辑保持不变，只是想加密码检查）：
如果原逻辑（非 RequireShutdown/RequireRestart 时进入锁屏）是正确的，而你想对 RequireShutdown/RequireRestart 做特殊处理，那么这段代码不应该这样改。正确的做法可能是：

// 保持原有的排除逻辑
bool isStandardPowerAction = (m_powerAction == SessionBaseModel::RequireShutdown || 
                             m_powerAction == SessionBaseModel::RequireRestart);

// 如果是标准电源操作，且未通过密码检查，则不进入锁屏（直接执行后续操作）
if (isStandardPowerAction && !m_model->gsCheckpwd()) {
    // 不进入锁屏，直接返回或执行关机
    return; 
}

// 原有逻辑：非上述特定模式，执行锁屏
if (m_model->currentModeState() != SessionBaseModel::ModeStatus::PowerMode
    && m_powerAction != SessionBaseModel::RequireUpdateShutdown
    && m_powerAction != SessionBaseModel::RequireUpdateRestart
    && m_powerAction != SessionBaseModel::RequireShutdown // 原有逻辑
    && m_powerAction != SessionBaseModel::RequireRestart) { // 原有逻辑
    
    FullScreenBackground::setContent(LockContent::instance());
    m_model->setCurrentContentType(SessionBaseModel::LockContent);
}

4. 安全性

• 逻辑漏洞：错误的逻辑反转可能导致绕过预期的安全检查。例如，如果原意是"只有在特定条件下才允许操作"，而新代码变成了"只有在特定条件下才允许锁屏"，可能会导致系统在未验证的情况下直接执行敏感操作（如关机），或者导致系统无法正常锁定。

总结

强烈建议拒绝此代码变更。该变更破坏了原有的业务逻辑，且未提供清晰的注释说明为何进行如此巨大的逻辑反转。请开发者重新确认需求，并提供符合预期的逻辑实现。