feat(core,dashboard): Add verifyCustomerAccount mutation to admin API

[latifniz]

Description

Adds a verifyCustomerAccount(id: ID!): Customer! mutation to the admin API,
allowing administrators to manually verify a customer account without requiring
an email verification token.

This fills a gap when authOptions.requireVerification: true (the default) but
the customer never received the verification email. for example when no email
plugin is configured in dev/staging, the email landed in spam, or during B2B
onboarding where the admin creates accounts on behalf of clients.

Changes:

• Adds verifyCustomerAccount(id: ID!): Customer! to the admin GraphQL schema
• Adds CustomerService.verifyCustomerAccount() which sets user.verified = true,
  clears the pending verification token, records a CUSTOMER_VERIFIED history
  entry and emits AccountVerifiedEvent
• Adds a "Verify account" button to the dashboard customer detail page, visible
  only when the customer status is "Registered" (not yet verified)
• Adds e2e tests covering verification, history entry, event emission and idempotency

Relates to #4756

Breaking changes

None.

---

^{Need help on this PR? Tag @codesmith with what you need. Autofix is disabled.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
vendure-storybook	Ready	Preview, Comment	May 22, 2026 9:12am

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: e018b482-77bb-469b-91fa-8050c8b5ed5c

📥 Commits

Reviewing files that changed from the base of the PR and between 929870c and d285c6f.

📒 Files selected for processing (11)

• packages/admin-ui/src/lib/core/src/common/generated-types.ts
• packages/common/src/generated-types.ts
• packages/core/e2e/customer.e2e-spec.ts
• packages/core/e2e/graphql/graphql-env-admin.d.ts
• packages/core/e2e/graphql/shared-definitions.ts
• packages/core/src/api/resolvers/admin/customer.resolver.ts
• packages/core/src/api/schema/admin-api/customer.api.graphql
• packages/core/src/service/services/customer.service.ts
• packages/dashboard/src/app/routes/_authenticated/_customers/customers.graphql.ts
• packages/dashboard/src/app/routes/_authenticated/_customers/customers_.$id.tsx
• schema-admin.json

---

📝 Walkthrough

Walkthrough

This PR implements a new verifyCustomerAccount mutation that enables administrators to manually mark customer accounts as verified without going through the standard email verification token flow. The feature includes a new GraphQL mutation field, a CustomerService method that updates the user verification status and publishes an AccountVerifiedEvent, a resolver endpoint with permission enforcement, comprehensive E2E tests, and dashboard UI integration with a contextual "Verify account" button on the customer detail page.

Suggested reviewers

• gabriellbui
• michaelbromley

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: adding a new verifyCustomerAccount mutation to the admin API across core and dashboard packages.
Description check	✅ Passed	The description is comprehensive, covering the motivation, specific changes, testing, and breaking changes status. It follows the template structure with clear sections for description and breaking changes.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Ryrahul]

I think this might already be covered by the existing admin customer creation flow in resolver/service layer. (password is missing in the dashboard ui)

`CustomerService.create() is documented as:

"This method is intended to be used in admin-created Customer flows."

and it already immediately verifies the customer when a password is provided by calling the existing verification flow internally.

So from my understanding, admins can already create a verified customer account through the existing API/service behavior, previous angular admin ui already had this behaviour so maybe adding password in the dashboard ui may be the appropriate way to go ahead ( i am not a maintainer so , you should probably wait for maintainer take on it ),

This fills a gap when authOptions.requireVerification: true (the default) but
the customer never received the verification email. for example when no email
plugin is configured in dev/staging, the email landed in spam, or during B2B
onboarding where the admin creates accounts on behalf of clients.

As for this , dev server has mailbox where you can check all the emails to verify , while for b2b cases it normally requires much more complex verification flow than this , or the above method told should be used