Monlam account application backend (PocketBase 0.40.6) Collections monlam_accounts: applicant authentication, email verification, name. monlam_staff: reviewer authentication; created only by a superuser. monlam_applications: one application per applicant, contact and monastery details, consent, authorization declaration, verification and review state. monlam_monasteries: official monastery directory; superusers maintain it. registration_id is optional and never allocated by this workflow. monlam_memberships: approved application MonId/name, optional legacy directory link, active flag. monlam_audit: server-written submission, confirmation and review history. Applicants can read only their own account, application and memberships. The monastery directory is staff-only, including its list and view APIs. Applicants supply their monastery details directly. Neither applicant nor staff needs a directory match for approval. Supplied monastery relation IDs are ignored. Staff can read applications and audit history. Direct application, membership, audit, and staff-account writes are locked to superusers. Do not place a superuser token/password in frontend code. Applicant verification is provided by PocketBase's built-in email verification, not an applicant-editable flag. Account deletion endpoint: POST /api/monlam/account/delete [authenticated applicant only] password: current password; confirmation: exact text DELETE. Permanently deletes the authenticated account, its applications, memberships and application audit records in one transaction. Staff and other applicant records/directory entries are not deleted. Supplied target IDs are ignored. Direct collection delete rules remain locked. The portal clears the current account's local session/drafts after success; downloaded files and backups are unaffected. Existing tokens cease authenticating after record deletion. Built-in endpoints under /api/collections/monlam_accounts: POST /records signup: email,password,passwordConfirm,name POST /auth-with-password identity,password POST /request-verification email (SMTP must be configured first) POST /confirm-verification token from the verification email POST /request-password-reset email POST /confirm-password-reset token,password,passwordConfirm Custom endpoints (send Authorization: ) PUT /api/monlam/application [applicant] representative_name, role, whatsapp (international +digits), monastery_name, address, country, MonId (optional text; blank becomes New), authorized_declaration (boolean), whatsapp_consent (boolean). Creates or replaces the applicant's draft. All text fields except monastery are required. Editable only in draft or needs_information state. Editing resets WhatsApp verification. Never accepts status/owner/reviewer fields. POST /api/monlam/application/submit [applicant] Empty object body. Requires verified email and both declarations. Returns pending application with random ML- code expiring in 48 hours. Repeated calls return the current code; an expired code is replaced. After confirmation, repeated submit does not issue another code. Applicant sends the code manually to Monlam's WhatsApp number. POST /api/monlam/applications/{id}/confirm-whatsapp [staff or superuser] code, sender_phone (exact international format stored on application). Staff must personally check that the message arrived from this number. Requires pending state and valid code; consumes code and records actor/time. POST /api/monlam/applications/{id}/review [staff or superuser] decision: approved | rejected | needs_information note: required explanation, up to 2000 characters, visible to applicant. No monastery relation parameter is required or used. Staff confirm authority to represent the applied MonId/New and monastery full name shown on screen. Approval requires email and WhatsApp verification. Creates membership and audit record in the same database transaction as the status change. needs_information lets the applicant edit and resubmit. Rejected and approved applications are closed to applicant edits. Local staff operation today POST /api/monlam/applications/{id}/unapprove [staff or superuser] note: required reason, up to 2000 characters, visible to applicant. Only approved applications may be unapproved. Sets status back to pending, deactivates related memberships, and records an unapproved audit event in one transaction. Data/contact verification/drafts are kept. Reapproval reactivates the existing membership. Applicants cannot call this endpoint. Use http://127.0.0.1:8090/_/ with your private superuser login to inspect collections and create official monastery/staff records. The PocketBase dashboard is a superuser tool; monlam_staff accounts use the API and future staff frontend. Superusers bypass all API rules; use the custom endpoints for confirmation/approval so checks, memberships, and audit execute. Testing node --test pocketbase-local/test/backend.test.cjs Starts a separate PocketBase on 127.0.0.1:18090 with random credentials and a temporary database; never accesses the development database. The test verifies email by isolated test-superuser API rather than sending email. It covers cross-account access, privilege escalation, code expiry/renewal, single use, phone matching, prerequisites, membership and correction flow. Portal integration See PORTAL.txt for applicant/staff URLs and private Gmail configuration. RegForm/monlam-account.html and monlam-staff.html use the API with separate applicant/staff sessions. start.ps1 serves RegForm as the public directory. POST /api/monlam/monasteries lets staff create official directory records with name,address,country and optional registration_id. Applicant access to this route is denied. Direct collection-write rules stay locked. The second migration updates only Monlam's verification/reset email templates to link back to the portal; SMTP settings are not changed. The third migration restricts the monastery directory to staff. The fourth adds the applicant-provided MonId reference, defaulting existing blank references to New. Staff review the applicant-provided reference. Leading zeros are retained. The public directory remains inaccessible. The fifth migration makes membership directory links optional and adds MonId/name snapshots, backfilled from existing applications. Approval uses these details directly without querying or creating directory records. Applicant field drafts are kept locally per backend/account. Applicant login persists on the device; staff sessions remain in sessionStorage. Passwords are never cached. Only explicit Save application writes application details to Monlam. Scope and remaining integration No changes to registration HTML, participant data, historical exports, or unrelated collections/global settings. SMTP credentials must still be entered privately; no actual Gmail delivery has been verified. WhatsApp is manual; the configured Monlam recipient is +91 6362309873. No automated notifications are sent on staff decisions; applicants refresh their status in the portal. One application/monastery per applicant is supported initially. Multiple representatives can be approved for the same monastery. Active memberships are the future participant-access gate; participant storage and its permissions are not part of this migration. Before exposing publicly: configure/test SMTP, HTTPS, request rate limits and backups. Keep development and production data/credentials separate. All custom routes are /api/monlam/...; no unrelated settings are changed. Migrations intentionally have no destructive down migration. Back up first.