Motivation

• The interactive DingTalk QR setup previously saved DINGTALK_ALLOW_ALL_USERS=true unconditionally, which could unintentionally open the bot to all DingTalk users. The change prevents that unsafe default and ensures operators are prompted to choose access controls.

Description

• Replace the QR-path silent DINGTALK_ALLOW_ALL_USERS=true write with a post-credential access-control prompt implemented in a new _configure_dingtalk_access() helper that supports explicit allowlist entry, DM pairing, or explicit open-access opt-in.
• Add DINGTALK_ALLOWED_USERS as an is_allowlist platform variable so manual setup also surfaces the allowlist prompt.
• Add DINGTALK_ALLOWED_USERS and DINGTALK_ALLOW_ALL_USERS to the known _EXTRA_ENV_KEYS so managed env handling recognizes them.
• Update the DingTalk setup docs to state that the wizard prompts for allowlist/pairing/open access (rather than silently enabling allow-all).
• Add regression tests (tests/hermes_cli/test_dingtalk_setup.py) that assert the QR-flow no longer writes DINGTALK_ALLOW_ALL_USERS=true silently and that access-control prompting is present.

Testing

• Ran the new unit tests with pytest tests/hermes_cli/test_dingtalk_setup.py -q -o addopts="-m 'not integration'" and they passed (2 passed).
• Verified syntax/compilation with python -m py_compile hermes_cli/gateway.py hermes_cli/config.py, which succeeded.
• Performed an AST-based check in the added tests to ensure no direct save_env_value("DINGTALK_ALLOW_ALL_USERS", "true") remains in the _setup_dingtalk() flow, which passed.

Codex Task

Summary by CodeRabbit

• New Features

  • DingTalk integration now includes explicit access control configuration during setup, allowing you to configure an allowlist of authorized users, enable DM-only pairing, or deny access by default.

• Documentation

  • Updated DingTalk setup guide to clarify the new access control configuration options during the setup process.