← Admin Tools

What's New — Admin View

Items shown in red are visible to administrators only and are not shown to regular family members.

July 2026

July 25, 2026

Family Passcodes — added an "Only those with a passcode" filter — Mirrors the existing "Only those without a passcode" checkbox. The two are mutually exclusive — checking one automatically unchecks the other — so you can't accidentally filter the list down to nothing.
Family Passcodes — corrected the page's notice text — It previously mentioned "a one-time email sign-in link," which no longer applies now that magic-link login is hibernated, and implied an email on file was required to set a personal passcode, which was never true. The notice now also makes clear that passcodes are always system-generated — nobody types their own value, they just generate and adopt a new one.

July 24, 2026

Sign-Up Sheets — invite lists are now private, and only the Organizer can add people to them — Two related tightenings, not shown to regular members. First, a sheet's invite list, item claims, and details are now only visible to its Organizer and the people actually invited to it — previously every signed-in family member could see every sheet, current or past, whether or not they were invited (e.g. a surprise party's guest list wasn't actually a secret from anyone who checked). Second, the "+ Add yourself to this list" self-add option is gone — only the Organizer (or an admin) can add someone to a sheet now; before, anyone could add themselves to any sheet regardless of whether the Organizer meant to invite them. As always, admins can see and do everything on every sheet, the same as before. Verified locally against several test accounts: Organizer add-invite works, a non-Organizer invitee is blocked (403) from adding others, an uninvited person sees zero sheets and is blocked even hitting the API directly, an invitee still sees their own sheet, and an admin retains full visibility and control.
Your own passcode is coming to you — you don't need to do anything — The old shared family password stops working on August 30, 2026. If you haven't set up your own passcode yet, we'll email you one automatically two weeks beforehand, on August 16. You don't have to sign in first to get it, and you don't have to do anything when it arrives — just keep it. The next time you sign in, use that passcode instead of the old family password, and you'll be asked to pick one of your own. It comes from [email protected] with the subject "Your Ratterman.Family passcode" — if you don't see it, please check your spam or junk folder, and look in any "Other" or "Focused Inbox" tab if your email has one.
A clearer message if you try the old family password after August 30 — Previously, typing the retired family password just said "Incorrect passcode," and five tries would lock you out for 15 minutes even though that password could never work again. Now it explains that the family password has been retired, tells you where to find your own passcode, and no longer counts those attempts against you — so you can't get locked out over a password that no longer exists.
The lockout gap this fixes — The July 16 plan said the August 30 deadline was informational and the shared password would keep working until you rotated it manually. That had a hole: sessions last 60 days and are completely independent of passcode status. Someone whose last real sign-in was in late June has their session expire in late August — before the rotation — with no personal passcode and no way to ask for one. Waiting for people to sign in and be prompted never reaches them, which is why the mailout goes out unprompted.
Both steps are now automated, and both need one-time setup from you — Two new scheduled GitHub Actions workflows: the passcode mailout on August 16 and the SITE_PASSWORD rotation on August 30. Cloudflare Pages Functions can't run cron jobs, so GitHub Actions calls the site over HTTPS. You must set a new MIGRATION_JOB_KEY secret in two places — once on Cloudflare and once in GitHub — or the mailout will fail. See docs/shared-password-retirement.md for the exact commands.
Rotating the secret alone would have silently done nothing — A Cloudflare Pages secret change does not affect the deployment that's already running; it only applies to deployments made afterward. A workflow that just wrote the new SITE_PASSWORD would have reported success on August 30 while the old family password kept working indefinitely, with nothing visibly broken to tip you off. The rotation workflow now redeploys the site immediately after writing the secret, then checks the site is actually back up.
Run the verify-only test before August 30 — The rotation workflow has a manual verify-only mode that writes and deletes a throwaway secret purely to prove the Cloudflare API token is allowed to write project settings, not just deploy. That permission has never been exercised — the deploy workflow only deploys — and discovering it's missing on August 30 with the family locked out is exactly what this avoids. Please run it once from the Actions tab.
11 people have no passcode and no email address — and they're not all children — 26 living family members have neither. The assumption was that these were all young kids covered by a parent's sign-in; that's true for 15 of them. The other 11 are 13 or older, including a 74-year-old first-generation member and six adults between 18 and 35. Nothing automated can reach them — there's no address to send to. They do not block the rotation (your call), but they'll each lose access on August 30 unless you collect an email address or hand them a passcode directly. The new report emails you and Nick the list, oldest first.
"Delivered" does not mean "they read it" — The report also lists everyone who was emailed a passcode but still hasn't set their own, which is the real follow-up list. Resend reporting "delivered" only means their mail server accepted the message — Outlook accepted Amy's magic-link email and then filtered it out of sight. Only passcode_set_at proves a human actually got a code and used it. The report can optionally ask Resend what happened to each message, which does catch hard bounces from stale addresses.
Safety rails on the mailout — It works in batches (hashing costs ~12ms of CPU per person, so ~50 at once would strain a single request) and can be resumed. If an email fails to send, the passcode is rolled back so nobody is left holding a code that never arrived, and that person is reported for retry. Nobody is ever emailed twice. There's a dry-run mode that lists exactly who would be contacted without sending anything, and a single-person mode so you can prove the whole path works on one willing volunteer before ~50 irreversible emails go out — worth doing.
Both workflows are year-gated and should be deleted afterward — GitHub cron has no "run once," so 0 14 30 8 * would fire every August 30 forever. A guard step makes any non-2026 scheduled run do nothing. Once the migration is confirmed, delete both workflow files and the passcode_migration_log table.

