Furries PH Docs
Dashboard

Updates

Platform Updates

Public-facing release notes for meaningful changes across Furries PH operational systems.

First created Last updated

Showing release notes 171-180 of 1437
2026-10-0219:32

Dealer packages can set their own base registration price

Repositories: Partners, partners-api and Rego.

What changed: Tier-based Dealers Den packages now have a switch and price field to override the base registration cost per attendee. Partners can set a cheaper, higher or zero price. Booth fees remain separate, upgrades add their regular tier price difference, and tier inclusions remain unchanged. Registrants see a notice when the package rate is below their selected tier’s regular value.

Who may notice: Partners configuring booth packages and dealers choosing attendee tiers.

Next steps: Enable the override in package pricing and review the total before saving. Turning it off restores regular pricing for new registrations. Existing registrations retain their submitted pricing policy for subsequent upgrades, refunds and transfers.

Validation: Focused API and frontend fixtures cover normal, discounted, higher and zero rates, upgrade differences, add-ons, fees and saved policies. API, Partners and Rego type checks/builds pass. The rendered editor shows the switch, lower-value notice and updated totals, restores regular pricing when switched off, and fits a mobile viewport. These checks created no live registrations or payments.

2026-10-0219:32

Registration emails prepare Gmail event extraction

Repositories: partners-api and Partners.

What changed: Confirmed attendee and dealer emails explicitly label the event, ticket holder, confirmation number, schedule, venue/address and entry QR. Eligible emails include structured EventReservation metadata. Partners can maintain a complete structured venue address in Event Details for Gmail extraction.

Who may notice: Attendees and dealers receiving confirmations, and partners setting up events.

Next steps: Complete the structured venue address and arrange Google’s two separate sender reviews: Wallet’s visible-email parser sample and Gmail’s structured-email allowlist. Wallet class approval alone does not enable Gmail importing. Recipient settings and Google’s parsing determine automatic saving; imported copies are separate from managed Wallet passes.

Validation: Focused confirmation and address tests cover attendee/dealer states, incomplete metadata, escaping, authorization and conflicting edits. API and Partners type checks, Worker build validation, Partners build and Docs checks/build pass. The rendered address editor rejects partial input, saves complete input, and fits a mobile viewport. Google’s Email Markup Tester extracts a synthetic EventReservation with no required-field errors; optional performer/modification recommendations remain. No real email or Google review submission was sent by these checks.

2026-10-0219:32

Google Wallet tickets use Google's reference layout

Repositories: Partners, partners-api and Rego.

What changed: The Wallet editor uses Google’s official Event Ticket reference template beside live draft settings, with managed artwork, color and an approved-class test-pass action. Event details and assigned conditions provide defaults. Confirmed emails include event details and a current-owner QR image. Existing Wallet passes receive registration changes and messages matching successfully sent event email-blast recipients. Transfers rotate the entry reference and revoke the former owner’s object.

Who may notice: Event partners configuring tickets, attendees and dealers saving passes, and check-in teams handling transferred registrations.

Next steps: Complete missing canonical venue/schedule details, save the configuration and inspect a test pass in Google Wallet. Gmail import and recipient-specific account restrictions need Google’s approval; automatic saving and push delivery depend on Google and recipient settings. Offline check-in snapshots must sync after transfers.

Validation: Partners/Rego typechecks and production builds, API typecheck/Worker dry-run, six focused provider/email/announcement/QR/transfer/dealer-upgrade fixtures, and Docs check/static build pass. Desktop/mobile checks verify the official template, live edits and no horizontal overflow. Linked API, Partners, Rego and Docs deployments succeeded. Hosted preview and Rego code were checked; live authorized preview endpoints return synthetic tickets, and the approved-class test link contains one isolated non-entry object with a ten-minute lifetime. The official template is served as text to prevent CDN HTML rewriting. Final device rendering is controlled by Google; no real email blast, registration or payment is created by these checks.

2026-10-0219:32

Dealers Den settings keep compact field heights

Repository: Partners.

What changed: Dealer capacity stays at normal input height. The merchandise requirement uses a full-width editor below the numeric settings. The preview now renders the actual settings component.

Who may notice: Partners configuring Dealers Den applications.

Next steps: Refresh the dashboard to load the corrected layout; saved settings remain unchanged.

Validation: Typecheck and production build pass. Desktop/mobile rendered checks show 38px capacity/fee inputs and no narrow-screen overflow. The code fix is pushed for linked deployment.

