* main:
Fix image icons
Revert "Merge pull request #345 from basecamp/cascade-layers"
Fine tune notifications states
Remove empty helper
Use an icon for the button
Show button on collection page and notif settings
Add involvement types to accesses
Extract a couple components
Add cascade layers to all CSS files
This provides a way to set the level of involvement that a user has with
a collection, and from which we determine the level of notifications to
send. Users can be access-only, watching, or being notified about
everything.
If you're access-only, you won't get an notifications. If you're
watching, you'll only get notifications for the items you're watching
(which includes the items you've been assigned, have commented on, etc).
If you're set to everything you'll get notifications about all activity
in that collection.
This change replaces our previous concept of subscriptions. Where
previously you'd subscribe to a collection to get notifications in it,
now you'll simply set the notification level on your access.
The previous implementation would delete all accesses if the bucket
was not all_access.
I think it's simpler to move the bucket workflow into a separate
Buckets::WorkflowsController, rather than deal with different sets of
params from different forms in the existing BucketsController.
- we no longer need to explicitly add the TenantSelector middleware
- and we can set up a properly-articulated tenant resolver proc that's
used by both TenantSelector and Action Cable connections
ref: https://37s.fizzy.37signals.com/buckets/693169862/bubbles/999008671
ref: https://3.basecamp.com/2914079/buckets/37331921/messages/8422006338
The script takes advantage of the fact that we can bind to the
existing untenanted database by adding it explicitly (and temporarily)
as a readonly shard to the database.yml, and so in the script
with_original_db is connected to the original database.
storage/tenants/%{tenant}/ is now the root directory for all
state stored for a particular tenant, including active storage and the
database.
We leave the existing files and production database in place after the
migration, in case we need to roll back (by reverting the code and
config).
We also don't do a granular active storage blob copy, since the
attachments are mostly on Account (and not on Bubble). Instead we
hardlink the blobs on disk (so we don't take up additional space with
duplicates).
Finally, we're manually adding the kamal-proxy hosts to the deploy
file, so that we can generate letsencrypt certs for the
subdomains. This is only intended to be a short-term solution, we'll
want something like a wildcard cert before we go live.
Because solid cache started using shard swapping when given a
`database:` key in https://github.com/rails/solid_cache/pull/219, and
Rails doesn't distinguish which database is being swapped and which
was locked.
Hopefully I can make a change upstream that will enable swap locking
only for a specific databases. Until then, let's just use a slightly
more verbose configuration to work around it.
We use a true/false preference so we can tell the difference between
disabling the watch vs never having the watch. This is so we can toggle
off and on the preferences for a container (like the bucket) without
losing any bubble-specific preferences.
David Heinemeier Hansson