July 16, 2026

New way to sign in — your own passcode or a one-time email link — You can now sign in with your own personal passcode or a one-time link emailed to you, instead of the shared family password. On the sign-in page, type your name and your passcode, or use "Email me a sign-in link" to get a link that signs you in with one click (it works once and expires after 15 minutes). The first time you sign in, you'll be given a personal passcode to save — save it in your phone or browser's password manager so you don't have to remember it. During the switch-over the old shared family password still works until you've set up your own, so no one gets locked out. Your sign-in still lasts 60 days on each device. The sign-in page will remind you if you're still using the old shared password — it stops working on August 30, 2026, so sign in once before then to get your own passcode.
Migration deadline is not enforced automatically — The August 30, 2026 date shown on the login page is informational only, and the reminder itself disappears automatically the day after (so it won't linger claiming a past deadline). But that's cosmetic — the shared SITE_PASSWORD itself keeps working until you manually rotate it to a random string once you're satisfied everyone's migrated. Check the Family Passcodes admin tool to see who still hasn't set their own passcode before you do.
New — Family Passcodes admin tool — Admin Tools has a new Family Passcodes card. It lists every family member with whether they've set their own passcode, whether an email is on file, whether they're holding a temporary code, and whether they're currently locked out. You can reset anyone's passcode from here — it generates a fresh temporary code, emails it to them (or shows it to you to pass along if they have no email on file), and forces them to choose their own passcode the next time they sign in.
Roster no longer leaks on the login page — The old login flow showed a dropdown of every family member's name to anyone who reached the page. The name field is now type-ahead and returns nothing until at least 3 characters are typed, and only ever returns names (no contact info), so the full roster is never exposed.
Per-person lockout on failed sign-ins — Five failed passcode attempts lock that person out for 15 minutes (tracked per person via new failed_login_count / locked_until columns), on top of Cloudflare's existing edge rate-limit on /api/login. A correct passcode or magic-link sign-in clears the lock. Magic-link requests always return the same generic response whether or not the email is on file, so they can't be used to discover which addresses are registered.
Under the hood — Per-person passcodes are stored as PBKDF2-SHA256 hashes in the existing password_hash column (now used for everyone, not just admins); passcodes are system-generated 8-character codes (XXX-YYYY, ambiguous glyphs excluded). Magic links are single-use 15-minute tokens in a new login_tokens table. The shared SITE_PASSWORD keeps working during a 45-day migration window and stops working per-person once they set their own passcode; existing admins were backfilled so they are never prompted to reset. New endpoints: set-passcode, admin/reset-passcode, admin/passcode-status, people-search, request-magic-link, magic-login. After the migration window, rotating SITE_PASSWORD to a random string completes the cutover.

July 15, 2026

Sign-Up Sheets — rename a category or change its quantity — The Organizer of a sign-up sheet (and admins) can now click the pencil (✎) next to a category's name to rename it or change how many are needed, without having to delete and re-add it. Leave the quantity blank to make it unlimited.

July 4, 2026

New — a User Manual — There's a new User Manual item in the top menu with a plain-language, step-by-step guide to the whole site: viewing the Family List, exploring the charts on Fun with Data!, printing and saving lists and contact cards from Reports, using and creating Sign-Up Sheets, looking someone up, editing a family member's information, and keeping up with What's New. It has pictures throughout, and a button at the top to print it or save it as a PDF.

July 3, 2026

Sign-Up Sheets — templates now carry over invitees — When you use another event as a template for a new sign-up sheet, the people who were invited to that event are now automatically checked on the new one too (categories were already copied over). You can still add or remove anyone before saving.
Sign-Up Sheets — invitee list now sorted oldest to youngest — The list of invitees on a sign-up sheet now appears in age order, oldest first. For a couple, the older person's age is used.
Date of Birth is now required — When adding or editing a family member on the Edit page, Date of Birth must now be filled in.
Database: date_of_birth is now NOT NULL — Rebuilt the people table (SQLite requires a full rebuild to add a column constraint) after confirming no hard foreign-key references and taking a fresh wrangler d1 export backup. The shared "GuestRatt" guest account (GUEST-001) had no birthdate on file and received an obviously-fake placeholder (1900-01-01) since it's already hidden from every list/report. Also corrected schema.sql, which had drifted from the live table and was missing the is_admin, password_hash, include_in_list, and is_guest columns entirely.
Fixed: GuestRatt could appear in four admin-only views — /api/data only hides guest accounts from non-admins; admins always got the unfiltered list, and four pages weren't filtering it out on top of that: Reports' Custom Report member picker, the Dashboard's population/age stats, Sign-Up Sheets' "add a family member" dropdown, and Family Member Look-Up search. Regular (non-admin) members were never able to see it anywhere — this only affected what an admin could see. All four now exclude is_guest rows. It's still expected to appear on the Edit page's People directory, since that's where you manage its password.

July 2, 2026

Site Audit Notes page corrected — audit.html had a few stale numbers left over from the original June 14 QA pass (it said 11 HTML files / 9 authenticated pages / 0 hardcoded colors — all since changed by later work). Updated the counts and replaced the absolute "zero hardcoded colors" claim with an accurate description of the current policy (token-based everywhere except one print-popup window that can't reach theme.css). No functional change — this is a documentation correction only.

July 2, 2026

Pop-up windows are easier to use with a keyboard — Pop-up windows across the site (the Edit dialogs and the Sign-Up Sheet dialogs, plus the admin Send Group Email → Sent Emails detail window) now close on the Esc key, move focus into the window on open and back to where you were on close, and expose role="dialog" / aria-modal / aria-labelledby so screen readers announce them correctly. Lightweight treatment — no focus-trap.

July 2, 2026

Sign-Up Sheets — apostrophe in a contribution broke its edit button (fixed) — The per-claim ✎ (edit) button interpolated the description into an inline onclick call-string. esc() had already turned ' into ' (so the trailing .replace(/'/g,…) was a dead no-op), and the browser then decoded ' back to ' inside the attribute — producing invalid JS, so the button threw and did nothing for any description containing an apostrophe (e.g. "Mac 'n cheese"). The description is now carried in a data-desc attribute and read via element.dataset, so user text never becomes part of a JS call-string.
Sign-Up Sheets — interactive controls moved to event delegation — Every dynamically-generated onclick/onchange in signups.js (edit/delete event, request/approve/reject deletion, add/remove invite, add/delete category, add/edit/delete claim, attendee count, use-as-template, and the category-builder row remove) was converted to data-action + delegated listeners, matching the pattern already used for the hub navigation. No behavior change; the static modal-button handlers in signups.html were left as-is.

July 2, 2026

Family Member Look-Up — sign-out badge restored — lookup.js never called RFAPI.mountUserBadge(), so the Look-Up page had no "Signed in as… · Sign out" badge and <body> never got the .is-non-admin class — which also meant the Admin Tools nav link showed to every member on that page (a dead-end; the server still bounced non-admins). Added the mount call.
Records & Activity — toast notifications fixed — The local toast alias in admin-records.js passed its arguments to RFAPI.toast(msg, kind, duration) in the wrong order (3000 as kind, the type as duration). Success toasts rendered unstyled and error toasts vanished almost immediately (duration resolved to NaN). Restored correct coloring and the intended 3000 ms duration.

July 2, 2026

Sign-Up Sheets — menu-driven navigation — The main page is now a hub of three choices (Current Events / Past Events / New Event) rendered via client-side view-switching in signups.js. Current/Past show one-line lists (Organizer · date[+time] · title) that drill into the full sheet via the existing renderEvent; Past opens read-only. The standalone signups-past.html page was deleted (its role moved into the hub's Past view). The admin signups-pending-deletion.html page is unchanged.
Sign-Up Sheets — permission corrections — The event creator (Organizer) can now edit/delete any claim on their sheet (event-claims/[id].js canEdit now allows the event's created_by_id, not just admin/claim-owner). Invitees can remove themselves (event-invites/[id].js DELETE now permits self-removal when the actor is in person_ids, with an expired-event guard); a couple row removes both people. Admin-everywhere and invitee-own-line behavior were already correct.
Sign-Up Sheets — "Delete This Sheet" label + auto Organizer — Non-admin Organizer's button relabeled from "Request Deletion" to "Delete This Sheet" (same request→approval flow, same emails). The editable Organizer field was removed from the New Event form; organizer name is auto-set to the creator's nickname/first name and is omitted from edit PATCHes so it stays immutable. Existing events keep their stored organizer name.
Sign-Up Sheets — fixed category display order — Category columns are sorted at display time (sortedCategories in renderGrid) to a canonical order: Entrée, Appetizers, Salads, Sides, Fruit, Desserts, Rolls / Bread, then custom names in creation order, then "Other" last. Storage/entry order is unchanged. The suggestions datalist was trimmed to those eight ("Rolls" → "Rolls / Bread"; Beverages/Condiments/Paper goods/Chairs/Tables/Ice removed). "Past Lists" wording changed to "Past Events" throughout the live UI.
Sign-Up Sheets — templating refinements — The New Event choice + picker heading are now "Use Another Event as a Template," and openTemplatePicker lists all events (current + past, newest first) instead of past only. The per-sheet "Use as Template" button was removed from renderEvent's header (the useAsTemplate function stays, reached only via the picker).

July 1, 2026

Birthdays & Anniversaries — anniversaries now supported — The Edit page's Spouse/Partner section now has a "Marriage / Partnership Date" field, shared by both spouses since it lives on their one relationship record. Once a date is on file, the couple's anniversary automatically appears on the Birthdays & Anniversaries report — including marriages that ended in death (e.g. Nan & Pop), which are still commemorated each year. Populated initial dates for 23 of 24 current couples plus Nan & Pop from the family's historical records via direct database update (not through Edit, so these initial entries won't appear in Records & Activity). Two DePaulo marriages have no known date and were left blank.
Sign-Up Sheets — guided New Event creation — "+ New Event" now opens a 3-way choice (Start from Scratch / Use a Past List as Template / Cancel) instead of one dense form. The template picker lists past events by Organizer, Date, Title, and Location. The New Event form gained searchable Individual and Couple Invitee checklists (Colorado households, age 16+, deceased members excluded, nickname-first display, bidirectional mutual exclusion so a couple and its two individuals can't both be checked, nobody checked by default, with Check all/Clear all links). Invite lists are now built entirely from what the Organizer checks — the previous fully-automatic server-side generation (which also had no deceased-member exclusion) is gone. Also fixed a bug where a partnered person never got a standalone checkbox in the Individuals list at all — meaning mutual exclusion silently never triggered — which also affected the "add a family member" dropdown on an event card; it now correctly offers both the individual and the couple option for a partnered person, with no state/age restriction.
Sign-Up Sheets — deletion now requires Organizer or admin, non-admin requests go through review — Only the event's Organizer or an admin can delete a sheet now (previously delete was admin-only with no button shown to Organizers at all). An admin's delete stays immediate. A non-admin Organizer sees "Request Deletion" instead, which emails you (as admin) and the Organizer, then hides the sheet everywhere for everyone until you act. New column: events.deletion_requested_at (migration 2026-07-events-pending-deletion.sql).
New admin page: Lists Pending Deletion — Admin Tools → Lists Pending Deletion shows every sheet with a pending deletion request, read-only, with Approve Deletion (permanently removes it) and Keep Sign-Up Sheet (restores it, clears the flag) buttons. The Organizer is emailed the outcome either way. Backed by GET /api/events/pending-deletion and new POST /api/events/:id actions request_deletion / approve_deletion / reject_deletion, all audit-logged.
Sign-Up Sheets — Event Name capitalization can be overridden — The Event Name field auto-capitalizes to Headline Case on blur only until the Organizer or an admin edits it further (e.g. "Cinco De Julio" → "Cinco de Julio," since "de" is Spanish for "of"); after that the field is left exactly as typed. Editing an existing event's name never auto-recapitalizes it, so a previously-corrected name can't get silently mangled again.

June 2026

June 30, 2026

Send Group Email — Sent Emails log — The Send Group Email tool now has a "Sent Emails" tab listing every group email previously sent, with date, subject, sender, and recipient/sent/failed counts. Click "View" on any entry to see the full message body and complete recipient list.

June 22, 2026

vCard name format — All vCard downloads (Family List Address Book, Custom Report, Member Look-Up) now show a person's nickname as their contact name when they have one, instead of their formal first name.
Custom Report vCard — fixed missing contacts — The "Download .vcf" button on the Custom Report tab previously only showed the first selected person when opened in some contacts apps (including Windows). Fixed.

June 19, 2026

Reports — Custom Report vCard download — The Create a Custom Report tab now has a Download .vcf button alongside View & Print and Download PDF. After selecting members, click it to download just those people as a contact file ready to import into any contacts app.
Reports — Address Book download — A new Address Book card on the Family List tab of the Reports page lets any member download all living family members as a single .vcf file, ready to import into iPhone, Android, Outlook, or any contacts app. Sorted alphabetically; deceased members excluded.
Activity — IP address and location tracking — Every login and page view is now logged with the visitor's IP address, city, state, country, and ISP. The Recent Logins table now shows IP, Location, and ISP columns; Recent Views shows IP and Location. Only new activity going forward is captured — older entries show "—". Find this under Admin Tools → Records & Activity → Activity.
Guest account (GuestRatt) — You can now share the site with someone outside the family. Give them the shared site password and tell them to type GuestRatt at the name prompt — exactly as written, it is case-sensitive and will not appear in the login suggestions. Guests can browse all family data but cannot submit edits, sign up for sign-up sheets, or download PDF reports. The account is invisible everywhere on the site — not shown in the family list, reports, dashboard, look-up, or any dropdowns. You can manage the account from the Edit page.

June 18, 2026

Fun with Data! — corrections — A heading on the generation composition chart has been corrected, and a confusing subtitle has been removed. On narrow phone screens, the Births per Decade chart now scrolls horizontally so all decades are visible.

June 16, 2026

Family Member Look-Up — Download vCard — Every contact card on the Look-Up page now has a Download vCard button. Click it to download a .vcf file with that person's name, address, phone numbers, email, and date of birth — ready to import into your iPhone, Android, Outlook, or any contacts app.
Reports — Create a Custom Report — The Reports page now has tabs, including a new Create a Custom Report tab. Build your own directory by selecting whole clans — which checks everyone in that clan so you can uncheck any you don't want — and/or picking individual family members, then choose which columns to show (address, cell phone, email, date of birth — names are always included). Your custom list keeps the same order and household grouping as the full Family List, and you can view, print, or download it as a PDF.
Add-person requests now require approval — If a family member tries to add a new person to the site, the submission is now held in Pending Edits for your review. You receive an email notification and can approve, edit-then-approve (opens the Add Person form pre-filled with their proposed data so you can correct it before saving), or reject it. Previously, there was no server-side block and no notification.
Include in family list — admin toggle — A new "Include in family list?" field is now in every person's edit modal (visible to admins only). Set it to Yes to include a step-child or other non-bloodline, non-spouse person on the family list and in reports. The person appears in non-bold (married-in) style. This setting is never applied automatically — an admin must set it per person.

June 15, 2026

Sign-Up Sheets — add yourself — Any family member not already on a sign-up sheet can now add themselves with a single button click. Their name is added to the list so they can then sign up for any open slot.
Sign-up sheet delete restricted to admins — Previously the server would allow a sheet's creator to delete it via a direct API call even though the Delete button was only shown to admins. The server now enforces admin-only deletion to match what the site shows.
Admin privilege escalation blocked — A non-admin could previously craft a request to submit a pending edit that included an admin flag, which an admin might approve without noticing. The admin flag is now excluded from the pending-edit system entirely and can only be changed by an admin directly through the Edit page.
What's New — Admin Updates page — This page. A new admin-only changelog under Admin Tools shows all site changes, with admin-only items highlighted in red so they are easy to spot.

June 14, 2026

Age on Family Member Look-Up — Living members with a known date of birth now show their current age to one decimal point (e.g., "69.5 years old as of June 14, 2026") above their date of birth on the result card.
Show/hide password — Every password field on the site now has an eye icon button so you can reveal or hide what you are typing while signing in or changing your password.
Nicknames in all dropdowns — Every family member selection dropdown across the site now shows each person's nickname if they have one.
Login accepts nickname or first name — Members with a nickname can sign in using either their nickname or their formal first name.
Dark mode — All pages now respond correctly when a device is set to dark mode, with a consistent color scheme throughout.
Mobile navigation — On smaller phone screens, the navigation menu now wraps cleanly instead of running off the edge of the screen.
Records & Activity moved to Admin Tools — Pending edit requests, the recent-changes log, and the family activity summary are no longer on the Edit page. They now live under Admin Tools → Records & Activity, keeping the Edit page cleaner and those tools out of sight of regular members.
Sortable tables on the Edit page — The People and Households tables can now be sorted by clicking any column header. Click once to sort; click again to reverse. Hold Shift and click a second column to sort on two fields at once (e.g., Branch first, then Generation within each branch).
Site Audit Notes — A summary of the June 2026 quality review of the site's code is available under Admin Tools → Site Audit Notes.
Activity and history locked to admins — The Recent Changes and Activity data feeds now enforce admin-only access on the server, so a regular member cannot retrieve that data even by making a direct request outside the normal site pages.

June 13, 2026

Family Member Look-Up — A new search tool where any member can type a name and instantly see that person's contact card, including phone numbers, email, date of birth, and a clickable link to their address in Google Maps.
Sign-Up Sheets — member list — The dropdown when adding someone to an event now shows a member's nickname (if they have one), and no longer includes deceased members.
Phone number formatting — Hyphens are now added automatically as you type a phone number (XXX-XXX-XXXX), and numbers with fewer than 10 digits are not accepted.
Admin preview mode — You can now switch to a "family member view" to see exactly what the site looks like to a regular member — no admin tools, no pending-edit buttons, nothing admin-specific. A banner at the top lets you switch back with one click. Find the option in your user badge (top right).
Edit request confirmation email — The automatic email sent to a family member after they submit an edit request now includes a note telling them how long to expect before hearing back. This reduces follow-up questions to you.

June 12, 2026

Sign-Up Sheets — A new section where any family member can create a sign-up sheet for an event (holiday gatherings, potlucks, etc.), and everyone can claim a slot. Creators can edit their own sheets. Past events are stored and viewable separately.
Birthdays & Anniversaries print — Improved layout so the full list fits on one page, including on iPhones. A reminder now prompts users to select Legal-size paper for the best result.
Group Email — You can now send an email to the whole family or to a targeted group (e.g., all Colorado members, all adults) directly from the site. Find it under Admin Tools → Send Group Email.
Admin Tools hub — All administrator functions are now gathered in one place under "Admin Tools" in the navigation. Regular members see the link but are redirected away if they try to access any page under it.
Household delete — safety check — When you delete a household, the confirmation dialog now shows how many people are currently listed at that address, so you can see at a glance whether anyone will be left without a home address before you confirm.

June 11, 2026

Reports page — A new page with two printable/downloadable documents: the full Family List and the Birthdays & Anniversaries calendar. Both can be downloaded as PDF files or printed directly from the browser.
Submit update requests — You can now submit a request to update your information on the site. Look for the "Suggest an Edit" button on the Edit page.
Clickable contact info — Phone numbers and email addresses on the Family List are now clickable links.
Edit request workflow — When a family member submits an update request, you receive an email notification. You can then review the proposed change, approve it as-is, edit it before approving, or reject it — all from the Records & Activity page. The member receives an email at each step.

June 1, 2026

Undo recent changes — From the Recent Changes list in Records & Activity, you can undo any individual edit that was made in the past 30 days with a single click.
Write access restricted to admins — Regular family members can no longer make direct changes to any record on the site. They can only submit edit requests for your review. This prevents accidental or unauthorized changes to family data.