Friendly-Community.com

Administrator manual — key procedures, warnings, and delicate handling. Compiled July 2026.

Overview

This is a private community forum for residents of 100 South Doheny, built and maintained by Pierre as a solo, non-technical developer working with Claude as development partner. It is a single-page HTML frontend deployed via FTP, backed by a Google Apps Script server and a Google Sheets database — no traditional hosting, no formal backend framework.

This manual exists to capture what would otherwise only live in scattered conversation history: the conventions that keep the site stable, the places where a small mistake can cause real damage, and the reasoning behind decisions that might otherwise look arbitrary to a future reader (including a future Pierre).

Architecture

Layer	What it is
Frontend	One large HTML file (`index.html`), plain JavaScript, no framework. Edited in BBEdit, uploaded via FileZilla.
Backend	Google Apps Script (`Code.gs`). Deployed as a Web App; the frontend calls it via `fetch()` to a hardcoded script URL.
Database	A single Google Sheet with many tabs — residents, chat threads, contractors, mailing lists, logs, and site file registrations.
Email	Sent via `GmailApp.sendEmail()`, authenticated as Pierre's real Google Account, using `noreply@friendly-community.com` as a display alias.

Critical Terminology — Never Conflate These

These are easy to mix up and mean genuinely different things. Using the wrong one in code or conversation has caused real confusion before.

Term	Meaning
Suspend	Blocks login. Reversible. Visible to members as `[Post suspended by moderator]`.
Delete	Former resident. Permanent (soft-delete flag, not row removal).
Unsubscribe	Stops mass communications. Keeps full forum access and login. Stored as a `status` value on the Registered sheet — an unsubscribed resident is still fully registered.
Total Hide ("occult")	Completely invisible to members, no trace, no notice — different mechanism from Suspend. Set via the Cleaning Posts admin tool.
Registered vs Members	Members sheet = the resident roster (imported/maintained by Pierre). Registered sheet = who actually created an account. A person can be a Member without being Registered.
TEST_MODE	One master Script Property. Controls WHO receives mass email (test addresses vs real residents). Does not control what counts as new activity — see the Testing section below.

Deployment Rules

These conventions exist because they prevented real regressions in the past. They are not optional style preferences.

FIND/REPLACE only — never full-file rewrites

Full-file rewrites have caused repeated regressions historically. Every code change should be a precise, verified FIND/REPLACE against the actual current file — never a wholesale rewrite.

Verify before editing

Always view the actual current file/line before proposing an edit. Guessing at code shape from memory or from an earlier session has caused wasted cycles and incorrect fixes more than once.

Syntax + duplicate-function check before every deployment

Run a syntax check and a duplicate-function scan before any file goes live. Only updateAdminBtn and doLogout are known-harmless pre-existing duplicates — see Known Harmless Duplicates.

BBEdit quirks

BBEdit's Find/Replace can silently fail on multi-line blocks containing em-dashes, emoji, or middle-dot characters — even when nothing looks unusual. When Find reports 0 results but the text is visibly present, switch to Go-To-Line plus manual select/paste rather than repeatedly retrying Find/Replace.

Apps Script: saving ≠ deploying

This has caused live-but-not-working bugs before. Saving a script file only updates the editor's copy. The live Web App URL only updates after Deploy → Manage deployments → New version. A change that "did nothing" is very often this.

Testing Safely

Test data is real data. TEST_MODE only controls who receives an email — it does not affect what counts as "new activity" for the Weekly Broadcast. Any test chat post or test contractor entry added during testing sits in the real sheet and will appear in the next real broadcast to actual residents unless manually deleted or hidden before then.

The weekly broadcast cutoff timestamp moves on every run — test or real. weeklyBroadcastLastRun is a single Script Property. Every execution of weeklyBroadcast overwrites it to "now," with no distinction between a manual test and the real Sunday trigger. Testing repeatedly in quick succession, close to a real scheduled send, can cause the real send to miss activity that happened between tests. It is only safe to test freely when the last real send is well in the past and the next one is days away.

Safe testing checklist:

Check whether a real (Live Mode) broadcast has already gone out this week. If yes, testing today is safe regardless of timestamp effects.
If testing close to a real scheduled send: note the current weeklyBroadcastLastRun value before testing (Apps Script → Project Settings → Script Properties), then restore it afterward.
To guarantee a test run finds "new" activity without fighting the timestamp: post a genuinely new test message immediately before running — it will always be newer than any prior cutoff.
Clean up test content (chat posts, contractor entries) before the next real send if it shouldn't reach real residents.

Tests Prior to Communications

