The change door
For an app on Supabase, everydeck adds its own Edge Functioneverydeck-write-door to your Supabase project after you approve. It is not in your repository. We call it the change door.
It writes like your Supabase dashboard does, but only what is switched on. Everything else the door refuses by itself.
- Each change runs in one transaction, so your app’s triggers, rules and foreign keys apply.
- If your database refuses a change, its message comes back word for word, with e-mail addresses masked.
- The door accepts only signed requests from everydeck.
- Data in your app: edit, archive, delete with what goes with them, and remove a single message.
- Users of your app (Supabase Auth accounts): send a sign-in link, send a password reset email, resend the confirmation email, suspend and restore access, edit their details, delete an account. See People.
Apps with their own server can offer changes through their own app bridge instead. The standard setup does not build one.
What is on after you approve
When you approve, the content people of your app see, people and messages are on. Technical tables (roles, imports, notifications, mail, jobs, settings) are off. The approval box says “IDs, owners and timestamps are never editable.”Settings: Changes from everydeck
Go to Technical › Changes from everydeck. The card says: “Everything below works as approved. Switch something here only if you want it different.” It has two parts:- Users of your app: the accounts people use to sign in (Supabase Auth).
- Data in your app: records in your tables, like in the Table Editor of your Supabase dashboard. Technical kinds say “Off since the approval: everydeck counts them as technical, not as what your app is about.”
New permissions
A new version of everydeck may be able to do more in your app than you allowed. Then the card says, for example, “everydeck can now also archive bookings.” with two buttons:- Allow: everydeck updates the change door in your app now.
- Not now: everydeck keeps the change door as it is and does not email you about it again.
When the door does not answer
everydeck checks the door when it starts, every hour, and after each rollout or switch. If the door does not answer, the page says “The change door in your app does not answer everydeck, so changes from here are paused.” with the reason and Check again.Editing a record
On a record page, click a value (“Click to change”), change it and save under the field. Or click Edit to change all editable fields.- Never editable: ids and references, owners, timestamps, values your database keeps itself, and fields another system manages.
- everydeck checks only the form of a value (number, yes or no, date, value from the list). It has no rules of its own. If your app refuses, its message appears at the field.
- Changed in the meantime: if your app changed the record since everydeck read it, nothing is saved. The page shows the current values. Change again and save.
Reasons
A reason is required for archiving, deleting, fields marked as needing one, and exporting personal data. The reason goes into the protocol and to your app.Deleting
Deleting is red: it needs the typed name and a reason, and it cannot be undone. Before you delete, the page shows what goes with it in the database, what stays without a link, and what would stop the delete. If the table hasdeleted_at or is_deleted, everydeck deletes softly, like your app does.
Second factor
Deleting objects and people and red actions ask for a fresh confirmation with your second factor (an authenticator app), if you set one up. The confirmation stays fresh for 10 minutes. Editing, archiving and exporting do not ask for it.Undo and the protocol
Every change is in the protocol: who, when, why, before and after for each field. “Undo sets the old value, only if nothing changed since.”- Undo works for field edits, for 1 day.
- There is no undo for archiving, deleting and bulk changes.