Add Zoom Web host automation userscript for automatic Multi-Pin grants

[Copilot]

Implements a TamperMonkey userscript that runs under a Zoom Web host/co-host account and automatically grants Multi-Pin permission to any participant who raises their hand, along with scaffolding for camera-off detection and chat spam monitoring.

New files

• scripts/zoom-host-tools.user.js — Main userscript (@match https://*.zoom.us/wc/*). Organized into discrete modules:

  • resolve() / resolveAll() — selector resolver with primary→fallback strategy; all DOM lookups go through this
  • scanParticipants() — 2 s polling loop; raises-hand detection; processedParticipants Set prevents double-processing
  • needsMultipin() + grantMultipin() — opens participant context menu, locates option via aria-label with text-content fallback (resolveMultipinOption()), clicks, retries once on failure
  • checkCameraStatus() — scaffold; logs camera-off state, TODO for chat reminder
  • monitorChat() — MutationObserver on chat container detects spam URL patterns; bounded retry (max 60 s) for lazy-rendered chat panel
  • Floating debug panel (scanned / raised hands / grants / last action), gated on DEBUG_MODE

• selectors/zoom-dom-selectors.json — Canonical selector config with primary + fallback for every Zoom DOM element touched by the script. Update this file when Zoom changes its DOM; embedded SELECTORS object in the script mirrors it.

"multipinMenuOption": {
  "primary": "[aria-label='Allow to Multi-Pin']",
  "fallback": "[role='menuitem']",
  "_note": "When fallback is used, script MUST validate text content contains 'Multi-Pin'."
}

• docs/automation-design.md — Architecture, selector strategy, Multi-Pin logic flow, known limitations (name-collision in processedParticipants, host-privilege requirement), and extension points for camera-check and moderation hooks.

• docs/testing-checklist.md — 8-case manual QA checklist covering load, hand detection, auto-grant, idempotency, selector resilience, debug logging, spam detection, and camera scaffold.

Original prompt

You are tasked with implementing a Zoom Web automation userscript that performs the following tasks when run under a host or co-host account on Zoom Web in a browser:\n\n1. Automatically grants Multi-Pin permission when participants raise their hand during the meeting.\n2. Implements the following in a modular, deployable, and resilient structure:\n\n## Implementation Details:\n\nSTEP 1: Project Structure\n- Files to be created:\n 1. scripts/zoom-host-tools.user.js\n 2. selectors/zoom-dom-selectors.json\n 3. docs/automation-design.md\n 4. docs/testing-checklist.md\n\nSTEP 2: Selector Configurations:\n- Create a JSON object zoom-dom-selectors.json containing all configurable selectors relevant to Zoom. \n - Include placeholders for following keys:\n 1. participantList\n 2. participantRow\n 3. participantName\n 4. raisedHandIcon\n 5. participantMenuButton \n 6. multipinMenuOption.\n\nSTEP 3: Processes in TamperMonkey Scripts: \n-Involve aspect:\n\n Implementation Takeaway/best write\n \t

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Review

Assistant: This pull request addresses multiple architectural weaknesses in the STIX MAGIC platform by focusing on async correctness, API security, database reliability, observability, and deployment.

Summary of Core Improvements:

1. Async Safety and Media Processing:

   • Offloads blocking tasks like media processing (convert_to_sticker, convert_video_to_sticker, etc.) using asyncio.run_in_executor to ensure the event loop is not blocked.
   • Introduces async_* wrappers to maintain clean, testable sync APIs.
   • Adds a global error_handler for centralized error logging.

2. API Enhancements:

   • Introduced an in-memory sliding-window rate limiter applied per client IP.
   • Logs each request with X-Request-ID and a structured format for better tracing.
   • Adds a /status API endpoint to check real-time statuses in Telegram.

3. Database Improvements:

   • Replaces manual connection handling with a context manager, db_conn().
   • Adds a zero-downtime migration for the packs table and introduces an event_log for analytics.

4. Deployment & Documentation:

   • Adds a Dockerfile for standardized deployment.
   • Includes .env.example for environment setup and ARCHITECTURE.md to detail changes for developers.

Review Highlights:

✅ Positives:

• Improves async handling, which was a critical issue causing stalls in the event loop.
• Rate limiting and observability upgrades significantly improve security and debugging.
• Contextual database connection handling enhances robustness.
• Docker support aligns the project with modern deployment practices.

❗ Improvements Needed:

1. Inline Menu Definitions:

   • The file menus.py remains to be updated. Ensure async compliance is verified and modern patterns are followed.

2. Tests:

   • Add automated tests for reliability. Consider including edge cases for the rate limiter and /status APIs.

3. Security Considerations:

   • Identified a vulnerability where Mini App endpoints accept plain user_id without HMAC validation. This must be addressed before public deployment.

📂 Changed Files: 7 files were modified with 109 deletions and 652 additions.

• If you want a detailed analysis of a specific file change, let me know!
• View pull request and changes

User: Check and review run testing

Assistant: I can't retrieve the file scripts/zoom-host-automation.user.js from the specified URL. It seems like there’s an issue with the file or access.

Please verify:

1. The URL is correct and the file exists in the repository.
2. The branch copilot/design-tampermonkey-userscript is publicly accessible.

Let me know if there's anything specific you'd like me to check further!

User: Great. Here is the Implementation-Only Agent Prompt.
This version tells the Copilot agent exactly what files to create, in what order, and what each should contain so it can start coding immediately.

You can paste this directly into Copilot Agent Tasks.

⸻

:::writing{variant=“standard” id=“91842”}

IMPLEMENTATION AGENT PROMPT — ZOOM MULTIPIN AUTOMATION

You are a coding agent working inside this repository.

Your task is to implement a Zoom Web automation userscript that runs under a Host or Co-Host account and automatically grants Multi-Pin permission when participants raise their hand.

The system must be simple, reliable, and deployable quickly.

Do NOT introduce unnecessary architecture or dependencies.

The system must run entirely as a Tampermonkey userscript interacting with the Zoom Web DOM.

Assume the Zoom account running the script has co-host or host permissions.

⸻

STEP 1 — CREATE PROJECT STRUCTURE

Create the following files:

scripts/zoom-host-tools.user.js
selectors/zoom-dom-selectors.json...

This pull request was created from Copilot chat.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[cr-gpt]

Seems you are using me but didn't get OPENAI_API_KEY seted in Variables/Secrets for this repo. you could follow readme for more information

[cr-gpt]

Seems you are using me but didn't get OPENAI_API_KEY seted in Variables/Secrets for this repo. you could follow readme for more information

[FriskyDevelopments]

Here is a clean copy-paste follow-up comment you can leave on that PR:

This is a strong first implementation. The userscript is well-structured, keeps selector logic centralized, and treats the working Multi-Pin flow as the primary feature instead of overreaching.

What’s especially good here:

• all DOM access goes through a resolver layer
• selectors are centralized in one canonical config
• hand-raise detection is isolated in scanParticipants()
• grantMultipin() includes retry behavior instead of assuming perfect DOM timing
• debug panel + manual QA checklist make this much easier to validate in live Zoom sessions
• camera/chat features are honestly scaffolded instead of being presented as complete

This is a solid prototype foundation.

For the next pass, I’d suggest focusing on reliability and identity handling before adding more features:

1. Participant identity stability

   • processedParticipants should avoid relying only on visible display names
   • if possible, derive a more stable participant key from DOM attributes or row structure
   • name collisions are likely in real rooms

2. Polling + observer hybrid

   • keep the 2 s polling loop for reliability
   • but consider adding MutationObserver support for participant list changes so detection becomes faster and less wasteful

3. Multi-Pin action hardening

   • log the exact failure reason when grant fails:
     • participant row missing
     • menu not opened
     • option missing
     • click failed
   • this will make selector breakage much easier to diagnose

4. Selector config synchronization

   • the embedded SELECTORS object and selectors/zoom-dom-selectors.json should not drift
   • either generate one from the other or clearly document which one is the runtime source of truth

5. Camera scaffold next step

   • define the exact trigger conditions for camera-off handling
   • example:
     • hand raised
     • Multi-Pin granted
     • camera off for X seconds
     • send reminder
   • keep this deterministic before wiring chat actions

6. Chat monitoring guardrails

   • make sure MutationObserver disconnects/reconnects safely if chat panel rerenders
   • consider rate-limiting spam detections per sender/message pattern

7. Debug panel improvements

   • add:
     • last participant processed
     • last grant success/failure reason
     • selector fallback usage count
   • this would be extremely useful in live testing

8. Prepare migration path

   • this script now looks like a strong behavioral prototype for the future extension
   • document which functions should later map cleanly into:
     • event bus
     • adapter layer
     • platform modules

Important constraints going forward:

• keep Multi-Pin as the core working behavior
• do not add incomplete automation that looks finished
• keep selectors centralized
• preserve honest scaffold labeling for camera/moderation features

Overall this is a very good Phase-1 userscript foundation. The next focus should be identity robustness, failure diagnostics, and making the working Multi-Pin path as reliable as possible in real host/co-host sessions.