feat(identity): split organization and user registration#186
Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (20)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (8)
📝 WalkthroughWalkthroughThis PR splits organization contact verification from user registration by introducing organization-scoped registration tokens, bifurcating the email-verification endpoint to route to either user provisioning or user registration with a setup token, and attaching first users to organizations via token consumption during registration. ChangesRegistration Split: Organization Contact Verification and First User Setup
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
docs/use-cases/platform-foundation/register-org/README.md (1)
175-175:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAlign sequence text with the new canonical screen order.
Line 175 still says “Continue to register-user setup link when ready,” but this now contradicts Line 106–107 and Line 129–130, which define
register-userbeforeworkspace-provisioning. Update this line so the sequence diagram matches the reordered flow.As per coding guidelines, “don’t leave stale ‘planned/will be wired’ statements; use PROGRESS for status and use-case files for spec-aligned implementation notes.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/use-cases/platform-foundation/register-org/README.md` at line 175, Update the sequence line that currently reads "Web-->>Rep: Continue to register-user setup link when ready" so it matches the canonical screen order where register-user appears before workspace-provisioning: change the message to reference workspace-provisioning instead of register-user (e.g., "Web-->>Rep: Continue to workspace-provisioning setup link when ready") and remove any "will be wired" style wording—if you need a status note use PROGRESS or move implementation notes into the use-case spec file; update the sequence entry that mentions register-user / workspace-provisioning accordingly.tests/Modules/Identity/Axis.Identity.Application.Tests/Commands/RegisterOrganizationHandlerTests.cs (1)
107-121:⚠️ Potential issue | 🟠 Major | ⚡ Quick winThe “without creating anything” test under-asserts side effects.
Line 107’s claim is broader than what’s verified. The test currently checks only
_orgRepoand_emailSender; it can still pass if roles/tokens are created or writes are committed.Suggested assertion coverage
result.IsFailure.Should().BeTrue(); await _orgRepo.DidNotReceive().AddAsync(Arg.Any<Organization>(), Arg.Any<CancellationToken>()); + await _roleRepo.DidNotReceive().AddAsync(Arg.Any<Role>(), Arg.Any<CancellationToken>()); + await _organizationTokenStore.DidNotReceive().CreateVerificationAsync( + Arg.Any<Guid>(), Arg.Any<string>(), Arg.Any<DateTime>(), Arg.Any<CancellationToken>()); + await _uow.DidNotReceive().SaveChangesAsync(Arg.Any<CancellationToken>()); await _emailSender.DidNotReceive().SendVerificationEmailAsync( Arg.Any<string>(), Arg.Any<string>(), Arg.Any<CancellationToken>());As per coding guidelines, “the assertions must prove what the test name claims.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/Modules/Identity/Axis.Identity.Application.Tests/Commands/RegisterOrganizationHandlerTests.cs` around lines 107 - 121, The test RegisterOrganization_WhenEmailIsInvalid_ReturnsFailureWithoutCreatingAnything currently only asserts _orgRepo and _emailSender; expand it to prove no other side effects occur by also asserting that role and token repositories were not called and no commit happened—e.g., add DidNotReceive checks for _roleRepo.AddAsync(Arg.Any<Role>(), Arg.Any<CancellationToken>()), _tokenRepo.AddAsync(Arg.Any<Token>(), Arg.Any<CancellationToken>()), and _unitOfWork.CommitAsync(Arg.Any<CancellationToken>()) (or the actual unit-of-work commit method used in the code) so the test name is fully satisfied.src/Modules/Identity/Axis.Identity.Application/Commands/RegisterOrganization/RegisterOrganizationHandler.cs (1)
111-125:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftMake organization creation and verification-token issuance atomic.
SaveChangesAsynccommits the new organization and roles beforeCreateVerificationAsync,SendVerificationEmailAsync, andMarkCompletedAsync. If any of those later steps fail, you can leave behind a persisted pending organization with no guaranteed verification path, and the catch then marks the idempotency key failed so a retry can create a second pending org. Keep org + verification token in one transaction, then hand email delivery off after commit (for example via an outbox).Also applies to: 129-133
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/Modules/Identity/Axis.Identity.Application/Commands/RegisterOrganization/RegisterOrganizationHandler.cs` around lines 111 - 125, The current flow calls uow.SaveChangesAsync before issuing the verification token and emailing, which can leave a persisted organization without a token if subsequent steps fail; change RegisterOrganizationHandler to create the verification token (OpaqueTokenGenerator.Create) and call organizationTokenStore.CreateVerificationAsync within the same unit-of-work/transaction (uow) so org + token are saved atomically, then commit via uow.SaveChangesAsync; after successful commit, dispatch emailSender.SendVerificationEmailAsync (or enqueue an outbox entry to send the email) and only then call MarkIdempotencyCompletedIfNeededAsync; ensure any exceptions before commit roll back without marking idempotency completed.src/Modules/Identity/Axis.Identity.Infrastructure/Services/OrganizationIdentityPurger.cs (1)
12-40:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftMove external logo deletion after a successful DB transaction.
DeleteLogoAsyncruns before the database purge completes. If any subsequent delete fails, storage and DB state drift (logo removed, org still present/partially present).Suggested transaction/order shape
public async Task PurgeAsync(Guid organizationId, string? logoUrl, CancellationToken cancellationToken) { - if (!string.IsNullOrEmpty(logoUrl)) - { - try - { - await logoStorage.DeleteLogoAsync(logoUrl, cancellationToken); - } - catch (Exception) - { - // Best-effort file cleanup during hard delete. - } - } + await using IDbContextTransaction tx = await context.Database.BeginTransactionAsync(cancellationToken); IQueryable<Guid> userIds = context.OrganizationMemberships .Where(m => m.OrganizationId == organizationId) .Select(m => m.UserId); @@ await context.Organizations .Where(o => o.Id == organizationId) .ExecuteDeleteAsync(cancellationToken); + + await tx.CommitAsync(cancellationToken); + + if (!string.IsNullOrEmpty(logoUrl)) + { + try + { + await logoStorage.DeleteLogoAsync(logoUrl, cancellationToken); + } + catch (Exception) + { + // Best-effort post-commit cleanup. + } + } }As per coding guidelines, “Side effects (external storage, messaging) must not commit before the DB transaction they depend on — flag ordering that can leave drift.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/Modules/Identity/Axis.Identity.Infrastructure/Services/OrganizationIdentityPurger.cs` around lines 12 - 40, PurgeAsync currently calls logoStorage.DeleteLogoAsync before performing DB deletes, which can cause storage/DB drift; change the flow so all DB deletions (the queries using context.OrganizationMemberships, context.EmailVerificationTokens.ExecuteDeleteAsync, context.OrganizationRegistrationTokens.ExecuteDeleteAsync, context.PasswordResetTokens.ExecuteDeleteAsync) are executed inside a single database transaction and, only after that transaction completes successfully, call logoStorage.DeleteLogoAsync; keep the existing best-effort catch around DeleteLogoAsync but move it to after the committed transaction so external side effects occur only on successful DB commit.
🧹 Nitpick comments (1)
tests/Modules/Identity/Axis.Identity.Application.Tests/Commands/RegisterUserHandlerTests.cs (1)
85-111: ⚡ Quick winKeep organization IDs consistent in the setup-token fixture.
Line 85 defines
organizationId, but Lines 88-92 create anOrganizationwith a differentorganization.Id. This impossible state makes the test brittle and implementation-coupled.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/Modules/Identity/Axis.Identity.Application.Tests/Commands/RegisterUserHandlerTests.cs` around lines 85 - 111, The test creates a separate organizationId Guid but then constructs an Organization whose Id doesn't match that Guid, causing impossible state; fix by making the Organization and the organizationId consistent—either pass the pre-generated organizationId into Organization.Create (or use an overload/ctor that accepts an id) so the created Organization.Id equals organizationId, or remove the standalone organizationId and set organizationId = organization.Id after Organization.Create; update uses in the test (_organizationTokenStore.ConsumeFirstUserSetupAsync, _organizationRepo.GetByIdAsync, Role.CreateSystem) to reference the single consistent organizationId/Organization instance.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@openapi.json`:
- Around line 7523-7525: Operation summaries for the affected endpoints are out
of date: update the OpenAPI operation.summary and relevant descriptions for
/api/users/register and /api/auth/verify-email (and duplicate entries in the
block around 8037-8062) to reflect the new setup-token branch—specifically note
that registration is not "standalone-only" anymore and email verification no
longer always establishes a session; edit the operation objects for the paths
"/api/users/register" and "/api/auth/verify-email" (and their corresponding
operationId entries) to clearly state the new behaviors so the generated docs,
frontend types, and tests remain consistent.
In `@src/Axis.Api/Endpoints/AuthEndpoints.cs`:
- Around line 141-152: The endpoint currently computes business logic (deriving
nextStep using VerifyEmailNextStep and
result.Value.OrganizationSetupToken/OrganizationId) before returning
VerifyEmailSessionEstablishedDto; move this logic into the application layer by
having the handler (the mediator response) include a precomputed NextStep
property or by adding a factory on VerifyEmailSessionEstablishedDto that accepts
the handler result and computes NextStep there, then update the endpoint to only
call mediator.Send and map the response to Results.Ok without conditional logic
(remove references to nextStep computation from the endpoint).
In
`@src/Modules/Identity/Axis.Identity.Application/Commands/RegisterUser/RegisterUserHandler.cs`:
- Around line 65-72: The handler currently returns early on setup-token failures
(inside the setupToken is not null block) and skips idempotency cleanup, leaving
the idempotency key acquired; update RegisterUserHandler so that before
returning any failure from AttachFirstUserToOrganizationAsync (or other
setup-token business failures) you call a helper like
MarkIdempotencyFailedIfNeededAsync to release the idempotency record; implement
MarkIdempotencyFailedIfNeededAsync to call
idempotencyRepo.MarkFailedAsync(idempotencyKey, cancellationToken) when
idempotencyKey is not null and acquire result ==
RegistrationIdempotencyAcquireResult.Acquired, otherwise return completed task,
and invoke this helper in the failure path right before each early return (e.g.,
after AttachFirstUserToOrganizationAsync returns IsFailure).
In
`@src/Modules/Identity/Axis.Identity.Application/Commands/VerifyEmail/VerifyEmailHandler.cs`:
- Around line 88-93: The verification flow in VerifyEmailHandler currently calls
uow.SaveChangesAsync to persist the organization status and provisioning rows
before calling CreateFirstUserSetupAsync, which can leave the tenant stranded if
token creation fails; change the sequence so that CreateFirstUserSetupAsync is
invoked and its resulting setup-token is created/validated before committing
changes, or wrap both the setup-token creation and the org status/provisioning
updates in a single transactional unit (e.g., the existing unit-of-work
transaction scope) so that either all of: (a) setup token creation, (b)
organization.Status transition from PendingVerification, and (c) provisioning
rows are committed together; update code paths around VerifyEmailHandler
(including the pre-check for organization.Status and the later
uow.SaveChangesAsync calls) to use the single transaction and only return
success after the transaction completes.
In
`@src/Modules/Identity/Axis.Identity.Application/Services/OrganizationRegistrationTokenResults.cs`:
- Around line 3-25: Replace the bespoke records/enums with the shared
Result/Result<T> pattern: remove OrganizationVerificationTokenResolveResult and
OrganizationVerificationTokenState and have the verification flow return
Result<Guid> (successful Result contains the OrganizationId); similarly remove
OrganizationSetupTokenConsumeResult and OrganizationSetupTokenState and return
Result<Guid> for setup consumption. Map the previous enum cases (NotFound,
Expired, AlreadyUsed) to domain failure Results (use appropriate failure
reasons/messages from your shared failure contract) so callers receive Result
failures instead of custom enums; update all methods referencing
OrganizationVerificationTokenResolveResult and
OrganizationSetupTokenConsumeResult to use Result/Result<Guid> accordingly.
In `@src/Modules/Identity/Axis.Identity.Domain/Aggregates/Organization.cs`:
- Around line 166-177: The method BeginProvisioningAfterContactVerification
currently raises OrganizationVerified even when no status change occurs; update
BeginProvisioningAfterContactVerification so OrganizationVerified is only raised
when the organization actually transitions to OrganizationStatus.Provisioning
(i.e., if Status == OrganizationStatus.PendingVerification set Provisioning and
raise, otherwise call BeginProvisioning only when Status !=
OrganizationStatus.Provisioning and raise OrganizationVerified after that
successful transition); reference BeginProvisioningAfterContactVerification,
BeginProvisioning, Status, OrganizationStatus.Provisioning and the
OrganizationVerified domain event to locate and implement the conditional check
that prevents emitting the event when no status change happened.
In
`@src/Modules/Identity/Axis.Identity.Infrastructure/Services/OrganizationRegistrationTokenStore.cs`:
- Around line 148-166: The CreateAsync helper in
OrganizationRegistrationTokenStore is performing a premature commit by calling
context.SaveChangesAsync; remove the SaveChangesAsync call so CreateAsync only
constructs and AddAsync the OrganizationRegistrationToken (use the existing
context.Set<OrganizationRegistrationToken>().AddAsync(token, ct)) and let the
caller control transaction/SaveChanges; if the caller needs the new entity id or
object, return the created OrganizationRegistrationToken (or its Id) from
CreateAsync so callers can persist in their transaction boundary.
In `@tests/Api/Axis.Api.Tests/Identity/OrganizationEndpointTests.cs`:
- Around line 49-50: Replace the legacy admin-email assertions with checks
against the actual contact-email side effect: update the two ctx.Users.Count
checks that use Email.Create("adminidem1a@test.com") and
Email.Create("adminidem1b@test.com") to assert against the
organizationContactEmail value produced by the test flow (use the
organizationContactEmail variable/property passed or created in the test and
Email.Create(...) on it) so the test verifies users are/are-not created for the
contact email rather than the old admin emails.
---
Outside diff comments:
In `@docs/use-cases/platform-foundation/register-org/README.md`:
- Line 175: Update the sequence line that currently reads "Web-->>Rep: Continue
to register-user setup link when ready" so it matches the canonical screen order
where register-user appears before workspace-provisioning: change the message to
reference workspace-provisioning instead of register-user (e.g., "Web-->>Rep:
Continue to workspace-provisioning setup link when ready") and remove any "will
be wired" style wording—if you need a status note use PROGRESS or move
implementation notes into the use-case spec file; update the sequence entry that
mentions register-user / workspace-provisioning accordingly.
In
`@src/Modules/Identity/Axis.Identity.Application/Commands/RegisterOrganization/RegisterOrganizationHandler.cs`:
- Around line 111-125: The current flow calls uow.SaveChangesAsync before
issuing the verification token and emailing, which can leave a persisted
organization without a token if subsequent steps fail; change
RegisterOrganizationHandler to create the verification token
(OpaqueTokenGenerator.Create) and call
organizationTokenStore.CreateVerificationAsync within the same
unit-of-work/transaction (uow) so org + token are saved atomically, then commit
via uow.SaveChangesAsync; after successful commit, dispatch
emailSender.SendVerificationEmailAsync (or enqueue an outbox entry to send the
email) and only then call MarkIdempotencyCompletedIfNeededAsync; ensure any
exceptions before commit roll back without marking idempotency completed.
In
`@src/Modules/Identity/Axis.Identity.Infrastructure/Services/OrganizationIdentityPurger.cs`:
- Around line 12-40: PurgeAsync currently calls logoStorage.DeleteLogoAsync
before performing DB deletes, which can cause storage/DB drift; change the flow
so all DB deletions (the queries using context.OrganizationMemberships,
context.EmailVerificationTokens.ExecuteDeleteAsync,
context.OrganizationRegistrationTokens.ExecuteDeleteAsync,
context.PasswordResetTokens.ExecuteDeleteAsync) are executed inside a single
database transaction and, only after that transaction completes successfully,
call logoStorage.DeleteLogoAsync; keep the existing best-effort catch around
DeleteLogoAsync but move it to after the committed transaction so external side
effects occur only on successful DB commit.
In
`@tests/Modules/Identity/Axis.Identity.Application.Tests/Commands/RegisterOrganizationHandlerTests.cs`:
- Around line 107-121: The test
RegisterOrganization_WhenEmailIsInvalid_ReturnsFailureWithoutCreatingAnything
currently only asserts _orgRepo and _emailSender; expand it to prove no other
side effects occur by also asserting that role and token repositories were not
called and no commit happened—e.g., add DidNotReceive checks for
_roleRepo.AddAsync(Arg.Any<Role>(), Arg.Any<CancellationToken>()),
_tokenRepo.AddAsync(Arg.Any<Token>(), Arg.Any<CancellationToken>()), and
_unitOfWork.CommitAsync(Arg.Any<CancellationToken>()) (or the actual
unit-of-work commit method used in the code) so the test name is fully
satisfied.
---
Nitpick comments:
In
`@tests/Modules/Identity/Axis.Identity.Application.Tests/Commands/RegisterUserHandlerTests.cs`:
- Around line 85-111: The test creates a separate organizationId Guid but then
constructs an Organization whose Id doesn't match that Guid, causing impossible
state; fix by making the Organization and the organizationId consistent—either
pass the pre-generated organizationId into Organization.Create (or use an
overload/ctor that accepts an id) so the created Organization.Id equals
organizationId, or remove the standalone organizationId and set organizationId =
organization.Id after Organization.Create; update uses in the test
(_organizationTokenStore.ConsumeFirstUserSetupAsync,
_organizationRepo.GetByIdAsync, Role.CreateSystem) to reference the single
consistent organizationId/Organization instance.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: a3eb8efc-2a3a-4111-bdd2-43d84e5c59e3
📒 Files selected for processing (51)
docs/PROGRESS.mddocs/use-cases/identity-access/README.mddocs/use-cases/identity-access/register-user/README.mddocs/use-cases/platform-foundation/README.mddocs/use-cases/platform-foundation/register-org/README.mdfrontend/src/features/auth/hooks/useRegister.tsfrontend/src/features/auth/hooks/useVerifyEmail.tsfrontend/src/lib/api-types.tsfrontend/tests/register-page.test.tsxfrontend/tests/verify-email-page.test.tsxopenapi.jsonsrc/Axis.Api/Endpoints/AuthEndpoints.cssrc/Axis.Api/Endpoints/OrganizationEndpoints.cssrc/Axis.Api/Endpoints/RegisterOrganizationRequest.cssrc/Axis.Api/Endpoints/RegisterUserRequest.cssrc/Axis.Api/Endpoints/UserEndpoints.cssrc/Modules/Identity/Axis.Identity.Application/Commands/RegisterOrganization/RegisterOrganizationCommand.cssrc/Modules/Identity/Axis.Identity.Application/Commands/RegisterOrganization/RegisterOrganizationCommandValidator.cssrc/Modules/Identity/Axis.Identity.Application/Commands/RegisterOrganization/RegisterOrganizationHandler.cssrc/Modules/Identity/Axis.Identity.Application/Commands/RegisterUser/RegisterUserCommand.cssrc/Modules/Identity/Axis.Identity.Application/Commands/RegisterUser/RegisterUserCommandValidator.cssrc/Modules/Identity/Axis.Identity.Application/Commands/RegisterUser/RegisterUserHandler.cssrc/Modules/Identity/Axis.Identity.Application/Commands/RetryTenantProvisioning/RetryTenantProvisioningHandler.cssrc/Modules/Identity/Axis.Identity.Application/Commands/VerifyEmail/VerifyEmailHandler.cssrc/Modules/Identity/Axis.Identity.Application/Commands/VerifyEmail/VerifyEmailSessionEstablishedDto.cssrc/Modules/Identity/Axis.Identity.Application/Commands/VerifyEmail/VerifyEmailSuccessDto.cssrc/Modules/Identity/Axis.Identity.Application/Queries/GetProvisioningStatus/GetProvisioningStatusHandler.cssrc/Modules/Identity/Axis.Identity.Application/Services/IOrganizationRegistrationTokenStore.cssrc/Modules/Identity/Axis.Identity.Application/Services/OrganizationRegistrationTokenResults.cssrc/Modules/Identity/Axis.Identity.Domain/Aggregates/Organization.cssrc/Modules/Identity/Axis.Identity.Domain/Aggregates/OrganizationStatus.cssrc/Modules/Identity/Axis.Identity.Infrastructure/Extensions/IdentityInfrastructureExtensions.cssrc/Modules/Identity/Axis.Identity.Infrastructure/Migrations/20260605075025_RegistrationSplit.Designer.cssrc/Modules/Identity/Axis.Identity.Infrastructure/Migrations/20260605075025_RegistrationSplit.cssrc/Modules/Identity/Axis.Identity.Infrastructure/Migrations/IdentityDbContextModelSnapshot.cssrc/Modules/Identity/Axis.Identity.Infrastructure/Persistence/Configurations/OrganizationConfiguration.cssrc/Modules/Identity/Axis.Identity.Infrastructure/Persistence/Configurations/OrganizationRegistrationTokenConfiguration.cssrc/Modules/Identity/Axis.Identity.Infrastructure/Persistence/Entities/OrganizationRegistrationToken.cssrc/Modules/Identity/Axis.Identity.Infrastructure/Persistence/IdentityDbContext.cssrc/Modules/Identity/Axis.Identity.Infrastructure/Services/OrganizationIdentityPurger.cssrc/Modules/Identity/Axis.Identity.Infrastructure/Services/OrganizationRegistrationTokenStore.cstests/Api/Axis.Api.Tests/Helpers/AuthHelper.cstests/Api/Axis.Api.Tests/Helpers/TestRegistrationPayload.cstests/Api/Axis.Api.Tests/Identity/AuthEndpointTests.cstests/Api/Axis.Api.Tests/Identity/OrganizationEndpointTests.cstests/Modules/Identity/Axis.Identity.Application.Tests/Commands/RegisterOrganizationHandlerTests.cstests/Modules/Identity/Axis.Identity.Application.Tests/Commands/RegisterUserHandlerTests.cstests/Modules/Identity/Axis.Identity.Application.Tests/Commands/RetryTenantProvisioningHandlerTests.cstests/Modules/Identity/Axis.Identity.Application.Tests/Commands/VerifyEmailHandlerTests.cstests/Modules/Identity/Axis.Identity.Application.Tests/Queries/GetProvisioningStatusHandlerTests.cstests/Modules/Identity/Axis.Identity.Domain.Tests/Aggregates/OrganizationTests.cs
8 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements the split between organization onboarding and user identity registration.
POST /api/organizationsnow captures organization/contact/legal facts, sends organization-contact verification, starts tenant provisioning after verification, and returns a first-user setup token.POST /api/users/registercan consume that setup token to attach the first admin user while standalone user registration remains supported.Linked spec
docs/use-cases/platform-foundation/register-org/README.mddocs/use-cases/identity-access/register-user/README.mdRequirements & rules followed
python scripts/axis.py verifypassed; additional Identity Infrastructure and API Testcontainers suites passed with the WSL Docker TCP endpoint.TODO/FIXME/NotImplementedException/ placeholder / stub undersrc/,tests/,frontend/src/.Summary by CodeRabbit
Release Notes
New Features
Documentation