e2e(FR-2982): assert inviter email is shown in folder invitation modal by agatha197 · Pull Request #7610 · lablup/backend.ai-webui

agatha197 · 2026-05-27T05:21:39Z

Resolves #7608 (FR-2982)

Stacked on #7607 — merge that one first.

Summary

Extend acceptAllInvitationAndVerifySpecificFolder (in e2e/utils/test-util.ts) with an optional inviterEmail parameter.
When the parameter is provided, assert that the open FolderInvitationResponseModal contains that email before the Accept loop. This catches regressions in the modal's "From" field — i.e. broken item.inviter_user_email plumbing or a broken invitation-inviter-email capability check.
Pass userInfo.user.email (the inviter set up by loginAsUser in beforeEach) at the single existing call site in e2e/vfolder/vfolder-crud.spec.ts ("User can share vFolder"), so the assertion runs in CI.
No production source changes; e2e-only.

Why

The "From" field is the only place an invitee sees who shared a folder with them. Today no e2e / unit / Storybook test asserts that field is non-empty or correct.
Existing test already exercises the modal, so the new check is a low-cost extension rather than a new scenario.

Test plan

CI: existing vfolder/vfolder-crud.spec.ts "User can share vFolder" run passes with the new assertion enabled.
On a backend with invitation-inviter-email capability, the assertion confirms user@lablup.com is rendered inside the modal.
On a backend without that capability, the assertion would fail (the modal falls back to item.inviter, a non-email value); intentional — this is the regression we want to surface.

agatha197 · 2026-05-27T05:21:53Z

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

flow:merge-queue - adds this PR to the back of the merge queue
flow:hotfix - for urgent changes, fast-track this PR to the front of the merge queue

You must have a Graphite account in order to use the merge queue. Sign up using this link.

_{An organization admin has required the Graphite Merge Queue in this repository.} _{Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.}

This stack of pull requests is managed by Graphite. Learn more about stacking.

Copilot

Pull request overview

Extends an existing E2E helper to optionally assert the inviter's email appears in the folder invitation modal, then enables the assertion in the existing vfolder share test. This closes a coverage gap around the modal's "From" field, which currently has no unit, Storybook, or E2E verification.

Changes:

Add optional inviterEmail parameter to acceptAllInvitationAndVerifySpecificFolder and assert the modal contains it when provided.
Pass userInfo.user.email at the existing call site in vfolder-crud.spec.ts so the assertion runs in CI.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
e2e/utils/test-util.ts	Adds optional `inviterEmail` argument and a `toContainText` assertion on the invitation modal.
e2e/vfolder/vfolder-crud.spec.ts	Passes inviter email (`userInfo.user.email`) to the helper to enable the new check.

github-actions · 2026-05-27T09:35:13Z

Coverage Report for react-coverage (./react)

Status	Category	Percentage	Covered / Total
🔵	Lines	6.52%	1799 / 27572
🔵	Statements	5.34%	1994 / 37279
🔵	Functions	5.27%	297 / 5631
🔵	Branches	3.73%	1300 / 34831

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
react/src/components/DefaultProviders.tsx	26.76%	14.7%	5.88%	27.53%	92, 104-124, 164-182, 189-218, 228-231, 236-258, 264-324
react/src/components/LoginView.tsx	0%	0%	0%	0%	56-1146

Generated in workflow #1123 for commit bdbe490 by the Vitest Coverage Report Action

