Privacy policy
This policy describes the data AnySchedule actually stores, where it lives, who can read it, and what happens when an account is deleted.
1. Who we are
AnySchedule is a scheduling application for institutions. It consists of a Flutter application and a Supabase project that provides the database (PostgreSQL), authentication and private file storage. There is no separate analytics, advertising or profiling service, and the application does not collect location, contacts or device identifiers.
A support address is published only when a real one is configured for a build. No placeholder address is shown to users.
2. What we store
- Account credentials. Your email address, a password hash, your email-verification state and your last sign-in are held by Supabase Auth. The password hash is never visible to AnySchedule.
- Profile. Your display name, which is optional, and a reference to your profile photo.
- Profile photo file. Stored in a private storage bucket. It is readable only through short-lived signed links for your own account.
- Preferences. Language, time zone, appearance and notification choices, so your settings follow you between devices.
- Institutional records. Schools, classes, subjects, teachers, rooms, periods, timetables and reservations, keyed by institution. These records belong to the institution, not to an individual.
- Membership and role. Which institution you belong to and what you are allowed to read or change there.
- A deletion audit record. A record that an account was deleted. It contains no name, email or profile.
Nothing else is collected. There is no advertising identifier, no access to your contact list and no background location.
3. What we do not collect
- Location data, contacts or device identifiers.
- Advertising identifiers, analytics identifiers or behavioural profiles.
- Cookies or local storage on this marketing website.
- Learner records: classes are groups in a timetable, not people.
4. How we use it
- To sign you in and keep your account secure.
- To show your own name and photo to you.
- To apply your preferences on every device you use.
- To run the scheduler and store the timetables an institution builds.
- To decide who may read or change an institution’s data.
- To keep an audit record of account deletions.
Data is never used for advertising or profiling, and no decision that affects you is made by automated means alone.
5. Legal bases
Where data-protection law requires a legal basis for processing, the operator of an AnySchedule deployment will rely on performance of a contract when providing the scheduling service to an institution, legitimate interests when keeping accounts and institutional records secure, and consent for optional information such as a profile photo.
A jurisdiction-specific mapping of legal bases depends on the operator identified for your deployment. This repository does not define one, and this page does not invent one.
6. Hosting and providers
AnySchedule runs on Supabase, which provides the PostgreSQL database, authentication and private object storage. Supabase acts as the hosting provider and processes data on behalf of the operator of a deployment. Data lives in the Supabase project that the operator configures for that deployment.
No other processors are configured in this repository: there is no analytics vendor, no advertising network, no crash-reporting service and no email marketing tool.
7. International transfers
Where data is physically processed depends on the region chosen for the Supabase project. This repository does not fix a region and does not claim a transfer mechanism it has not implemented. An operator deploying AnySchedule must record the region and any transfer safeguards that apply to their deployment.
8. Retention
Account data is removed from the live database when an account is deleted. One limitation cannot be removed by application code:
Backups managed by the hosting provider may still contain the deleted data until the provider replaces them on its own schedule. AnySchedule itself keeps no copy after the account is deleted.
No other retention period is implemented in this repository. This page states no fixed number of days for backups until the hosting plan’s backup window is confirmed and recorded.
9. Your rights and choices
- Edit or clear your display name, and add, replace or remove your photo.
- Change your email address. The change takes effect only after the confirmation message is opened, and both the old and the new address may need to confirm.
- Change your password, signing in with the current one first.
- Sign out of this device, or of every device.
- Delete your account and its personal data.
Requests that need a human cannot yet be routed, because no support mailbox is configured for this release. That is a limitation of the current build, and it is stated here rather than hidden.
10. Account and data deletion
You can delete your account from inside the application, or without it through the public account deletion page. Both routes call the same server-side deletion function; the client is never trusted to perform the deletion itself.
Deleting an account removes:
- Your profile: display name and profile photo.
- Your preferences: language, time zone, appearance, and notification settings.
- Your sign-in credentials, email address, and every active session.
- Your membership of every school, including any administrator role you hold.
- The stored copy of your profile photo.
Deleting an account keeps:
- Schools, classes, subjects, teachers, rooms, periods, timetables, and reservations that belong to a school. They belong to the institution and stay available to the other members who rely on them.
- A record that an account was deleted (no name, email, or profile), so deletions can be audited.
One situation needs a decision before deletion. If your account is the only administrator of a school, deletion is refused until another administrator is appointed, because removing the last administrator would lock the remaining members out of their own timetables. The application names the blocking schools, and the refusal comes from the database rule rather than from the screen.
11. Children’s privacy
AnySchedule is intended for institutional use by adults: administrators, teachers and viewers. It does not create accounts for learners, and classes in a timetable are groups rather than personal records. The product is not directed at children and does not knowingly collect personal data from children.
12. Security
- Authorization is enforced by the database through row level security and by the server-side deletion function. The client is never trusted.
- The application never receives a service-role key.
- Passwords are never stored, logged or written by AnySchedule code.
- A published timetable is immutable at the database level until the term is unpublished.
- Profile photos live in a private bucket and are read through short-lived signed links.
13. Cookies and this website
This website sets no cookies, uses no local storage and loads no third-party resources. Its typeface is self-hosted, so visiting these pages makes no request to an external font provider. There are no accounts, forms, tracking pixels or analytics of any kind on the marketing pages.
The account deletion page is different only in that it contacts the authentication service when you deliberately submit its form.
14. Changes to this policy
When the collected data, the deletion behaviour or the retention rules change, this page, the in-app disclosure and the public deletion page change in the same release. The date at the top of this page is the date of the current text.
15. Contact
No support mailbox is configured for this release, so no address is published here in place of one that nobody reads. Until a real contact route exists, account and data requests are handled through the account deletion page and the account settings inside the application.