Metadata-Version: 2.5
Name: jupyterlab_rtclauncher
Version: 0.3.0
Summary: JupyterLab Launcher tiles that start, join, or stop a Research Platform project's shared real-time-collaboration server.
Project-URL: Homepage, https://git.smce.nasa.gov/scip/research-platform/jupyterlab-RTCLauncher
Project-URL: Bug Tracker, https://git.smce.nasa.gov/scip/research-platform/jupyterlab-RTCLauncher/-/issues
Project-URL: Repository, https://git.smce.nasa.gov/scip/research-platform/jupyterlab-RTCLauncher.git
Author-email: Navteca LLC <info@navteca.com>
License: BSD 3-Clause License
        
        Copyright (c) 2025, Navteca LLC
        All rights reserved.
        
        Redistribution and use in source and binary forms, with or without
        modification, are permitted provided that the following conditions are met:
        
        1. Redistributions of source code must retain the above copyright notice, this
           list of conditions and the following disclaimer.
        
        2. Redistributions in binary form must reproduce the above copyright notice,
           this list of conditions and the following disclaimer in the documentation
           and/or other materials provided with the distribution.
        
        3. Neither the name of the copyright holder nor the names of its
           contributors may be used to endorse or promote products derived from
           this software without specific prior written permission.
        
        THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
        AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
        IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
        DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
        FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
        DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
        SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
        CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
        OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
        OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
License-File: LICENSE
Keywords: jupyter,jupyterlab,jupyterlab-extension
Classifier: Framework :: Jupyter
Classifier: Framework :: Jupyter :: JupyterLab
Classifier: Framework :: Jupyter :: JupyterLab :: 4
Classifier: Framework :: Jupyter :: JupyterLab :: Extensions
Classifier: Framework :: Jupyter :: JupyterLab :: Extensions :: Prebuilt
Classifier: License :: OSI Approved :: BSD License
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Requires-Python: >=3.9
Requires-Dist: jupyter-server<3,>=2.4.0
Provides-Extra: test
Requires-Dist: coverage; extra == 'test'
Requires-Dist: pytest; extra == 'test'
Requires-Dist: pytest-asyncio; extra == 'test'
Requires-Dist: pytest-cov; extra == 'test'
Requires-Dist: pytest-jupyter[server]>=0.6.0; extra == 'test'
Description-Content-Type: text/markdown

# jupyterlab-rtclauncher

A small JupyterLab 4 extension for the NASA Research Platform. It adds
**Launcher tiles** — under a _Collaboration_ section — that start, join, and stop
the project's shared real-time-collaboration (RTC) server.

Without it, members reach the shared server through JupyterHub's admin UI
(`/hub/admin`), which is why they were granted the broad-looking `admin-ui`
scope. This extension replaces that route so the scope can be dropped.

## How it works

The tiles are **state-driven**: the Launcher shows only the actions that are
valid right now, and repaints itself as the shared server's state changes.

```
server down  │ [Start abtesting Collaboration]        ──▶ new tab: /hub/spawn/abtesting-collab
─────────────┼──────────────────────────────────────────────────────────────────────────────
spawning     │ [Starting abtesting Collaboration…]    ──▶ new tab: hub progress page
─────────────┼──────────────────────────────────────────────────────────────────────────────
server up    │ [Join abtesting Collaboration]         ──▶ new tab: /user/abtesting-collab/lab
             │ [Stop abtesting Collaboration]         ──▶ confirm ──▶ DELETE server
─────────────┼──────────────────────────────────────────────────────────────────────────────
stopping     │ [Stopping abtesting Collaboration…]    ──▶ (re-checks status)
```

1. On activation the frontend calls `GET /jupyterlab-rtclauncher/config`, which
   reads the spawn-time environment and answers with the project and shared
   account name.
2. It then polls `GET /jupyterlab-rtclauncher/status` to track whether the shared
   server is running — every 15s when settled, every 3s while a spawn or stop is
   in flight, and immediately whenever the tab regains focus.
3. **Start** opens `<hubPrefix>/spawn/<project>-collab`, **Join** opens
   `/user/<project>-collab/lab`, both in a new browser tab.
   **Stop** posts to `/jupyterlab-rtclauncher/stop` after a confirmation dialog,
   which proxies `DELETE /hub/api/users/<project>-collab/server`.

All three commands also live permanently in the command palette, where they dim
via `isEnabled` instead of appearing and disappearing.

### Why separate tiles, and why they are swapped rather than relabelled

A single toggling tile hid **Join** entirely — a second member had no way in
except to stop the session — and it put a destructive action on the same pixel as
a benign one.

Three permanently-visible tiles were the alternative, but a Launcher tile has no
disabled state to fall back on: `Card` in `@jupyterlab/launcher` never consults
`commands.isEnabled`, so a "greyed out" tile is still fully clickable. Showing
only the valid subset is the only honest option there.