…page (#7607) Linked Jira: [FR-2979](https://lablup.atlassian.net/browse/FR-2979) Backend counterpart: [BA-6193](https://lablup.atlassian.net/browse/BA-6193) (merged, SSO empty-email) Backend follow-up: [BA-6228](https://lablup.atlassian.net/browse/BA-6228) (expose `inviter_user_email` as a separate DTO field)  ## TL;DR FR-2979 ("Summary page invitation card shows empty `From:`") has **two independent root causes**. This PR fixes the frontend one. The other one is server-side and lives in BA-6193. Both need to land for FR-2979 to be fully resolved end-to-end. | # | Root cause | Where it lives | Status | | --- | --- | --- | --- | | 1 | Both the Summary card and `FolderInvitationResponseModal` read `invitation.inviter` blindly. The legacy backend used to put the inviter email there, but manager v25.6.0 plans to expose it under a separate `inviter_user_email` field. This PR gates the read with the existing `invitation-inviter-email` capability flag and falls back to the legacy `inviter` field for older managers. | Frontend (this PR) | Fixed here | | 2 | Backend persists `User.email = ""` for SSO-created accounts and mirrors it straight into the invitation response, so the sender renders blank regardless of the field name; the accept handler's `if not inviter_email` check also raises on the empty string. | Backend ([BA-6193](https://lablup.atlassian.net/browse/BA-6193)) | Tracked separately | After **this PR alone**: users invited by a manually-created sender on a manager that exposes `inviter_user_email` see the sender's email again. Users whose inviter is an SSO-created account still see blank — unblocked only by BA-6193. ## What this PR does Use the same capability-check pattern that `FolderInvitationResponseModal.tsx` originally followed (added in FR-1101): read `baiClient.supports('invitation-inviter-email')` and choose the field accordingly. Both call sites also fall back to `'-'` to avoid rendering `From: undefined` when neither field has a value. - `react/src/components/FolderInvitationResponseModal.tsx` — add `useSuspendedBackendaiClient` + `hasInviterEmail`, render `(hasInviterEmail ? item.inviter_user_email : item.inviter) || '-'` in the "From" descriptions item. - `react/src/components/SummaryPageItems/SummaryItemInvitation.tsx` — same gating in the card title. ## Known limitation (and the backend follow-up that unblocks it) The current `VFolderInvitationDTO` (`src/ai/backend/common/dto/manager/vfolder/response.py` in `lablup/backend.ai`) only declares the single `inviter` field: ```python class VFolderInvitationDTO(BackendAISchema): inviter: str = Field(description="Inviter email, or username if email is empty") ... ``` The handler collapses both possibilities into that field (`inviter=info.inviter_user_email or info.inviter_username or ""`). So on managers where the capability flag is *true* but the DTO has not yet been expanded with `inviter_user_email`, this PR will render `From: -` for every invitation. Older managers (capability = false) continue to read the legacy `inviter` field and work as before. The backend side needs to add `inviter_user_email` as a separate DTO field for the capability-gated branch to actually show the email. Tracked separately in [BA-6228](https://lablup.atlassian.net/browse/BA-6228) — until that lands, manager ≥ 25.6.0 will render `From: -` for every invitation. Older managers (capability = false) continue to read the legacy `inviter` field and work as before. ## What this PR explicitly does NOT fix — and why the frontend can't The SSO-side problem above is **not** addressable from the client: - The invitation payload contains the empty email itself; there is no other identifying field to fall back to. - The payload has no `is_sso` / `external_id` flag, so the frontend cannot even differentiate SSO rows to apply a special UI. - A cosmetic "Unknown sender" fallback would only mask the symptom while leaving the accept-flow exception in BA-6193 untouched. So the fix has to land where the empty email originates — the backend. See [BA-6193](https://lablup.atlassian.net/browse/BA-6193). ## Verification - `bash scripts/verify.sh` — Relay, Lint, Format PASS. TypeScript surfaces only pre-existing failures in unrelated files; no new errors in the touched files. - Manual: invite a manually-created user from another manually-created user on a manager that exposes `inviter_user_email`; the Summary card and the invitation modal both show the inviter's email. On a manager that only returns `inviter` (current main), both fall back to the legacy field and render correctly. SSO-related rows remain blank, expected until BA-6193 lands. ## Checklist - [x] Documentation — n/a (capability-check pattern already documented by FR-1101's PR) - [x] Minimum required manager version — no change (the existing capability flag covers both old and new managers) - [x] Minimum requirements to check during review — log in as the invitee and confirm the Summary invitation card title and the `FolderInvitationResponseModal` "From:" field both show the inviter's email (or `-` if not available on the current manager) - [ ] Test case(s) — covered by the e2e in #7610 (FR-2982) [FR-2979]: https://lablup.atlassian.net/browse/FR-2979?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [BA-6193]: https://lablup.atlassian.net/browse/BA-6193?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [BA-6228]: https://lablup.atlassian.net/browse/BA-6228?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

agatha197 · 2026-06-07T16:00:47Z

@yomybaby both of your inline comments are addressed: DefaultProviders.tsx and LoginView.tsx were reverted to the parent-branch state (that i18n-provider work moved to FR-2925), so the PR diff now contains only the intended e2e files (e2e/utils/test-util.ts, e2e/vfolder/vfolder-crud.spec.ts, and the coverage report). Both threads are resolved. Re-requesting review to clear the stale changes-requested — thanks!

nowgnuesLee

LGTM

approved by others. and resolved comment.

graphite-app · 2026-06-09T02:38:41Z

Merge activity

Jun 9, 2:38 AM UTC: agatha197 added this pull request to the Graphite merge queue.
Jun 9, 2:40 AM UTC: Merged by the Graphite merge queue.

#7610) Resolves #7608 (FR-2982) > Stacked on #7607 — merge that one first. ## Summary - Extend `acceptAllInvitationAndVerifySpecificFolder` (in `e2e/utils/test-util.ts`) with an optional `inviterEmail` parameter. - When the parameter is provided, assert that the open `FolderInvitationResponseModal` contains that email before the Accept loop. This catches regressions in the modal's "From" field — i.e. broken `item.inviter_user_email` plumbing or a broken `invitation-inviter-email` capability check. - Pass `userInfo.user.email` (the inviter set up by `loginAsUser` in `beforeEach`) at the single existing call site in `e2e/vfolder/vfolder-crud.spec.ts` ("User can share vFolder"), so the assertion runs in CI. - No production source changes; e2e-only. ## Why - The "From" field is the only place an invitee sees who shared a folder with them. Today no e2e / unit / Storybook test asserts that field is non-empty or correct. - Existing test already exercises the modal, so the new check is a low-cost extension rather than a new scenario. ## Test plan - [ ] CI: existing `vfolder/vfolder-crud.spec.ts` "User can share vFolder" run passes with the new assertion enabled. - [ ] On a backend with `invitation-inviter-email` capability, the assertion confirms `user@lablup.com` is rendered inside the modal. - [ ] On a backend without that capability, the assertion would fail (the modal falls back to `item.inviter`, a non-email value); intentional — this is the regression we want to surface.

github-actions Bot assigned agatha197 May 27, 2026

github-actions Bot added the size:S 10~30 LoC label May 27, 2026

agatha197 marked this pull request as ready for review May 27, 2026 05:35

Copilot AI review requested due to automatic review settings May 27, 2026 05:35

Copilot started reviewing on behalf of agatha197 May 27, 2026 05:35 View session

Copilot AI reviewed May 27, 2026

View reviewed changes

github-actions Bot added size:L 100~500 LoC and removed size:S 10~30 LoC labels May 27, 2026

github-actions Bot added size:M 30~100 LoC and removed size:L 100~500 LoC labels May 27, 2026

agatha197 changed the base branch from main to graphite-base/7610 May 27, 2026 10:04

agatha197 force-pushed the e2e/FR-2982-assert-inviter-email-in-invitation-modal branch from c89cb25 to cbe1693 Compare May 27, 2026 10:04

agatha197 changed the base branch from graphite-base/7610 to fix/FR-2979-shared-folder-invite-sender May 27, 2026 10:04

agatha197 mentioned this pull request May 27, 2026

fix(FR-2979): display sender on shared folder invitations in summary page #7607

Merged

4 tasks

agatha197 requested review from nowgnuesLee and yomybaby May 28, 2026 02:32

agatha197 changed the base branch from fix/FR-2979-shared-folder-invite-sender to graphite-base/7610 May 28, 2026 02:54

agatha197 force-pushed the e2e/FR-2982-assert-inviter-email-in-invitation-modal branch from cbe1693 to 654d33d Compare May 28, 2026 02:54

agatha197 force-pushed the graphite-base/7610 branch from 147f8b1 to 25baf00 Compare May 28, 2026 02:54

agatha197 changed the base branch from graphite-base/7610 to fix/FR-2979-shared-folder-invite-sender May 28, 2026 02:54

agatha197 marked this pull request as draft May 28, 2026 05:52

agatha197 changed the base branch from fix/FR-2979-shared-folder-invite-sender to graphite-base/7610 May 28, 2026 05:54

agatha197 force-pushed the e2e/FR-2982-assert-inviter-email-in-invitation-modal branch from 654d33d to ee4142c Compare May 28, 2026 05:54

agatha197 force-pushed the graphite-base/7610 branch from 25baf00 to f849b3a Compare May 28, 2026 05:54

agatha197 changed the base branch from graphite-base/7610 to fix/FR-2979-shared-folder-invite-sender May 28, 2026 05:54

agatha197 marked this pull request as ready for review May 28, 2026 05:55

agatha197 changed the base branch from fix/FR-2979-shared-folder-invite-sender to graphite-base/7610 May 28, 2026 07:20

agatha197 force-pushed the e2e/FR-2982-assert-inviter-email-in-invitation-modal branch from ee4142c to 99d6077 Compare May 28, 2026 07:21

agatha197 force-pushed the graphite-base/7610 branch from f849b3a to 005aaf8 Compare May 28, 2026 07:21

agatha197 changed the base branch from graphite-base/7610 to fix/FR-2979-shared-folder-invite-sender May 28, 2026 07:21

agatha197 changed the base branch from fix/FR-2979-shared-folder-invite-sender to graphite-base/7610 May 28, 2026 23:01

agatha197 force-pushed the e2e/FR-2982-assert-inviter-email-in-invitation-modal branch from 99d6077 to 941b668 Compare May 28, 2026 23:17

agatha197 force-pushed the graphite-base/7610 branch from 005aaf8 to 868c4a8 Compare May 28, 2026 23:17

agatha197 changed the base branch from graphite-base/7610 to fix/FR-2979-shared-folder-invite-sender May 28, 2026 23:17

github-actions Bot added size:L 100~500 LoC and removed size:M 30~100 LoC labels May 28, 2026

yomybaby previously requested changes May 28, 2026

View reviewed changes

Comment thread react/src/components/DefaultProviders.tsx Outdated

Comment thread react/src/components/LoginView.tsx Outdated

github-actions Bot added size:M 30~100 LoC and removed size:L 100~500 LoC labels May 29, 2026

agatha197 requested a review from yomybaby May 29, 2026 00:18

graphite-app Bot changed the base branch from fix/FR-2979-shared-folder-invite-sender to graphite-base/7610 May 29, 2026 01:07

graphite-app Bot force-pushed the e2e/FR-2982-assert-inviter-email-in-invitation-modal branch from e2c9281 to 6995ec4 Compare May 29, 2026 01:10

graphite-app Bot force-pushed the graphite-base/7610 branch from 868c4a8 to 17c6056 Compare May 29, 2026 01:10

graphite-app Bot changed the base branch from graphite-base/7610 to main May 29, 2026 01:11

graphite-app Bot force-pushed the e2e/FR-2982-assert-inviter-email-in-invitation-modal branch from 6995ec4 to 3e33168 Compare May 29, 2026 01:11

nowgnuesLee approved these changes Jun 8, 2026

View reviewed changes

graphite-app Bot force-pushed the e2e/FR-2982-assert-inviter-email-in-invitation-modal branch from 3e33168 to 2931506 Compare June 9, 2026 02:39

graphite-app Bot merged commit 2931506 into main Jun 9, 2026
7 checks passed

graphite-app Bot deleted the e2e/FR-2982-assert-inviter-email-in-invitation-modal branch June 9, 2026 02:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

e2e(FR-2982): assert inviter email is shown in folder invitation modal#7610

e2e(FR-2982): assert inviter email is shown in folder invitation modal#7610
graphite-app[bot] merged 1 commit into
mainfrom
e2e/FR-2982-assert-inviter-email-in-invitation-modal

agatha197 commented May 27, 2026 •

edited

Loading

Uh oh!

agatha197 commented May 27, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

github-actions Bot commented May 27, 2026

Uh oh!

Uh oh!

Uh oh!

agatha197 commented Jun 7, 2026

Uh oh!

nowgnuesLee left a comment

Uh oh!

graphite-app Bot commented Jun 9, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

agatha197 commented May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

Test plan

Uh oh!

agatha197 commented May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

How to use the Graphite Merge Queue

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

github-actions Bot commented May 27, 2026

Coverage Report for react-coverage (./react)

Uh oh!

Uh oh!

Uh oh!

agatha197 commented Jun 7, 2026

Uh oh!

nowgnuesLee left a comment

Choose a reason for hiding this comment

Uh oh!

graphite-app Bot commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merge activity

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

agatha197 commented May 27, 2026 •

edited

Loading

agatha197 commented May 27, 2026 •

edited

Loading

graphite-app Bot commented Jun 9, 2026 •

edited

Loading