Tiger Portal - Let users upload a transcript or meeting link to generate a dashboard

[yaqi-lyu]

Addresses #137

Summary

Adds the Parrot portal — a self-serve entry point where an SSW user signs in and either uploads a Teams .vtt transcript or points at a Teams meeting (full join link, short link, or a Meeting ID + attendee email), then gets a generated Tiger dashboard, with a per-user history of their submissions and their status.

Both paths flow through the existing queue → Container App Job → dashboard pipeline via a sourceType discriminated union, so no separate processing path was introduced and the automated Graph webhook path is untouched.

Architecture

• Portal SPA (portal/) — React 19 + Vite, styled with Tailwind using the same SSW design tokens as the generated dashboards. Views: Submit (Upload transcript / Meeting link or ID) + "My submissions".
• Portal API (functions-portal/) — a separate Azure Functions app (func-tiger-portal-*), split from the Graph webhook app so its SWA-only auth boundary never touches the public webhook. Endpoints: POST /api/v1/submissions (file upload), POST /api/v1/meetings (meeting link or Meeting ID), GET /api/v1/submissions (per-user history). Stays Graph-free — the meeting endpoint only validates the link/ID format; Graph resolution happens in the Job.
• Login — Azure Static Web Apps built-in Entra (AAD) auth, tenant-locked to SSW, reusing the existing Graph app registration (no new registration). The API is authLevel: anonymous; the trust boundary is the auto-provisioned "Azure Static Web Apps (Linked)" EasyAuth provider (verified post-deploy).
• Meeting resolution — processor/downloadFromMeetingLink.js runs in the Container App Job (which already has Graph creds):
  • Join / short link — resolves join URL → organizer's onlineMeetings → latest transcript → VTT. The organizer/tenant come from the link's own context param, so a join link alone is sufficient.
  • Meeting ID — carries no organizer, so the Job searches under candidate user IDs (the submitter first, then the supplied attendee) and keeps going past a 403 on any one candidate instead of aborting, surfacing a diagnosable reason if none resolve.
