Prototype planning
Account Migration Plan
This page maps the current Demo Identity system to future real WordPress users and roles.
Planning only. This does not create users, change WordPress roles, send email, or change current prototype behavior.
Identity map
Current Demo Identities to Future Users
Today, the Acting As selector stores a prototype identity in browser localStorage with the key apgp_demo_identity. Later, this should come from the logged-in WordPress account.
| Current demo identity | Future WordPress user mapping | Migration note |
|---|---|---|
| Guest | Logged-out visitor or pre-account interested party | Guest demo activity stays browser-local today. Production should not automatically convert anonymous localStorage data into a real account without consent. |
| Rich demo identity | WordPress user account mapped to profile slug "rich" | Future profile records can store an owner user ID while keeping approved answers, images, reviews, and requests profile-specific. |
| Sara demo identity | WordPress user account mapped to profile slug "sara" | Future profile records can store an owner user ID while keeping approved answers, images, reviews, and requests profile-specific. |
| Maya demo identity | WordPress user account mapped to profile slug "maya" | Future profile records can store an owner user ID while keeping approved answers, images, reviews, and requests profile-specific. |
| Jenna demo identity | WordPress user account mapped to profile slug "jenna" | Future profile records can store an owner user ID while keeping approved answers, images, reviews, and requests profile-specific. |
| Nora demo identity | WordPress user account mapped to profile slug "nora" | Future profile records can store an owner user ID while keeping approved answers, images, reviews, and requests profile-specific. |
| Tom demo identity | WordPress user account mapped to profile slug "tom" | Future profile records can store an owner user ID while keeping approved answers, images, reviews, and requests profile-specific. |
| Angelina demo identity | WordPress user account mapped to profile slug "angelina" | Future profile records can store an owner user ID while keeping approved answers, images, reviews, and requests profile-specific. |
| Test Customer demo identity | WordPress user account mapped to profile slug "testcustomer" | Future profile records can store an owner user ID while keeping approved answers, images, reviews, and requests profile-specific. |
Role map
Future Account Roles
Profile Owner
Owns one or more profiles, approves public profile answers, receives connection requests, invites reviewers, and manages visibility.
Interested Party
Browses Discovery, asks profile guide questions, saves profiles, sends connection requests, and views request status.
Friend / Family Reviewer
Uses an invite token or account-based invite to rate Representation Accuracy and provide confidential feedback.
Admin / Moderator
Handles support, safety issues, policy problems, and review moderation if that feature is enabled.
Data migration
Prototype Data to Account Data
| Current prototype behavior | Future real account behavior |
|---|---|
| Demo Identity dropdown | Logged-in account and role checks. |
| First name and initials fields on connection requests | Interested party account display name, profile image, and verified sharing settings. |
| Browser-local saved profiles | Account saved-profile list tied to the interested party user. |
| Connection requests stored in WordPress options | Account-linked requests with sender user ID, target profile owner ID, status, and safety controls. |
| Reviewer invite link with invite ID | Reviewer invite token, optional reviewer account, and confidential review submission. |
| Manual owner dashboard access | Role-based dashboard access where owners can only manage profiles they own. |
Implementation sequence
Suggested Migration Steps
- Create WordPress users for profile owners and add an owner user ID to each profile record.
- Replace localStorage Demo Identity with the current logged-in WordPress user on protected pages.
- Keep the self-profile guardrail so owners cannot send connection requests to themselves.
- Move saved profiles, connection requests, and request statuses from demo identity fields to account-linked records.
- Convert reviewer invites into invite tokens that can optionally attach to a reviewer account after acceptance.
- Add capability checks for owner dashboards, reviewer pages, admin tools, moderation actions, and data export/restore.
- Audit privacy rules before launch so reviewer names, notes, contact details, and private profile fields are never exposed accidentally.
Launch guardrails
Safety Rules Before Real Accounts
No automatic guest migration
Do not silently attach anonymous browser activity to a real account. Ask the user before preserving or importing it.
No automatic contact sharing
Connection acceptance should not reveal phone numbers, emails, or private details without explicit consent.
Reviewer confidentiality
Reviewer names can support invite tracking, but scores and notes stay confidential by default unless the reviewer opts in.
Owner access limits
Profile owners should only manage their own profiles, connection requests, reviewer invites, and approved profile data.