Improve client list display and add ASCOM status tooltip

[chvvkumar]

📋 Overview

This pull request enhances the user interface by improving the display of connected clients and adding an informative tooltip for ASCOM status. It modifies the client management logic to show unique clients by IP address with their most recent connection details. Additionally, a new tooltip provides explanations for the ASCOM status directly within the setup page.

🔄 Changes by Category

• Features:
  • Updated client list handling to display unique clients based on IP address, showing their most recent connection information.
  • Added an informational tooltip for the ASCOM Status field on the setup page, providing explanations.

---

_{📊 Analyzed 6 commit(s) | 🕐 Updated: 2026-01-05T01:46:06.914Z | Generated by GitHub Actions}

---

In general, fix this by explicitly setting permissions: for the workflow or for individual jobs so that GITHUB_TOKEN has only the scopes needed. For a compute-only job like prepare, that typically means contents: read at most.

The safest single change that preserves existing behavior is to add a root-level permissions: block (applies to all jobs that don’t override it) with contents: read. None of the shown steps require write access to repository contents, issues, or pull requests—they only read the code, compute versions, and interact with Docker Hub using a separate secret. Adding the block near the top of .github/workflows/build-and-release.yml (after name: and before on:) keeps the workflow clear and conventional. No new imports or methods are needed; this is a pure YAML configuration change.

Concretely:

• Edit .github/workflows/build-and-release.yml.
• Insert:

  permissions:
    contents: read

  between line 2 and line 3 (between name: Build and Release and the on: block).
  This constrains GITHUB_TOKEN for the prepare, build, merge, and release jobs (unless any of them already define their own permissions: blocks later in the file, which we must not assume or modify beyond the shown snippet).

To fix the problem, explicitly scope the GITHUB_TOKEN permissions so that jobs do not inherit potentially broad default permissions. The least privilege required here is for actions/checkout@v4, which only needs contents: read. No job in the shown snippet needs to write to the repository, manage issues, or modify PRs.

The best, minimal-impact fix is to add a permissions: block at the top (workflow) level, directly under name: Build and Release and before the on: key, with contents: read. This will apply to all jobs (prepare, build, merge, release, pr-commit-summary, etc.) that don’t override permissions locally, without changing any existing functionality. No new imports or dependencies are needed; this is a pure YAML configuration change.

Concretely:

• Edit .github/workflows/build-and-release.yml.
• Insert:

permissions:
  contents: read

after line 1 (name: Build and Release) and before line 3 (on:).
No other lines in the file need to be changed.

In general, the fix is to explicitly restrict the GITHUB_TOKEN permissions in the workflow to the minimal set required. Since this workflow only needs to checkout the repository and then interact with Docker Hub (using external credentials), the GITHUB_TOKEN only needs contents: read. No additional scopes (like pull-requests, issues, or packages) are required by the shown steps.

The best way to fix this without changing functionality is to add a top‑level permissions: block so that it applies to all jobs unless overridden. Insert it near the top of .github/workflows/snd.yml, after the name: (or after the on: block; any top‑level location is fine) and set it to contents: read. This will ensure GITHUB_TOKEN cannot modify repository contents or other resources while still allowing actions/checkout to function. No imports or additional definitions are needed in YAML.

Concretely: edit .github/workflows/snd.yml to add:

permissions:
  contents: read

at the top level of the workflow (e.g., between line 2 and line 3 in the provided snippet).

In general, fix this by explicitly specifying a minimal permissions: block for the workflow or for each job, reducing GITHUB_TOKEN to read‑only access (or disabling unused scopes) while still allowing the current steps to succeed.

The best targeted fix here is to add a permissions: block at the workflow root level (just under name: or on:), so it applies to both build and merge jobs. None of the steps require write access to the repository; they only need to read the code (handled by actions/checkout) and use external Docker credentials. Therefore, we can set contents: read and disable everything else by using permissions: read-all. For maximum clarity and least privilege, we can explicitly use permissions: read-all, which is a valid shortcut meaning “all scopes read‑only”. This will satisfy CodeQL by explicitly constraining GITHUB_TOKEN while not changing the existing behavior of the jobs.

Concretely:

• Edit .github/workflows/snd.yml.
• Insert a permissions: read-all block near the top, after the on: block (or directly after name:; both are valid, but we’ll put it after on: to keep triggers and permissions grouped).
• No imports or extra methods are needed; this is pure YAML configuration.