Platform Updates

Repositories: partners.furries.ph and Partners API. Status: Database migrations published; hosted catalog verification passed.

What’s Changed

Operational user identity now consistently uses the unified account records across registration reservations, Social-location authority checks, trigger-based revocation, and disposable-fixture cleanup. The retired account table is absent, and the remaining executable database routines were recompiled against the unified identity model.

Impact

Registration and location-consent flows continue to use the same attendee-facing behavior while resolving account ownership through the current unified account records. Existing event references and capacity rules remain unchanged.

Upgrade Notes

The focused migrations are published. Hosted catalog checks found no retired table, view, foreign-key dependency, or executable database routine reference. The V2 frontend, API type checks, and focused database regressions passed locally. No frontend release is needed for this database-only repair.

Repositories: partners.furries.ph and Partners API. Status: Database migration published; local checks passed.

What’s Changed

Payment providers now explicitly use either a receiving account number or a payment link. The provider dialog asks for a display name only when the organizer selects Other; recognized providers retain their standard public names.

Impact

Organizers can choose the collection method that matches each provider, while attendees see consistent provider names and only receive a payment link when that method is selected.

Upgrade Notes

Existing providers with payment links were classified as payment-link providers; other existing providers use account-number collection. Partners and API type checks passed locally. Release both applications together before using the new option in a hosted event.

Repositories: partners.furries.ph and partners-api. Status: Database correction published; hosted mailer verification pending.

What’s Changed

When registration opens or a registration-window reminder is due, the event email audience is now limited to people with an active saved prefill for that same event. General registration-email preferences still apply, but they no longer make someone eligible for every event notice.

Impact

People who have not started and saved an event registration draft should no longer receive its continuation emails. Revoked or expired prefills are also excluded. Existing queued messages are checked again immediately before delivery, so messages waiting to send are suppressed if the recipient is not eligible.

Upgrade Notes

The recipient-contract check and Partners typecheck passed, and the database migration is published. Emails already delivered cannot be recalled; a future mailer run is still needed for end-to-end hosted delivery evidence.

Repository: partners.furries.ph. Status: Local implementation verified; deployment pending.

What’s Changed

Volunteer applications now use the compact, native Furries PH form editor with collapsible question and section cards, ordered choices, managed choice images, required-answer settings, and conditional paths. The same reusable editor now powers registration, activities, Dealers Den, feedback, catalog, volunteer, and Signals survey forms instead of using a Google Forms-style editor. RegoSite has no Google Forms-style authoring surface; its public dynamic forms continue to consume the existing API-owned definitions.

Partners attendee previews now render registration, activity, and Dealers Den questions with the same RegoSite controlled form runtime. Preview-only answers, validation, choice behavior, conditional visibility, and local image handling match the attendee form without making an account, capacity, payment, or submission change.

Impact

Event organizers see one consistent authoring workflow wherever they configure an attendee or applicant form. Existing form schemas, validation records, routes, managed media, and submitted responses remain under their existing EMS ownership.

Upgrade Notes

Partners type checking and the focused volunteer browser workflow passed locally. Before treating this as hosted evidence, verify each form surface with an authorized organizer account, including saves, images, conditional routing, survey page rules, and the attendee-facing presentation.

Repositories: RegoSite and Partners API. Status: Cloudflare widget and Worker secret configured; application release pending.

What’s Changed

RegoSite now runs Cloudflare Turnstile quietly in the background when an attendee starts a protected action. Standard Rego runs that check directly on the main event-registration page and proceeds to the first registration choice; there is no separate verification or “Start registration” card. Account creation, sign-in, and attendee-profile prefill follow the same no-extra-step pattern. An interactive challenge appears only when Cloudflare needs one. Shop keeps verification out of browsing and the cart: it is requested and server-verified only when the attendee presses Place order.

The API validates each single-use token against the correct Rego action and hostname; a browser token alone is never trusted.

Impact

Automated traffic cannot create attendee accounts, trigger attendee sign-in initiation, complete an initial profile, consume event capacity, or place a shop order without passing human verification. Local-only development remains available without a hosted Turnstile widget.

Upgrade Notes

The managed widget and Worker-only verification secret for rego.furries.ph are configured. Release RegoSite and Partners API together, then verify account creation, password, email-code, passkey, initial-profile, standard-rego start, and the final Shop Place order action with fresh tokens.

Repositories: Partners, Partners API, and RegoSite. Status: Local implementation; not yet deployed.

What’s Changed

Event payment methods now show one organizer-ordered receiving account at a time. If an attendee reports an issue, only that checkout advances to the next account for the same provider. After three distinct attendee reports, the receiving account is automatically disabled and marked for review. Organizers receive the report in their dashboard and email, can review its details on the affected account while reordering accounts within that provider, mark each individual issue resolved with an accountable timestamp, and manually reactivate a resolved account.