That subset is applied by **adding and disposing launcher items**, not by
changing a command's label. `app.commands.notifyCommandChanged()` does nothing
for the Launcher: it is a `VDomRenderer` bound to `LauncherModel.stateChanged`
and ignores the command registry's `commandChanged` signal, so a state-dependent
label renders once and then goes stale until a browser reload. `launcher.add()`
and disposing its return value are what emit `stateChanged`.

### Why a new browser tab

The shared server is a different JupyterHub user server on its own URL prefix, so
entering it is a full-page navigation. Done in the current tab it evicts the
user's own running notebook from their only window. `window.open` must be called
synchronously from the click handler or pop-up blockers kill it; a blocked
pop-up is reported with the address so the user can open it manually.

### Why stopping matters

The shared server bills the **project pool** for as long as it runs. JupyterHub's
idle culler reaps it after 1h idle, but an open browser tab keeps refreshing
`last_activity` and can defeat that — and since the `admin-ui` scope was dropped,
members have no other way to shut it down. The Stop action closes that gap.

Note the server's 10Gi EBS home persists whether it runs or not; stopping
releases the compute, which is the expensive part.

### Why the stop goes through the server extension

The hub's `_xsrf` cookie is scoped to `Path=/hub/`, so JavaScript served from
`/user/<name>/lab` cannot read it — and JupyterHub 5 requires that XSRF token for
cookie-authenticated, non-GET API calls. The stop therefore proxies through this
extension's server handler, which authenticates with the notebook server's own
`JUPYTERHUB_API_TOKEN`.

That token only carries `admin:servers!user=<project>-collab` when the user
genuinely holds it: JupyterHub resolves `Spawner.server_token_scopes` against the
user's own scopes and drops the rest. A user outside the project's Keycloak group
gets a token without it and the hub answers 403. **The extension grants nothing.**

Requires rp-deployment to request that scope via `Spawner.server_token_scopes`
(`terraform/config/20-nojovyan.py`). Without it, `can_control` is false and the
tile degrades to start-only.

### Which projects get a tile

**Any project with collaboration enabled** — there is no hardcoded project list
and no allowlist to configure here.

The enablement signal is the `RP_COLLAB_ACCOUNT` environment variable:

1. A platform admin flips **Real-Time Collaboration → Enable collaboration** for a
   project in the RPAdmin console, which provisions its login-less
   `<key>-collab` principal.
2. RPAdmin's `GET /api/me/spawn-identity` — already called on every spawn — now
   returns `collab_account: "<key>-collab"` for that project, or `null`.
3. rp-deployment `terraform/config/20-nojovyan.py` forwards a non-null value to
   the notebook as `RP_COLLAB_ACCOUNT`.
4. This extension shows the tile only when that variable is present.

So enabling a new project is a toggle in RPAdmin — no change to this extension,
the spawner, or the image. `OSSProject` supplies the project key for the tile's
label; the account name comes from `RP_COLLAB_ACCOUNT` so the naming convention
lives only in RPAdmin.

> **Operational note.** JupyterHub access is granted separately, by the
> `RP_COLLAB_PROJECT_KEYS` allowlist in rp-deployment (the ISSO widening gate,
> feature 083). A project enabled in RPAdmin but missing from that allowlist will
> show a tile whose spawn the hub refuses — enabling collaboration is a two-step
> operation by design, and the two must be kept in sync.

### The tile grants nothing

It is a link. Starting the shared server requires `admin:servers!user=<acct>`
and entering it requires `access:servers!user=<acct>`; both are granted to the
project's Keycloak `/smdc-oss/<project>` group by rp-deployment
`terraform/config/41-collab-accounts.py`, and auto-revoke when Keycloak drops
the membership. A user without them who follows the link is refused by the hub.

The tile hides itself when `RP_COLLAB_ACCOUNT` is unset (collaboration is off for
the project), or when the current server _is_ the collaboration server
(`JUPYTERHUB_USER` ends in `-collab`).

## Install

```bash
pip install jupyterlab-rtclauncher
```

Both the frontend and the server extension are enabled automatically. To verify:

```bash
jupyter labextension list   # jupyterlab-rtclauncher ... enabled OK
jupyter server extension list
```

## Development

```bash
pip install -e ".[test]"
jupyter labextension develop . --overwrite
jlpm build
```

Run the tests:

```bash
python -m pytest tests/   # server extension
jlpm test                 # frontend
```

Rebuild after a source change with `jlpm build`, or run `jlpm watch` in one
terminal and `jupyter lab` in another.

## Uninstall

```bash
pip uninstall jupyterlab-rtclauncher
```

## Related

- Feature 083 — RTC collaboration accounts (`rpadmin/specs/083-rtc-collab-accounts/`)
- `jupyterlab-resource-tracker` — the usage & cost extension shipped in the same image
