# Activate Digitrika’s live invitation manager

Project: **digitrika-4fbb1**. Existing database ID: **default** (without parentheses). Its public web configuration is already installed in `assets/firebase-config.js`.

The existing access rules match `firestore.rules`, billing is disabled, and studio-owner access is enabled for the verified `digitrika@gmail.com` account. That owner can sign in after the corrected website files are uploaded. The one-time account setup below is only needed for a new owner account.

The website code is prepared for Firebase **Spark** using Email/Password Authentication, Anonymous Authentication and Cloud Firestore. It does not use Cloud Storage, Cloud Functions, SMS login or Analytics. Keep the Spark plan; no billing account is required for this implementation. Photos and videos continue to load from your existing website files.

## 1. Enable sign-in

Open [Firebase Authentication](https://console.firebase.google.com/project/digitrika-4fbb1/authentication/providers).

1. Choose **Get started** if prompted.
2. Under **Sign-in method**, enable **Email/Password**. Email-link sign-in is not needed.
3. Enable **Anonymous** as well. Guests use this automatically when sending an RSVP; they do not have to create an account.
4. In Authentication → Settings → Authorized domains, add your actual website domains, such as `digitrika.com` and `www.digitrika.com`. Add `localhost` and `127.0.0.1` if you will test locally. Do not enter the protocol or port.

## 2. Select the existing database and publish the access rules

Open [Cloud Firestore](https://console.firebase.google.com/project/digitrika-4fbb1/firestore).

1. Select the existing database named **`default`** in the database selector. Its ID has no parentheses.
2. Open the **Rules** tab. Replace its contents with the entire `firestore.rules` file from this project and press **Publish**.
3. The website reads `DigitrikaFirebaseDatabaseId` from `assets/firebase-config.js`; it is set to `default`. Firebase’s implicit `(default)` ID refers to a different database and does not exist in this project.
4. The existing database does not need recreating.

Do not replace the rules with public read/write access. Customer records, guest lists, replies and wishes must remain private.

If you already use the Firebase CLI, the equivalent rules-only command is:

```sh
firebase deploy --only firestore:rules,firestore:indexes --project digitrika-4fbb1
```

That command does not publish the website. It requires you to sign in to your Firebase account first. It does not enable billing.

## 3. Publish the prepared website files

Upload the complete `digitrika-cloudflare-ready.zip` to your existing Cloudflare Pages project as a new production deployment. It includes the website assets, `manage/`, `invite/`, `account/action/` and the root `_redirects` file. The `_redirects` rule serves `/invite/*` through the invitation page while retaining the readable address. Keep it in the deployment root. No separate website rebuild or paid backend is required. The pages must be served over HTTPS, or a local HTTP server during development; do not open them with `file://`.

Do not upload `node_modules/`, `.firebase-test-runtime/` or emulator log files. Those are local verification tools, not website assets.

The prepared Cloudflare ZIP excludes those development tools, credentials and local database rules. The updated Firestore rules are deployed separately to the existing `default` database.

Your private dashboard will be at **`https://digitrika.com/manage/`** if that is your website domain. Existing sample invitations and the public sample RSVP dashboard remain demonstrations. Real customer links use the new **`invite/`** page.

Customer share links are configured to use `https://digitrika.com/`, even when the owner opens the manager locally. If your public domain or website subfolder changes, update `DigitrikaPublicSite` in `assets/firebase-config.js`. Local previews stay local. Publish the `invite/` page before sending any customer links.

## 4. Give yourself studio access — one time only

1. Open your website’s `manage/` page.
2. Enter your own email and a strong password, then choose **Create account & verify email**.
3. Verify your email using the link Firebase sends, then sign in again.
4. Expand **Firebase setup and account access** and copy **Your account ID**. This is also shown in Firebase Authentication → Users.
5. In Cloud Firestore → Data, create a collection named **`operators`**.
6. Create a document whose document ID is your exact Firebase account ID. Add one field: **`enabled`**, type **boolean**, value **`true`**.
7. Refresh your dashboard. You should now see **Studio access**, **+ New**, and the invitation editor.

Only the Firebase project owner can grant this role through the console. Registering an account on the website does not grant studio access. Do not put passwords, service-account keys or admin credentials in website files.

## 5. Create an invitation

1. Choose **+ New**, then choose one of the eleven existing designs.
   The **Invitation address** is suggested from the names. You can choose your own address before saving, for example `aswin-radhika`, giving `https://digitrika.com/invite/aswin-radhika`. Saving reserves it atomically; another couple cannot use the same address. A saved address stays fixed when you edit names. Choosing a new address preserves old addresses as aliases to the same invitation.
2. Enter the names, couple’s dashboard email, plan and event details. The **first event supplies the opening date and time**. Up to three events can be entered.
   Event names, venues, addresses, dates and times also update their repeated references throughout the invitation, including secondary schedules, location headings, countdown captions, footers, directions, calendar shortcuts and RSVP event choices. The first event supplies shared venue summaries; each event keeps its own directions. Removing an event removes its secondary details and RSVP choice. Your own invitation wording and story remain as written.
3. Add the wording, story, dress code and guest information. Contact information and order notes are excluded from the public invitation document.
4. The suggested hosting end date follows the selected plan: seven days after the celebration for Essentials, one calendar month for Signature, twelve calendar months for Luxe. You can set a different agreed date. The displayed hosting cut-off is 23:59 UTC on that date.
5. Use **Preview** to check the actual theme. Replies are disabled in previews.
6. Choose **Publish invitation**, then copy or open the invitation link. Saving changes to an already published invitation updates its public version as well.
7. Share that customer link, not a sample theme URL or Design Studio preview URL.

## 6. Couple access and guest links

Send the couple the `manage/` address yourself. They create an account with the **exact dashboard email you assigned**, verify it, and sign in. They can view only invitations assigned to their verified email. They cannot edit or publish other customers’ invitations.

### If a verification email does not arrive

Saving a couple’s email in an invitation does not send email. The couple requests verification when they choose **Create account & verify email**, or **Send verification email** after signing in to their existing account. Do not create a second account for the same email.

The dashboard distinguishes a created account from an accepted email request. If Firebase rejects sending, the verification panel retains the actual error code even if the account check finishes later. A short resend pause helps prevent repeated requests; a throttling error has a longer pause. Email verification remains available even if the invitation database cannot be reached.

With the current default Firebase sender, check Inbox, Spam and All Mail for `noreply@digitrika-4fbb1.firebaseapp.com`. An accepted request confirms only that Firebase accepted the request, not delivery to the recipient’s inbox. Open the newest verification link, then choose **I’ve verified my email**. If sending still fails, copy the exact error displayed for diagnosis. Verification is required for access to the couple’s private records and is never bypassed to work around missing mail.

Choose the published invitation, enter a guest or family name and the maximum party size, then choose **Create guest link**. The generated URL includes a readable name label and a random private guest code. Send this link to that guest yourself. A guest link is a bearer link: anyone it is forwarded to can open that party’s invitation and reply for that party. Generic invitation links are also available.

Readable guest links include a name label and the existing full-strength private code, for example `/invite/aswin-radhika/menon-family--<private-code>`. The code identifies the saved party, greeting and maximum headcount. Changing the readable name label does not grant access to another party. Existing `invite/index.html?id=...&guest=...` links keep working. The one existing invitation has been given a readable address without moving its guest or RSVP records; the dashboard uses it after the new website is deployed.

## Gmail sender and branded email pages

The chosen sender is **digitrika@gmail.com**. In Firebase Authentication → Templates → SMTP settings, use `smtp.gmail.com`, port `587`, `STARTTLS`, and the same Gmail address for both username and sender email. Enter a Google App Password directly in Firebase. Two-Step Verification must be enabled for the Google account. Never put the password in this folder or share it in chat. This setup does not require a business-email inbox or a Firebase billing upgrade. Gmail sending limits and spam filtering still apply.

Gmail SMTP is configured in Firebase, and `digitrika.com` and `www.digitrika.com` are authorised for email continuation links. This confirms the saved settings, not inbox delivery. To test delivery, use the dashboard's **Send verification email** and verify the actual From address in the received message.

Firebase rejected email-template branding changes through the management API with `EMAIL_TEMPLATE_UPDATE_NOT_ALLOWED`. If desired, edit the verification template directly in the Firebase console: sender name **Digitrika**, reply-to **digitrika@gmail.com**, subject **Verify your email for Digitrika**. The actual SMTP sender remains the Gmail address configured above.

After the updated website is deployed and `https://digitrika.com/account/action/` opens the Digitrika account page, set **Customize action URL** in the Firebase email template to that address. Do this only after deployment. The page handles email verification, password reset and account email recovery, then returns clients to `/manage/`. Expired links are rejected; verification and password-reset success appear only after Firebase confirms them. The existing Firebase action page continues working until the new URL is activated.

Incoming RSVPs update the selected couple’s dashboard. Guests can amend a reply from the same browser; named guest links update the same party’s reply even from a different device. Generic links identify a browser, so another browser may create another response. Named links are preferable for a controlled guest list.

Wishes are shared privately with the couple and the studio. The public invitation does not list other guests’ replies or wishes. A success message appears only after Firestore confirms the write; a failed connection never falls back to a pretend local-only submission.

## Data, exports and limits

- `operators/{accountId}`: project-owner-controlled studio access.
- `invitations/{invitationId}`: private customer details, plan, notes and full configuration.
- `publicInvitations/{invitationId}`: only the published invitation configuration, status and expiry. Listing all public invitations is denied.
- `invitationSlugs/{readableAddress}`: immutable address-to-invitation mapping. Public lookup works only while its invitation is published and active; listing addresses is denied. Only the studio owner can reserve an address.
- `invitations/{invitationId}/guests/{randomToken}`: guest names and maximum party sizes.
- `invitations/{invitationId}/responses/{responseId}`: real RSVP replies.
- `invitations/{invitationId}/wishes/{guestAccountId}`: private wishes.

Use **Download CSV** for the guest list and **Download backup** for an individual invitation and its guest data. Hosting expiry and unpublishing stop public access and new submissions; they do not automatically erase the private records. Agree retention with each couple and remove old records from the Firebase console when no longer needed. Deleting a parent Firestore document does not automatically delete its subcollections.

The manager opens live listeners only for the selected invitation and removes them when switching invitations or leaving the page. Watch the Firestore Usage page; the free allowance is shared by all customers. Spark quotas are not unlimited, and hitting them can prevent new reads or replies until the quota resets. This setup does not configure automated database backups, paid extensions or email notifications for each RSVP.

## Final check before the first customer order

Create a temporary invitation with a future date and two test guests. In a separate browser/device, open a named guest link and submit an RSVP and wish. Check that they appear on the owner and verified couple accounts. Confirm that another couple cannot see that invitation, a guest cannot list the guest database, and unpublishing prevents new replies. Remove the temporary test data afterwards.

The supplied local tests cover data validation, field separation, client writes, theme rendering and regression checks. The Firestore rules have passed the local Firebase emulator tests, including verified couple isolation, blocked guest-list queries and rejected cross-account writes. Complete the real two-device test above after activating the project and publishing the rules.

Verification commands (test dependencies are in `scripts/firebase-tests/`):

```sh
node scripts/check-live-firebase.cjs
node scripts/firebase-tests/theme.test.mjs
node scripts/firebase-tests/manager.test.mjs
node scripts/firebase-tests/verification.test.mjs
node scripts/firebase-tests/links.test.mjs
node scripts/firebase-tests/email-actions.test.mjs
node scripts/firebase-tests/submission.test.mjs
```

For the database rules, run Firebase’s Firestore emulator with project ID `demo-digitrika` and execute `scripts/firebase-tests/rules.test.mjs`. This uses local synthetic data, not the live customer database. A Java 21 runtime is required for the emulator.

Official references: [Web setup](https://firebase.google.com/docs/web/setup), [Firestore rules](https://firebase.google.com/docs/firestore/security/get-started), [Spark plan](https://firebase.google.com/docs/projects/billing/firebase-pricing-plans), [Firestore free quotas](https://firebase.google.com/docs/firestore/quotas).