2026-10-0219:32

Booth packages have explicit registration types

Repositories: Partners, partners-api and Rego.

What changed: The booth package editor separates a rego-tier-based booth surcharge from a standalone fixed-price package. Partners choose the base tier, approved higher tiers and optional add-ons, or select standalone catalog inclusions and fixed variants. Dealer registration follows the package’s choices and displays the corresponding attendee and package costs.

Who may notice: Event partners configuring Dealers Den packages and approved dealers registering themselves and their assistants.

Next steps: Review the package type and price preview before saving. Existing packages retain legacy pricing until deliberately converted. Purchased totals and entitlement commitments remain historical records.

Validation: Focused booth pricing, catalog projection, policy, actual upgrade handlers and disposable migration/RPC fixtures pass, including stock shortage rollback and immutable variant quantities. Partners and Rego typechecks/builds, Worker dry-run build, and Docs checks/build pass. Desktop/mobile editor checks pass. The migration is installed in production. Linked API, Partners and Rego deployments succeeded; hosted package editor and dealer pricing components were checked, and the live Dealers Den API returns the new policy fields while existing packages retain legacy pricing. No real registration or payment was submitted.

2026-10-0119:32

Packaging Tracking uses a fixed-quantity checklist

Repository: Partners.

Validation: Partners typecheck and production build pass. Desktop/mobile shared-component checks verify fixed quantities, explicit saving, historical partial progress and disabled unpaid items. Docs check and static build pass. Hosted deployment is tracked separately.

What’s Changed: Packaging Tracking shows a packing checklist with quantities fixed by registration-tier inclusions, add-ons and shop orders. Partners mark whole ready item lines packed instead of editing numeric quantities. Mark all packed selects the ready items in the current draft; Save packing persists the selections, package label and notes.

Impact: Logistics teams can check off the package contents without changing the quantities purchased. Previously saved partial progress remains visible until a line is marked fully packed. Existing eligibility, source-change review and packing history continue to apply.

Upgrade Notes: No API or database schema change is required. Packing remains preparation only; payment, stock and handover records keep their existing meaning.

2026-10-0119:32

Packaging Tracking has its own Logistics page

Repository: Partners. Account packing now opens as Packaging Tracking, a separate page in Logistics directly below Inventory Tracking. Inventory Tracking continues to show stock counts and movement history. Packaging Tracking retains per-account purchase items, partial packing, package labels, notes, history and source-change review.

Validation: API/database persistence and permission tests remain valid. The page uses the existing packing API; dedicated route, navigation, responsive preview and linked release checks are recorded during this update.

2026-10-0119:32

Account packing in Logistics Tracking

Repositories: Partners and partners-api.

What’s Changed: Logistics Tracking now groups attendee, dealer and shop purchase items by account, retaining transaction references, variants and quantities. Partners can save partial packing progress, package labels and notes, review packing history, and reset progress when correcting a package. Unassigned purchases remain distinct.

Impact: Event logistics teams can prepare an account’s purchases together. Unpaid, inactive and already-released items show their eligibility. Changed purchases flag saved packages for review, and revision checks protect against overwriting another operator’s progress.

Upgrade Notes: Packing records preparation only. Existing payment, stock and item handover records remain authoritative. Inventory manage permission is required to save progress; inventory view permission permits review.

Validation: API projection/permission tests and disposable PostgreSQL persistence, audit, concurrency and privacy tests pass. Partners typecheck/build, Docs check and desktop/mobile shared-component interactions pass. The production private schema and rollback-only persistence check are verified; the Git-linked API build and authenticated test-event packing/history reads pass. Production currently has attendee records only; dealer, shop and POS coverage uses representative fixtures.

2026-10-0119:32

Partner-only internal registration numbers

Repositories: Partners and partners-api. Each event now has one internal numbering sequence shared by attendee and dealer registrations. Existing registrations are numbered from oldest to newest, beginning at 1. New registrations receive the next number automatically. Status changes preserve numbers, and deletion does not make a number available for another registration.

Partner workflow: Find the searchable Internal # in registration rosters and details. Public registration references stay unchanged. Internal numbers are held in a private database ledger and exposed only through authorized partner records and exports; attendees cannot read the ledger, and Rego pages, receipts and emails do not include them.

Validation: Disposable PostgreSQL backfill/allocation/privacy tests, API authorization and exact-decimal projection tests, Partners typecheck/build and desktop/mobile roster previews. Production backfill is verified against chronological order and full registration coverage.

All docs