* Restore unique index on board_publications.key
The account_id rollout (fe6df7085) replaced the unique index on
board_publications.key with a non-unique composite (account_id, key)
index. This was unintentional — other tables in the same migration
preserved uniqueness (account_join_codes, tags) but this one did not.
Without global uniqueness on key, a crafted data import can insert a
duplicate publication key via insert_all! (which bypasses model
validations). Since find_by_published_key queries globally without
account scoping, this enables public board URL hijacking after the
legitimate owner unpublishes.
Restore the original unique index on key and keep a plain account_id
index for account-scoped queries.
* Reorder index operations: add unique index before dropping composite
On MySQL, DDL is non-transactional. If the unique index creation
fails (e.g. duplicate keys exist), the previous ordering would leave
the composite index already dropped. Adding the unique index first
means a failure leaves the database unchanged.
* Add schema dumps for both SQLite and MySQL
Dump both schema files after running the migration against each
adapter to keep the PR complete for CI.
The table_definition_column_limits initializer (PR #1669) applies a
default limit of 255 to all string columns during schema:load, but
schema_sqlite.rb was never re-dumped after it landed. This caused
drift on every subsequent migration PR that dumped the schema.
Re-dump from schema:load → schema:dump to make the file idempotent.
* Add index on webhook_deliveries.created_at
The stale scope (WHERE created_at < ?) and ordered scope
(ORDER BY created_at DESC) both benefit from this index.
Without it, Webhook::Delivery.cleanup does a full table scan.
* Run webhook delivery cleanup every 15 minutes
Each run now deletes ~15 minutes of newly-stale records instead
of ~4 hours worth, a 16x reduction in per-run write volume.
As we now update notifications with unread counts we sort them by the
time they were updated instead of when they were created. To keep that
performant we also have to change the previous indices that used
created_at to use updated_at.
We had client-side notification stacking in the tray since launch, but now we want to stack notifications in the notifications page, in API responses and in email bundles.
Add migration to replace comment_id with polymorphic reactable
association (reactable_type, reactable_id), enabling reactions on both
comments and cards.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add self-service account deletion
* Disable access to cancelled accounts & implement Stripe interactions
* Add tests
* Fix failing tests
* Remove cancelled accounts from lists
* Fix incorrect redirect
* Use _path instead of _url for consistency
* Don't track how far the inicieration job got
We still want the step tracking so that the job can be interrupted. But, since the scope is idempotent, we don't need to track how far it got.
* Specify the exact time when the data will be deleted
* Fix crash due to unadvancable cursor
* Rename up_for_incineration to due_for_incineration
* Regenrate the schema
* Fix incorrect path check
* Migrate the SQLite schema
* Only show the cancel button on cancellable accounts
* Check that a subscirption method exists before calling it
* Ignore job failures due to missing records when an account gets deleted
* Skip sending notifications on cancelled accounts
* Use collbacks to integrate
* Add a blank line between queue_as and discard_on
* Break checks into methods
* Inline methods
* Rename Account::IncinerateJob
* Run migrations
* Migrate SQLite
An append-only storage ledger replaces deadlock-prone synchronous
counter updates and drift-prone async updates.
All content storage (card images, card/comment/board description embeds)
is tracked. Account exports (which expire) and avatars are not tracked.
Storage is accounted for by Account and Board. Both consume the same
event stream independently: no bubble-up storage bumps triggering
deadlocks due to lock sequencing. Each calculates its own total from
the underlying ledger with independent cursors and materialization.
* Storage::Entry: Append-only ledger recording attach/detach/transfer
events with delta bytes. Single event stream indexed for both
Account and Board cursor queries.
* Storage::Total: Polymorphic snapshot cache with cursor (last_entry_id)
tracking which entries have been materialized.
* Storage::Totaled concern: Provides bytes_used (fast snapshot) and
bytes_used_exact (snapshot + pending) query modes, plus
materialize_storage! to roll up pending entries.
* Storage::Tracked concern: For models owning attachments (Card,
Comment, Board). Provides board_for_storage_tracking for models
where board is determined differently (Board returns self).
Handles board transfers by recording transfer_out/transfer_in entries.
* Storage::AttachmentTracking: Hooks ActiveStorage::Attachment lifecycle
to record attach/detach entries. Handles ActionText::RichText embeds
by traversing to the actual model. Snapshots context in before_destroy
to handle cascading deletes where parent record may be gone by
after_destroy_commit.
* MaterializeJob: Rolls up pending entries into snapshot. Concurrency
limited per owner to prevent duplicate work.
* ReconcileJob: On-demand reconciliation against actual attachment
storage for support/debugging. Compares ledger total to real bytes
from card images, card embeds, comment embeds, and board embeds.
Usage:
* account.bytes_used / board.bytes_used: fast, slightly stale bytesize
* account.bytes_used_exact / board.bytes_used_exact: real-time bytesize
* Storage::Entry: audit trail for debugging and point-in-time queries
User are marked as verified after a join code is redeemed. The user is
redirected to Users::VerificationsController, either:
- after submitting a valid magic link code,
- or immediately after redeeming the join code (if they're already
authenticated with the correct identity)
Account owners are automatically verified when the account is
created (because they have already provided a magic link code at that
point).
This sets up for later commits that will backfill existing users and
require verification before sending notification emails.
Co-Authored-By: Claude <noreply@anthropic.com>
- Adds a button in Account Settings where you can request a ZIP export of your
Fizzy data
- Export files are created in the background. When ready, a link to
download them is sent to the requester.
- Exports expire after 24 hours. And are limited to 10 per day.
Jeremy Daer