* main: (116 commits)
Ensure avatar thumbnails are square
Update useragent to recognize twitterbot/facebot
Add defensive styles for non-square avatar images
Update test for copy changes
Missed commit
AI: standardize on https://agents.md
Make it clear this is just notifications, not comprehensive activity
AI: configure MCP servers for Chrome, Grafana, and Sentry (#1727)
Allow requests from Google Image Proxy
Update to basecamp's useragent fork
Clean up a little bit the CSRF reporting code
Claude: production observability guidance (#1725)
Prevent autoscroll to the root columns container to prevent jump on page load
Include full name string so you can type your name to filter
Prioritize current user and assigned users in assignment dropdown
Check and report on Sec-Fetch-Site header for forgery protection
bundle update
Bump bootsnap from 1.18.6 to 1.19.0
Bump rails from `077c3ad` to `17f6e00`
Fix cards getting stuck in edit mode
...
This is a great, solid alternative to CSRF tokens for CSRF protection
when we aren't worried about older browsers or other kind of actors
doing modifying requests in our app, and could be a good test for future
upstreaming to Rails (although there we'd need to continue using CSRF
tokens or at least letting people opt out manually).
Let's start checking the header and reporting on it when CSRF fails or
when it doesn't match the other checks Rails does, and then promote this
to be the only way to defend from CSRF.
Instead of writer pinning, we'll track the last transaction ID of each
write in the session. Then on each read we'll wait for the replica to
report that this transaction is available.
If it doesn't become available within a reasonable timeout, we'll
proceed anyway, and accept the possibility of a stale read.
The hope here is that most of the time, the replica is caught up in the
time between a write request and the following read request. If it's
not, we now have a little tolerance to wait for it, which hopefully
proves enough to stale reads are not encountered in normal use.
We also disable the writer affinity opt-out mechanism that we had
before, since we will no longer be using writer affinity at the load
balancer.
User flows when editing a card look like:
- Click "Edit" → the closure buttons are replaced by "Save changes"
- Submit card form → Saves and restores closure buttons
- Press ESC while editing → Cancels and restores closure buttons
Also, renamed for clarity:
- _title.html.erb → _content.html.erb
Co-Authored-By: Claude <noreply@anthropic.com>
- redirect avatar image requests to the rails_blob_url, instead of
streaming them through the web app
- use a thumbnail variant for avatar images
- only put avatar initials behind the stale? check (not the image
redirect, which would result in browsers rendering broken images when
an avatar is changed, until max-age expires)
Locally, having stale_while_revalidate works great, but in production when we are behind CloudFlare, this results in an old image being shown after you upload a new one
See: https://app.fizzy.do/5986089/cards/2978
Primarily this is in tests (which were caught by temporarily
introducing acts_as_tenant and enabling safety checks), but notably
action cable connections were not working properly, and that's now
fixed.
Lean on ActiveRecord models for searching and strip out the raw SQL.
Replaces the search_index_* tables with sharded search_records_* tables
as that allows us to use a Search::Record model name.
A Class is dynamically created for each record table shard so that we
and we can access it via the Search::Record.for_account(account_id)
method.
In order for model ordering to work as expected in tests, we need to
keep two properties:
- Fixtures are all created in the past
- Models sort in the order that they were created
This allows us to do things like this:
post cards_path, params: { ... }
created_card = Card.last
When using UUIDv7 PKs rather than sequential integers, we have to make
sure a couple of things happen in order for this still to be true:
- Fixtures should generate deterministic IDs that translate to UUIDs
that would have been created in the past (i.e. before today)
- Newly created objects must have enough precision in their timestamps
so that they sort in the order they were created, and their random
component doesn't come into play.
To solve this, we use the deterministic numeric ID as a number of
milliseconds after an early year. And we ensure that the new timestamps
we create have sub-millisecond precision.
These are mainly because the fixture's UUIDs are deterministic rather
than time-sortable, and more places where we need to correct the fixture
IDs as well.
Rosa Gutierrez