Every mass or targeted send carries real risk: wrong content, wrong recipients, or an incomplete send that looks successful. The checklist below distills lessons from real incidents (July 12–13, 2026) into a repeatable pre-send routine.

A "sent successfully" message is not proof everyone received it. On July 12–13, 2026, a 215-recipient targeted send hit Apps Script's 6-minute execution limit partway through; the browser reported failure, but ~64 emails had already gone out — and a later 78-recipient batch silently stopped after 69 with no error at all. The only reliable source of truth is the Targeted_Send_Progress tracking sheet (for sends using the batching system) or a direct Gmail Sent-folder reconciliation — never the on-screen message alone, especially past roughly 50–75 recipients.

Before sending to more than a handful of people:

Send a test copy to yourself first. Confirm the subject, body text, images, and every link/button actually work — including clicking through to the destination page, not just visually inspecting the email.
Re-verify the recipient list is current, not stale. If any exclusion was computed earlier in the session (e.g. "everyone except those who already registered"), rebuild it fresh immediately before sending — registration status changes in real time, and a list computed even an hour earlier can already be wrong.
Use "Paste emails to select" for any list built outside the app. Manually checking boxes one at a time for anything beyond a handful of people is slow and error-prone; paste the exact email list instead and confirm the "Selected X of X" count matches exactly.
The Recipient Selector's save/restore was fixed July 19, 2026 — selections are now keyed by unit+email pair (not email alone), so saving and reopening correctly restores exactly what was checked, including for multi-unit owners with only some units selected.
After sending, reconcile against reality — the Targeted_Send_Progress tab for batched sends, or a Gmail Sent-folder search for older-style sends — before assuming everyone on the list received it.

When searching Sent mail to verify a send, copy the subject line directly from an actual sent email — never retype it. Em dashes (—) and en dashes (–) look nearly identical on screen but are different characters to Gmail's search; a mismatched dash silently breaks an exact-phrase search and can return wildly wrong counts (seen firsthand: a search returned 286 unrelated results before the dash issue was found). If two sends share an identical subject line (e.g. Hello Neighbor v1 and v2), add a precise time cutoff — Gmail's after:/before: operators accept exact epoch timestamps, not just dates — to isolate one send from the other.

For any send to roughly 100+ recipients: use the batched sending system (see Targeted Letters) rather than a single-pass send. It sends in small batches via a time-based trigger, staying safely under the 6-minute execution limit, and logs each recipient's status in real time in the Targeted_Send_Progress tab — turning "did everyone get this?" into a simple question to check rather than an investigation to run.

Backups & Recovery

Three backup copies of all site files: FTP (live), Dropbox, and a local non-cloud Working Folder.

A Dropbox "copy" of a Google Sheet is usually not a real copy. Saving/opening a Google Sheet from within Dropbox typically creates a shortcut file pointing to the same one document in Google Drive — not an independent duplicate. Confirm by comparing the file ID in the URL (the string between /d/ and /edit) between the two locations; if identical, it's the same file wearing two hats.

For a genuinely independent structural backup ("Skeleton"): File → Make a copy in Google Sheets creates a truly separate document with its own ID. Delete all data rows, keep only headers, to get a safe reference for the schema alone.

For a genuinely independent data backup: File → Download → Microsoft Excel (.xlsx) — this actually exports the data out, with zero ongoing connection to the live sheet.

Moderation: Hide / Suspend / Delete

Action	Visible to members?	Reversible?	Where
Total Hide	No — completely invisible, no trace	Yes, via Show All	Cleaning Posts tool
Suspend	Yes — shows `[Post suspended by moderator]`	Yes	Standard moderation controls
Delete (member)	Removed from roster	Soft-delete, flag-based	Master List Maintenance

Total Hide is implemented via a hidden column value of "occult" on chat rows, matched by email extracted from the 3-part userId (lastName|unit|email). It never touches rows where hidden === "true" (a real Suspend), keeping the two mechanisms independent.

The Administrator account has a 2-part userId (admin|1104), not 3-part. Code that extracts an email from the last |-segment of userId must special-case this, or Administrator's own posts/actions will silently fail to match.

Registration & Login

Session persistence is implemented via localStorage (fc_session), with a sliding 30-minute idle timeout. Login also remembers the last-used Last Name and Unit (fc_lastLogin_lastName / fc_lastLogin_unit) for convenience on return visits — deliberately excluded for Administrator, since "Admin"/"1104" pre-filling on a resident's screen would be confusing.

Admin key format matters everywhere. The login key is admin|1104 — code checking admin identity should use .startsWith('admin|1104'), not an exact match, consistent with the 3-part key migration applied to all other residents.

Registration: One Screen, Two Modes