• Persistence — a Cosmos submissions container (partitioned by /projectName) holds {owner, status, dashboardUrl, …}. The Portal API writes the record on submit; the processor patches status/dashboardUrl on completion. For meeting submissions the history display name backfills from the resolved meeting subject when no project name was given.
• Hosting plan — the Portal API rides the Graph app's existing Y1 Consumption plan rather than provisioning its own. A second Y1 Linux plan won't place in this RG ("Dynamic SKU, Linux Worker not available" — the Australia East Linux webspace this RG maps to won't take another); Y1 scales per-app, so the apps stay independent.

Acceptance criteria (from #137)

#	Criterion	Status
1	Visible menu item to submit content	✅ Submit view + nav
2	Supports providing a meeting link	✅ full join link, short link, or Meeting ID + attendee email
3	Supports providing a meeting transcript	✅ .vtt upload
4	Valid meeting link creates a request	✅ link/ID → meetingLink job
5	Valid transcript creates a request	✅ upload → uploadedTranscript job
6	Confirmation that the request was accepted	✅ 202 + success state + reference ID
7	Processing status is visible	✅ "My submissions" (Queued / Processing / Ready / Failed)
8	Link to the dashboard on completion	✅ "Open dashboard" on completed rows
9	Authorization prevents unauthorized processing/viewing	⚠️ Partial — tenant-locked login + per-user list isolation. Any authenticated SSW user with a valid meeting link/ID can process it (stricter than the existing anonymous TriggerProcessing); participant-level restriction is a follow-up. Report-body isolation is intentionally deferred: dashboards remain public shareable URLs so users can send them to attendees.

Design notes

• The Portal API shares the Graph app's Consumption plan (hostingPlanId, wired from functionApp.outputs.hostingPlanId) — no separate plan is created, and referencing that output sequences the Portal API module after the Graph app.
• SWA requires the Standard plan and a supported region (australiaeast is not one; defaults to East Asia).
• Meeting resolution relies on the Teams application access policy already configured for the Graph app (the same one TriggerProcessing uses), plus the User.Read.All application permission (Meeting-ID submissions resolve an attendee email → object id).
• staticwebapp.config.json carries the SSW tenant GUID directly in the file. There is no build-time substitution and no SSW_TENANT_ID variable — the portal deploy workflows were removed in 1cd4805 and the portal is deployed by hand for now.

Deploying to staging (which is production)

staging-named resources ARE production (dashboards.sswtiger.com). There is no separate prod bicepparam and no production CI — every step below is manual.

infra/staging.bicepparam now carries the four portal flags explicitly:

param deployPortal = true                        // build the Portal API + SWA + containers
param manageKeyVaultRoleAssignment = false       // roles were granted by hand
param manageTranscriptBlobRoleAssignment = false // roles were granted by hand
param manageSwaAuthSettings = false              // SWA app settings were set by hand

The three false flags are the point: with them off, Bicep emits no Microsoft.Authorization/roleAssignments resource and never calls getSecret(), so a plain Contributor can run this deployment and nothing collides with the sysadmin's manual grants.

Order matters

Two independent constraints, and they compose into one order:

1. Bicep before any func azure functionapp publish. The Node 22 move lives in Bicep (linuxFxVersion: 'NODE|22'), while the locked Azure SDKs in both Function Apps declare engines.node >=22. Publishing first drops a Node-22 package onto an app still running Node 20.
2. Graph Function App before the Portal API. If the Portal API goes live first, portal messages land on the old queue consumer, which throws Missing required IDs in queue message and sends them to the poison queue.

So: image → Bicep → Graph app → Portal API → SPA. Running Bicep first is safe for constraint 2 — it only creates func-tiger-portal-staging as an empty shell with no code, so nothing can enqueue a portal message until step 4.

⚠️ Flipping linuxFxVersion restarts func-tiger-staging. Between that restart and step 3 the app serves its previously-deployed package on Node 22 (pure JS, no native modules — fine), but the Graph webhook is briefly unavailable. Graph retries failed notifications, so this is low risk rather than no risk.

Before you start

• Deployer has Contributor on SSW.Transcript-Intelligence-Group-Event-Reasoning.Dev. (Key Vault Secrets User is not needed while manageSwaAuthSettings = false.)
• Storage Blob Data Contributor for id-tiger-staging → satigerstaging exists (granted manually at account scope). Without it the Job cannot download an uploaded transcript.
• swa-tiger-portal-staging exists (hand-created; host polite-stone-048f66900.7.azurestaticapps.net). Bicep adopts it in place — same name/region/SKU. Never delete and recreate it: a new hostname invalidates every registered Entra callback.

Steps

1. Build + push the container image — build-container.yml, tag latest.
   Carries the new entrypoint.sh, downloadFromMeetingLink.js, downloadUploadedTranscript.js, updateSubmissionStatus.js, parseSubject.js. Easy to forget: on the old image, a portal job falls through the TRANSCRIPT_SOURCE_TYPE check into local mode and dies without ever updating its history row.

2. Dry-run the infra change, then apply:

   cd infra
   az deployment group what-if -g "SSW.Transcript-Intelligence-Group-Event-Reasoning.Dev" \
     --template-file main.bicep --parameters staging.bicepparam
   az deployment group create  -g "SSW.Transcript-Intelligence-Group-Event-Reasoning.Dev" \
     --template-file main.bicep --parameters staging.bicepparam

   Creates func-tiger-portal-staging, the transcript-submissions blob container and the Cosmos submissions container, links the backend to the SWA, moves both Function Apps to NODE|22, and adds FUNCTIONS_REQUEST_BODY_SIZE_LIMIT + TRANSCRIPT_STORAGE_* to the existing Graph app. Note the portalSwaUrl / portalEntraRedirectUri outputs.

3. Deploy the Graph webhook Function App — cd azure-function && func azure functionapp publish func-tiger-staging.
   This is what teaches the queue consumer about uploadedTranscript / meetingLink. ProcessTranscriptQueue.js was substantially refactored, so this also needs a regression check in step 8.

4. Deploy the Portal API — cd functions-portal && func azure functionapp publish func-tiger-portal-staging.

5. Build + deploy the SPA — cd portal && npm ci && npm run build, then publish portal/dist with the SWA deploy token:

   az staticwebapp secrets list -n swa-tiger-portal-staging \
     -g "SSW.Transcript-Intelligence-Group-Event-Reasoning.Dev" --query 'properties.apiKey' -o tsv

6. Verify the auth boundary — ./infra/scripts/verify-portal-auth-boundary.sh staging.
   Do not hand out the portal URL until this reports [ OK ]. It checks the one control that makes the authLevel: anonymous endpoints safe: the "Azure Static Web Apps (Linked)" EasyAuth provider. If it is missing, the API is reachable from the internet and x-ms-client-principal becomes caller-supplied — anyone can impersonate any user. Nothing in the code can detect this, and this is a point-in-time check, not monitoring.

7. One-off Entra setup (likely already done with the sysadmin — confirm, don't assume):

   • Redirect URI https://polite-stone-048f66900.7.azurestaticapps.net/.auth/login/aad/callback registered on app registration 10e2928c-….
   • That registration allows user sign-in: Web platform, ID tokens enabled, delegated openid/profile/email. It was previously app-only.

8. Smoke test — upload a .vtt and submit a meeting link; watch each row go Queued → Processing → Ready and open its dashboard. Then re-check the Graph webhook path end to end, since its queue consumer changed.

Rollback

Setting deployPortal = false and redeploying does not delete the SWA or the Portal API — incremental mode simply stops managing them. To actually take the portal down, unlink the backend or stop serving the SPA.

Deploying to test

infra/test.bicepparam now sets param deployPortal = true. The whole portal stack already exists in test, hand-created, so this adopts it rather than building anything: what-if reports 18 changes, all Modify — no Create, no Delete.

What is already in place and matches the Bicep exactly:

Resource	Deployed	Bicep
swa-tiger-portal-test	East Asia, Standard, staging envs Disabled	same name / region / SKU
linked backend portalApi	→ func-tiger-portal-test, australiaeast	same link name and target
func-tiger-portal-test	exists, `NODE	20`
SWA app settings	AZURE_CLIENT_ID, AZURE_CLIENT_SECRET_APP_SETTING_NAME set by hand	untouched (manageSwaAuthSettings = false)
azureStaticWebApps EasyAuth provider	present on the backend	re-asserted by the link
transcript-submissions container	exists on satigertest	adopted
Cosmos submissions container	exists on cosmos-tiger-test	adopted
Storage Blob Data Contributor for id-tiger-test	granted at account scope on satigertest	not managed (manageTranscriptBlobRoleAssignment = false)

The only substantive change is linuxFxVersion: NODE|20 → NODE|22 on func-tiger-test and func-tiger-portal-test. what-if also reports Delete on four SWA properties (stableInboundIP, provider, trafficSplitting, deploymentAuthPolicy) — these are computed/read-only fields the template does not declare, which is a known what-if over-report, not a real removal.

Same order as staging:

1. Build + push the container image — build-container.yml, tag test (only if processor/ changed).
2. Apply the infra — az deployment group create -g "SSW.Transcript-Intelligence-Group-Event-Reasoning.Dev" --template-file main.bicep --parameters test.bicepparam. This is what moves func-tiger-test to Node 22, so it must come first.
3. Deploy the Graph webhook Function App — run the Deploy Azure Function Test workflow (already pinned to node-version: 22).
4. Deploy the Portal API — cd functions-portal && func azure functionapp publish func-tiger-portal-test.
5. Build + deploy the SPA to swa-tiger-portal-test.
6. Verify the auth boundary — ./infra/scripts/verify-portal-auth-boundary.sh test.

Testing

• All suites green: processor + lib 122, functions-portal 56, azure-function 9, portal 45.
• portal typechecks (tsc -b) and builds; az bicep build succeeds; staging.bicepparam binds; entrypoint.sh and both infra/scripts/*.sh pass bash -n.
• Not yet done: end-to-end run against a live Cosmos/SWA/Graph environment.
• npm run lint is currently red repo-wide (102 errors, a handful in new code). Biome config landed here; the sweep did not. Do not wire lint into CI until that is done.

Review fixes folded into this PR

• Submitter audit trail — the actor now survives normalization onto the queue as {email, subject} (roles/type deliberately dropped so nobody mistakes it for an authorization input), lands in SUBMITTED_BY, and is logged by ProcessTranscriptQueue and by the Job itself. A Meeting-ID submission can pull a transcript for a meeting the submitter only knows the ID of, so "who asked for this" must be answerable from logs alone.
• Live status in "My submissions" — the list only refreshed on mount. A tab switch remounts the view, so navigating back did pick up changes, but a submitter who stayed on the list watched a frozen Queued for the whole multi-minute run. It now polls every 20 s while any row is still running and stops the moment none are.
• Failure reasons — failed rows said Unavailable while the Job was throwing away genuinely useful text. The reason is now persisted to failureReason (capped, cleared when a row leaves failed) and rendered. Download errors surface the user-facing message; processor errors get a generic one, since that stdout is internal diagnostics with no user action in it.
• Stale-record sweep — a hard SIGKILL used to strand a row on processing forever (SIGTERM was already handled). The existing KeepWarm timer now also sweeps hourly, failing rows older than 90 min — comfortably clear of the Job's own 3600 s replicaTimeout so a slow-but-healthy run is never killed underneath itself.
• manageSwaAuthSettings flag — getSecret() on the RBAC-enabled vault silently required the deploying principal to hold Key Vault Secrets User, to re-write app settings that were already correct. Now gated off by default. Also documented that this config resource is a full replace, not a merge.
• portal-post-deploy.sh → verify-portal-auth-boundary.sh — it had rotted into stale reminders (including one pointing at a config placeholder that no longer exists) around a single check that mattered. Cut to that one check; the name now prevents the same accretion.

Follow-ups

• Participant-level authorization for meeting-link submissions (tighten AC 9). Today a Meeting ID plus any colleague's email resolves a transcript, because the Job fetches as the meeting's real organizer.
• Report-body isolation, if reports must not be publicly shareable.
• Per-user submission quota — each accepted submission starts a Container App Job running Claude Opus, with no throttle today.
• Project-name namespacing: a submitter can file into an existing project's namespace just by typing its name.
• Repo-wide Biome format sweep.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Introduces a new self-serve “Tiger Portal” (React SPA + separate Portal API Azure Functions app) that lets authenticated SSW users submit either an uploaded .vtt transcript or a Teams meeting reference, flowing through the existing queue → Container App Job → dashboard pipeline with submission history persisted in Cosmos DB.

Changes:

• Adds Portal SPA (portal/) and Portal API (functions-portal/) with SWA-based authentication, per-user submission history, polling, and actionable failure reasons.
• Extends the processor + queue message contract to support new source types (uploadedTranscript, meetingLink) and best-effort status updates back into Cosmos.
• Updates infrastructure (Bicep + scripts) to provision Portal resources, Cosmos submissions container, transcript-submissions blob container, and deployment verification for the SWA-linked auth boundary.

Reviewed changes

Copilot reviewed 86 out of 93 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
processor/updateSubmissionStatus.js	Best-effort Cosmos status/URL/password updates for portal submissions after job completion.
processor/projectSetup.test.js	Tests for transcript filename validation including collision-resistant suffix.
processor/projectSetup.js	Allows YYYY-MM-DD-HHmmss[-suffix].vtt and uses node: builtins.
processor/parseSubject.js	Shared subject parsing for consistent project/title derivation across sources.
processor/downloadUploadedTranscript.test.js	Tests for uploaded-transcript download + validation + speaker-label detection.
processor/downloadUploadedTranscript.js	Downloads private uploaded transcript from Blob, validates/canonicalizes it for processing.
processor/downloadTranscript.js	Reuses shared subject parsing (moved into parseSubject.js).
portal/vite.config.ts	Vite dev proxy config with local SWA principal injection and Vitest setup.
portal/tsconfig.node.json	TS config for Vite config project reference.
portal/tsconfig.json	TS project references for app + node configs.
portal/tsconfig.app.json	Strict TS config for portal app source.
portal/src/vite-env.d.ts	Vite client type references.
portal/src/views/UploadView.test.tsx	Tests for upload/link submission validation, flows, and error rendering.
portal/src/views/SignInView.tsx	Sign-in screen used for logout landing + local-dev fallback.
portal/src/views/DashboardsView.test.tsx	Tests for cached rendering, polling, failure reasons, and password display behavior.
portal/src/testSetup.ts	Common test cleanup and jest-dom setup for Vitest.
portal/src/styles.css	Tailwind v4 + self-hosted Inter + design-system tokens for portal styling.
portal/src/main.tsx	Bootstraps app, primes submissions fetch, binds remembered principal for fast paint.
portal/src/components/TranscriptDropzone.tsx	Upload dropzone with progressive drag-and-drop and accessible file input.
portal/src/components/AppHeader.tsx	Header with tab navigation, user identity display, and sign-out handling.
portal/src/App.tsx	SPA shell with auth gating, navigation via path, and cache binding on auth confirm.
portal/src/App.test.tsx	Tests for auth gating, remembered principal fast paint, and cache owner binding.
portal/src/api/submissionsCache.test.ts	Tests for cache hydration, owner scoping, persistence, concurrency, and clearing.
portal/src/api/SubmissionClient.ts	Client for submissions + meetings endpoints with auth-challenge handling and primed GET adoption.
portal/src/api/SubmissionClient.test.ts	Tests for stable response parsing, auth redirect handling, 403 surfacing, and primed-request adoption.
portal/src/api/RequestAdapter.ts	Request abstraction (same-origin cookies) for future auth/proxy swaps.
portal/src/api/authClient.ts	SWA auth client with remembered principal (localStorage) and name/email/initials helpers.
portal/public/staticwebapp.config.json	SWA routing + auth enforcement + immutable assets caching + 401 redirect override.
portal/package.json	Portal dependencies/scripts (Vite, React 19, Tailwind v4, Vitest).
portal/index.html	App shell with early submissions prefetch to reduce perceived cold start latency.
package.json	Adds Biome lint/format scripts and devDependency at repo root.
lib/cosmosClient.js	Adds submissions container access + updateSubmissionStatus patch helper.
infra/test.bicepparam	Adds portal-related flags and disables role/auth settings management by default in test.
infra/staging.bicepparam	Enables portal deployment and documents/locks down manual RBAC/auth settings behavior.
infra/setup-cosmos.sh	Adds submissions container to Cosmos setup script.
infra/scripts/verify-portal-auth-boundary.sh	Verifies SWA-linked EasyAuth provider boundary exists on Portal API Function App.
infra/modules/storage.bicep	Adds transcript-submissions private container + optional Blob Data Contributor assignment.
infra/modules/staticWebApp.bicep	New SWA module: Standard plan, linked backend, optional Entra auth appsettings.
infra/modules/portalApiApp.bicep	New Portal API Function App module (Linux consumption) on shared plan with required app settings.
infra/modules/functionApp.bicep	Adds request body size limit + transcript storage env vars + exposes hostingPlanId output.
infra/modules/cosmosDb.bicep	Adds Cosmos submissions container (partitioned by /projectName).
infra/modules/containerApp.bicep	Passes transcript storage account/container env vars to the Container App Job.
infra/main.bicep	Orchestrates portal stack (Portal API + SWA), transcript-submissions container, and related flags/outputs.
functions-portal/src/services/submissionValidation.test.js	Tests project slugification, VTT validation, and canonical filename generation.
functions-portal/src/services/submissionValidation.js	Validates project name + uploaded VTT, sanitizes filename, builds canonical processor filename.
functions-portal/src/services/submissionStore.test.js	Tests Cosmos query/patch shapes for user listing + stale sweep behavior.
functions-portal/src/services/submissionStore.js	Cosmos-backed per-user submissions store with warmup + stale sweep.
functions-portal/src/services/submissionStorage.test.js	Tests connection-string path avoids managed-identity client construction.
functions-portal/src/services/submissionStorage.js	Blob storage client for transcript submissions with MI/connection-string seam.
functions-portal/src/services/submissionService.test.js	Tests upload, queue publish, rollback behavior, and optional history record persistence.
functions-portal/src/services/submissionService.js	Service to validate, upload transcript source, write history record, and enqueue v2 message.
functions-portal/src/services/submissionQueue.js	Queue publisher for transcript-notifications messages (base64 JSON).
functions-portal/src/services/submissionActor.test.js	Tests SWA principal decoding + role dropping + defensive fallback identity.
functions-portal/src/services/submissionActor.js	Resolves authenticated actor from x-ms-client-principal (portable identity).
functions-portal/src/services/meetingLinkValidation.test.js	Tests meeting link classification + attendee email validation.
functions-portal/src/services/meetingLinkValidation.js	Validates/normalizes Teams join links or numeric meeting IDs (no Graph call).
functions-portal/src/services/credential.test.js	Tests MI-vs-DefaultAzureCredential selection and caching behavior.
functions-portal/src/services/credential.js	Shared cached data-plane credential selection (MI when deployed, default chain locally).
functions-portal/src/http.js	Shared JSON response helper (no-store + JSON content-type).
functions-portal/src/functions/SubmitTranscript.test.js	Tests multipart handling, size rejection, validation mapping, and auth gating.
functions-portal/src/functions/SubmitTranscript.js	Portal API endpoint for transcript upload submission (anonymous + SWA-bound identity).
functions-portal/src/functions/SubmitMeetingLink.test.js	Tests meeting-link/ID submission flows, resolver identity list, and rollback behavior.
functions-portal/src/functions/SubmitMeetingLink.js	Portal API endpoint for meeting-link/ID submission (enqueues v2 meetingLink message).
functions-portal/src/functions/ListSubmissions.test.js	Tests per-user listing mapping + unauthenticated rejection + error mapping.
functions-portal/src/functions/ListSubmissions.js	Portal API endpoint for per-user submission history with Cosmos warmup.
functions-portal/src/functions/KeepWarm.test.js	Tests keep-warm cadence, sweep throttling, and failure swallowing.
functions-portal/src/functions/KeepWarm.js	Timer to reduce cold starts and sweep stale submissions hourly.
functions-portal/src/functions/index.js	Portal Functions entrypoint wiring.
functions-portal/package.json	Portal API package metadata and test/start scripts.
functions-portal/host.json	Azure Functions host logging + extension bundle config for portal app.
biome.json	Adds Biome formatter/linter configuration for the repo.
azure-function/src/services/queueMessage.test.js	Tests queue message normalization/dedup/env building for new source types and actor audit label.
azure-function/src/services/graphMeetingUrl.test.js	Tests correct escaping/encoding of Graph onlineMeetings JoinWebUrl filter.
azure-function/src/services/graphMeetingUrl.js	Shared helper for building properly encoded JoinWebUrl filter URLs.
azure-function/src/functions/TriggerProcessing.js	Uses graphMeetingUrl helper for JoinWebUrl-based meeting lookup.
azure-function/package.json	Adds test script and bumps Node engine to >=20.
azure-function/package-lock.json	Updates lockfile (notably pulls core-rest-pipeline requiring Node >=22).
.gitignore	Ignores portal + portal-functions artifacts and SWA emulator output.
.gitattributes	Enforces LF normalization and marks binary assets.
.editorconfig	Enforces consistent formatting defaults (UTF-8, LF, 2-space indent).

Files not reviewed (2)

• azure-function/package-lock.json: Generated file
• functions-portal/package-lock.json: Generated file

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[AttackOnMorty]

For next time:

My first feeling is that we can just implement a one-way: use the meeting link to generate the dashboard.

Implement a minimum workable feature.

[AttackOnMorty]

1. why it doens't support the recording share link? I noticed it supports meeting ID.

As a user, I thought I would

• Go to the Teams Channel
• Click the share on video recap
• Get the share link
• Then paste in the SSW.Tiger

[AttackOnMorty]

I submitted one using Teams ID (465 857 077 869) but failed

1. Please investigate and fix.

[AttackOnMorty]

Small UI feedback

1. Duplicate text "Submit"
2. "Generate Dashboard" looks plain; can we change it to something like "Generate AI Insights" (ask AI for button text)

[AttackOnMorty]

1. Can we add the process time duration if it's easy?

[yaqi-lyu]

I submitted one using Teams ID (465 857 077 869) but failed

1. Please investigate and fix.

Fixed. This happened because Microsoft changed its settings. Previously, access to VTT transcripts was enabled by default, but in July, Microsoft changed the default to “none,” so users now have to configure it manually. This is a pretty bad change, and it affected many meetings today.

[yaqi-lyu]

Small UI feedback

1. Duplicate text "Submit"
2. "Generate Dashboard" looks plain; can we change it to something like "Generate AI Insights" (ask AI for button text)

Fixed. Updated the words

[yaqi-lyu]

1. Can we add the process time duration if it's easy?

Added.