The embedded Rego and Dealers Den payment flow follows the same rule: selecting a provider assigns its first active organizer-ordered account, with no receiving-account picker shown to attendees.

Payment provider names now use their proper public brand styling, such as GCash, PayPal, Coins.ph, and UnionBank. Unrecognized provider names are shown in readable Title Case.

Standard Rego capacity holds now expire after an API-chosen five to ten minute window. When a hold expires, checkout is blocked by a recovery dialog whose only action returns the attendee to the event page to begin a fresh verified registration.

Impact

Attendees no longer choose between multiple published receiving accounts. A single report does not disable the account for other attendees; the third distinct report triggers the shared safety stop, which an organizer must manually reverse after resolving the issue.

Rego holds become shorter as live holds, recent checkout starts, or capacity pressure increase. An expired hold cannot be renewed in place, so attendees always begin a new checkout against current availability.

Upgrade Notes

Release Partners, Partners API, and RegoSite together. Verify a configured multi-account provider, three distinct attendee reports, the automatic disable, organizer inbox/email delivery, manual reactivation, and dashboard account ordering before treating the change as hosted evidence.

Apply 20260922003523_dynamic_rego_hold_expiry.sql, then verify a quiet event receives a ten-minute hold, demand shortens the returned expiry to the five-to-eight-minute range, and expiry opens the blocking restart dialog.

Repositories: Partners dashboard and Partners API. Status: Local implementation; not yet deployed.

What’s Changed

Partner profile setup and profile contact editing now update the existing primary phone contact instead of attempting an upsert against a non-matching conflict key. New users still receive one primary phone record, while repeated saves and phone-number changes remain safe. If an older service error is returned during setup, the dashboard keeps the completed form ready to retry and shows a safe recovery message rather than a database error.

Impact

Partner users can finish profile setup when their account already has a primary phone contact. The database’s one-primary-phone rule remains enforced, including when two saves arrive close together.

Upgrade Notes

Release the Partners dashboard and API changes together before asking affected users to retry setup. Local API type-checking, focused contact/address route contract, and dashboard browser recovery contract pass; no hosted deployment was performed.

Repositories: admin.furries.ph, Partners API, and Partners database migrations. Status: Local implementation; not yet deployed.

What’s Changed

The Admin Partner users directory now starts with every partner-role membership. Staff can search by person, filter by partner or role, view details, and change a partner role in a focused modal. The Attendee directory also starts unfiltered, with search plus account, terms, and country filters.

Impact

Administrators can find people without choosing an organization first. Attendee records remain separate from staff and partner access: filtering attendees does not grant or change a role. Existing role hierarchy checks and protected account-deletion safeguards remain in place.

Upgrade Notes

Release Admin, Partners API, and 20260921230010_admin_partner_user_directory_unscoped_list.sql together. Local contract/type checks and synthetic browser verification cover the directory states; no hosted role change, invitation, or attendee deletion was performed.

Repositories: Partners, Partners API, and RegoSite. Status: Local implementation; not yet deployed.

What’s Changed

Event organizers can now hide registration progress on an event’s public Rego page. The Registration configuration toggle hides spaces remaining, saved prefill totals, and registration totals while keeping registration availability, capacity enforcement, and waitlist behavior unchanged.

Impact

Use this setting when an event should accept registrations without publicly displaying attendance progress. Event staff retain the existing private registration, prefill, and analytics workspaces.

Upgrade Notes

Release Partners, Partners API, and RegoSite together. Local type checks verify the persisted setting and public rendering contract; hosted deployment remains separate.

Repositories: RegoSite and Partners API. Status: Local implementation; not yet deployed.

What’s Changed

Profile setup and contact-address editing now explain why a real delivery address is needed. Street / unit accepts only a house, building, or unit number plus street name: it rejects placeholder entries such as 0, 000, and #0, common fake values, Purok numbers used in place of a house or unit, and complete addresses that repeat the locality, city, postal code, or country in that field.

When a street / unit entry ends with complete, comma-separated values that exactly match the locality, city, province or region, postal code, or country already selected, RegoSite now offers a reviewable cleanup. The attendee sees both values and must choose whether to use the cleaned street / unit; no address is changed automatically.

Impact

People with an affected saved placeholder or combined address will be asked to complete their profile again. Enter locality, city, postal code, and country in their own fields. Organizers may use the saved address to send event inclusions or other items when an attendee cannot attend, or when an event shop offers delivery.

Upgrade Notes

Release RegoSite and Partners API together. Local type checks and focused profile-readiness/address-validation checks are required before deployment; this does not verify a physical address or perform a live release.