There is only one registration screen and one doRegister() function — it branches on whether the incoming URL has an ?email= parameter, giving two distinct behaviors from the same code path:

Invited mode (URL has ?email=X&unit=Y): the form is pre-filled and the email field is locked. This is the correct mode for anyone reached via a personalized link.
Walk-up mode (bare index.html, no parameters): a blank form, fully self-service. Correct for someone finding the site on their own.

A "plain link" workaround downgrades Invited mode to Walk-up mode. During the July 12–13, 2026 GlitchFix incident, a broken personalization bug was worked around by sending a plain index.html link with no parameters — which fixed the immediate breakage, but silently meant every recipient landed in Walk-up mode instead of Invited mode. It's a legitimate emergency fallback, but not the correct long-term pattern.

The correct pattern for any new targeted or invitation-style letter is buildRegisterLink(email, unit), which generates a proper personalized link — the same helper used by both Hello Neighbor and Targeted Letters (see below). Using {{registerLink}} in a letter template and letting the send function substitute it per-recipient is the supported approach; hand-building a link, or falling back to a bare link, should be treated as a temporary measure only.

Contact Administrator

Non-registered visitors on the bare landing page see a "Kindly register…" prompt instead of the real contact form — this only applies to the landing page specifically; Login, Register, and Forgot Password screens still allow real contact (visitors mid-registration aren't blocked).

Guests who do reach the real form must pass a server-side check: at least 2 of 3 of Email / Unit / Last Name must match the same row in the Registered sheet before their message is allowed through. Logged-in users skip this check entirely — their password login is already stronger verification.

Weekly Broadcast

Runs via a Sunday 2:00 AM Pacific time-driven trigger, calling weeklyBroadcast(). Scans all Chat_ and Contractor_ sheets for activity since the last recorded run, and — only if there's something new — emails a recap to Mass_Mail_List, filtered by exclusions and opt-outs.

Each recipient gets a different button and message depending on whether they're already registered:

Already registered: a "Go to the Forum" button linking to ?login=1, pre-filled with their last name and unit (never their password) — plus message_to_already_registered.html, fetched live from the site.
Not yet registered: the original "Join Our Community Forum" registration button, pre-filled with email/unit — plus message_to_non_registered.html.

Both message snippets are separate, editable HTML files fetched fresh on every send (same pattern as sendTargetedLetter), with safe built-in fallback text if either file is ever missing or unreachable.

Contractors

Adding a contractor recommendation requires: Trade/Category (routing key — determines which Contractor_ sheet tab the entry is written to; cannot be optional without risking an orphaned sheet), Contact Name, and a Phone Number (at least 10 digits). Company Name, Email, and Comments are optional.

Hello Neighbor

There are two separate, complementary ways to send the Hello Neighbor letter — not duplicates of each other, and not a "pick one and retire the other" situation:

	🔵 Blue "Send hello neighbor" button	Targeted Letter + Recipient Selector
Recipients	Automatic — everyone eligible in Mass_Mail_List	Manual — you choose exactly who
Best for	A genuine mass invite to everyone unregistered	A specific person, unit, or scoped group (e.g. one floor)
Batching / timeout safety	Not batched — same 6-minute execution risk the old GlitchFix bug had	Batched, trigger-driven — safe at any size
Test Mode	Fully supported — dry-runs against Test_Mail_List	Not available — refuses to run unless Live Mode is already on
Reporting	Hello Neighbor report (Reports card)	Targeted Letter report (Reports card)

Do not remove the blue button as "redundant." It's the only way to do a genuine mass send to everyone unregistered at once, and the only one of the two that supports a safe Test Mode dry-run. The Recipient Selector is for scoped, deliberate, case-by-case selection — the two exist for different situations.

Both paths send the same underlying Hello_Neighbor.html template and personalize it identically via buildRegisterLink(email, unit).

Targeted Letters

The Recipient Selector shows every Member except those marked deleted on the Members roster. The Status column reflects the person's actual Registered-sheet standing: Not Registered, ✓ Registered, ✓ Registered (Suspended), or ✓ Registered (Unsubscribed) — registration is always shown as true when it's true, with Suspended/Unsubscribed layered on as a qualifier rather than replacing it (a person can absolutely be both registered and unsubscribed).

Multi-unit checkbox behavior

Each Members row (one unit + one email) is tracked independently. Checking a row you haven't touched yet auto-selects every other row sharing that same email — a deliberate convenience for multi-unit owners. Unchecking any single row only affects that row — sibling units stay exactly as they were. This means a scoped selection (e.g. "everyone on floors 3–12 for an HVAC notice") won't be derailed just because one of those owners also has an unrelated unit elsewhere in the building — check the range, then individually uncheck anything that doesn't belong.

Show selection (left action panel) opens a live list of everyone currently checked — unit, name, email — so you can review the full picture before committing to Save or Send. It stays live while open: further checkbox changes, Save, or Clear all update it immediately rather than showing a stale snapshot.

Communications Report

Admin Panel → Reports card → Open. A full-page, read-only viewer covering all four mass-communication functions, so "did this actually send?" is a lookup instead of an investigation through the Gmail Sent folder or Apps Script's Executions log.

Report	Shows
Targeted Letter	Every send since the report was added — status, error (if any), letter, recipient, unit, mode, timestamp
General Letter	Same shape, from the existing General_Letter_Log
Hello Neighbor	Same shape, new dedicated report tab
Weekly Broadcast	One summary row per run — timestamp, recipient count, mode (no per-recipient detail, by design)

Reports only capture activity from when this feature was added (July 2026) forward. Nothing sent before that point will appear — there's no retroactive backfill.

Test Mode coverage is uneven. Hello Neighbor, General Letter, and Weekly Broadcast all log correctly in Test Mode, tagged Mode: Test — a safe way to verify the reporting pipeline without touching real residents. Targeted Letter cannot be tested this way: it refuses to run at all while Test Mode is on, so nothing reaches its report until a real Live Mode send.

Credentials

Admin password is intentionally plaintext in the Registered sheet. This is a deliberate choice, not an oversight — it gives Pierre direct visibility/edit access via the Sheet itself, without extra tooling, to quickly revoke or change access.

Email Deliverability

SPF, DKIM, and DMARC are all confirmed passing for friendly-community.com. Yahoo-specific spam-folder placement has still been observed, including outside of testing bursts. Since technical authentication is already clean, this points to sender reputation and engagement history rather than a fixable code or configuration issue.

There is no code fix for this. Yahoo weighs domain age, sending-volume consistency, and real recipient engagement (opens, complaints) more heavily than the other major providers. Rapid bursts of near-identical test emails actively work against this. The practical response: mark affected test emails "Not Spam," avoid further test bursts, and let real, steady weekly sending build reputation over time.

Sender Photo / Privacy

Gmail recipients may see Pierre's personal Google Account profile photo next to forum emails — this is standard Gmail behavior tied to the authenticated sending account, independent of the display alias/name used. Yahoo and most other providers do not show this at all.

To suppress it: Google Account → Personal info → under "Choose what others see," click Go to About me → find the Profile picture entry → set to Only you. Note this is an account-wide setting, affecting all uses of that Google Account, not scoped to forum mail specifically.

Known Harmless Duplicates

Do not "fix" these without deliberate review — they are not identical.

doLogout — two declarations exist; only the second (later) one actually runs in JavaScript. It's missing a stopAutoSync() call the first copy has, currently harmless because both end in a full page reload.

updateAdminBtn — two declarations; the one that runs lacks a null-safety check the other has.

Cleaning these up properly (keeping the better half of each) is a real, deliberate task for a dedicated low-traffic session — not a quick delete.

Cleanup Backlog

Template editor UI wiring for the two Weekly Broadcast message snippets (functionally complete without it — files can be edited directly and re-uploaded via FTP)
doLogout / updateAdminBtn duplicate cleanup (see above)
Yahoo deliverability — monitor, no action currently available
Revisit test-data-pollutes-real-broadcast behavior after more real-world usage
sendHelloNeighborToAll and sendGeneralLetter still lack the batched, trigger-driven redesign Targeted Letter received — both remain exposed to the same 6-minute execution timeout on large sends
sendHelloNeighborToAll checks registration off the deduplicated Mass_Mail_List row (one row per email, lowest unit number survives dedup) — a multi-unit owner registered on one unit won't get invited for a different, still-unregistered unit if the registered one has the lower number. Agreed fix (not yet built): check registration per-unit and generate a separate invitation link for each unregistered unit under an email
Targeted Letter has no Test Mode dry-run — it refuses to run at all while Test Mode is on. A scoped addition (route to Test_Mail_List / BCC-only when a test flag is passed, without touching the batching logic) would close this gap if it becomes worth the effort

Emergency Rollback

If a deployment causes a serious regression: FileZilla still holds every prior numbered version of both index.html and the Apps Script file. Re-upload the last known-good HTML version via FileZilla (Overwrite mode), and for Apps Script, redeploy the prior version via Deploy → Manage deployments, selecting the earlier version number. The project has recovered from a full authentication outage this way before by rolling back to a stable baseline rather than trying to patch forward under pressure.

🔐 Administrator Manual