* Bind sessions to identities
* Remove references to the identity token
* Move email changes to identity
* Move account menu into a turbo-frame
* Create tenants from a tenanted route
- New untenanted Identity and Membership models
- New `identity_token` cookie with path "/" holds state across tenants
We're not sure whether the untenanted database will be sqlite or
MySQL, and so I've been careful to minimize
- database reads, placing them behind etags and caching
- database writes, only writing when a new Session is created (login)
Note that we track two things in the identity_token cookie: a signed
id, and the updated_at for the underlying Identity object. This allows
us to effectively cache on the Identity without having to hit the
database, by using an Identity::Mock object that is compatible with
etag and cache methods.
The new integration test shows the desired user-facing behavior, which
is to make it easy to login without a tenanted URL and to jump between
tenants.
- the untenanted "login_help" page shows all linked memberships
- the jump menu shows all linked memberships (except the current)
Also introduced a utility script to populate existing employee
Identities, grouping accounts by email address.
This is the first step of a multi-step SaaS engine extraction.
Looking ahead to an open source release, we need to make sure that
local authentication is treated as an "official" option, and not just
a hack I added for Kevin to do load testing outside our DC. So this PR
gets to green, and adds a CI step in "local authentication" mode.
This all probably feels a little hacky to you, Reader, but the goal of
this change is to ease the next step, which will be extracting the
37id and Queenbee integrations into a proprietary "SaaS mode" engine.
In service of that goal, this commit simply wraps all of the dependent
code and tests with a conditional check on
`config.x.local_authentication`.
* main: (50 commits)
Regenerate fixtures
Let summaries know about collections
Regenerate fixtures
More tweaks
Regenerate fixtures after tweaking prompt
Fix model selection (I had broken it!)
Some prompt refinements
Some of us have basecamp.com email addresses
Update nokogiri and thor to addres CVEs
Fix tests
Format
Move model options to helper
Tidy up the admin tool for prompts
Extract methods
Format
Default to the current summary
Make models selectable
Add an animated effect for the generating state
Remove debug
Wrap them both in the container so the generating state looks right
...
* main:
Update dependencies
dep: bump to ruby 3.4.5
Switch to docker-dev
Cache needs to include publication key
First iteration on adding new users, from the console.
Fix clear button position in Safari
Give them screen reader labels
Not needed
Add missing `lang` attribute
Restore missing aspect ratio on the perma
Give the field more space when typing on mobile
We're only concerned with truncating the placeholder, scope to that
Make sure users can't login from launchpad if they're deactivated
Destroy the SignalId::User when a user is deactivated
* main: (48 commits)
Improve layout and truncation
This is annoying
Fix summary
Remove index columns
Same treatment for the events index
New menu filters and navigates
Don't test for _Added by_ events
Indention
@collection is always available when card scoped
Style
Remove check for _Added by..._ line
The placeholder attribute is on the `house-md` element
Duh, no before destroy commit, but this is still not right!
No long transactions!
Don't display published event in threads
But feels more essentially part of the User, so list first
Not related to the other two
Missing controller
Style
Errant `bubbles` => `cards` replacement
...
# Conflicts:
# app/models/card.rb
# app/models/user.rb
# db/schema.rb
# db/schema_cache.yml
If you intend to deactivate someone, and the process fails mid process,
so you only delete some sessions, or some accesses, you are actually
fine. The system is never left in an incomplete state. And that's really
the only time we should be using transactions with sqlite3 -- to prevent
actual data integrity issues.
The rest of the time, we should optimize for each transaction to be as
quick as possible. The sqlite3 writer lock is the one bottleneck that we
cant afford to overload.
With a single database this problem is not as bad, but it feels
safer to do things right. Also, not everyone in an account has access
to all the bubbles.
Stanko K.R.