- Add Card#commentable? method that returns true only for published cards.
- CardsController#create ensures that the card is commentable.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Reaction: belongs_to :reactable (polymorphic) instead of :comment
- Comment: has_many :reactions with as: :reactable
- Views: use reaction.reactable instead of reaction.comment
- Fixtures: use polymorphic syntax for reactable association
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Refactor: improve query scope composition with merge syntax
Replace manual WHERE clause concatenation with Rails' merge method
for more elegant and maintainable scope composition across Card,
Comment, and Filter models. This approach better follows Rails
conventions and improves code readability.
* Extend scope composition improvements to Card::Closeable
Apply the same nested hash syntax pattern to closures table references
in order and where clauses.
* Remove unnecessary outer braces from where clause
---------
Co-authored-by: Jeremy Daer <jeremy@37signals.com>
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
- Switch to binary 16 for UUID keys
- Remove AccountScopedRecord base class, all model use binary uuids now
- Fix the search sql to serialize uuids properly
- Patch the MySQL schema dumper to output binary lengths
Add a single search_index table for full-text search of cards and
comments.
For the search there is a full-text index on the title and content
columns. The board_ids is also included in the table and accessible
board ids are pre-loaded and included in the search query. This allows
us to filter out inaccessible records before joining with other tables.
Right now the search is just using boolean search. This would give us
a bunch of syntax options
(see https://dev.mysql.com/doc/refman/8.4/en/fulltext-boolean.html)
except the search query filters those out.
I've removed the searchable_by method for now - everything is built
on the assumption that there's a single search index table and all data
must fit into it.
Queries are written in SQL, we don't have a SearchIndex ActiveRecord
model. That's because we'll likely want to shard the table and it will
be simpler to just keep with the raw SQL for that.
There's no stemming, highlighting or snippet extraction yet - we are
dumping the full description in the search results.
Data can be reindexed with the search:reindex rake task.
* main: (45 commits)
Display tag counts in the filter menu
Move Add Card button to header
Re-write help content, try a modal-like display
Move to internal registry
Show date instead of time for notifications older than 1 day
Ensure checks are visible for tags and assignments
Adjust padding so card number isn't cut off
Don't color the collection header in considering
Golden cards bubble to the top of Considering, too
Adjust card collection header when colored golden
Allow cards in Considering to gilded
Hide focus ring on new card titles and step inputs
Add hover effect for comment edit button
Add hover effect to overflow button
Improve multi-account behavior of the PWA
Remove unneeded *
Rename test
Review the code to move cards
Update editor
Generalize and delete mentions too
...
- It does not make sense to scan "event summaries" for notifications.
- Placing them at the message level prevents us from using the generic approach to extract the mentionable content
This introduces a more dynamic system of activity scoring, to improve
the way bubbles "bubble up" due to their activity. There are a few
different parts we can tune here, and it's likely we'll need to make
adjustments once we get a feel for how this works in practice.
The basic idea here is:
- We assign points for certain types of event that happen on a bubble. A
boost gets 1 point, a comment gets 10 points, and so on.
- These points decay over time, at a rate of 50% per day. So old
activity is worth much less than new activity. Bubbles should rise up
quickly when acted upon, bit will float back down if left idle.
- Some comments can score higher than others: the first comment from
each person on a bubble is worth more (20) because it signals that
more people are getting involved; and comments that follow a comment
by a different author are also worth more (15) because that signals
there's ongoing conversation between people, not just a series of
notes being left by one individual.
In terms of implementation, we persist the score on the bubble
whenever it changes, but we handle the decay on the client side. That
allows us to cache the bubble representation without having to
continually change it while its activity decays.
We also keep a separate `activity_score_order` attribute on the model.
This can be used to sort the bubbles in order of "most active", without
having to think about the decay.
Mike Dalessio