Use the ClientSchedule data structure for deserialising and tracking
edit state on the client instead of trying to directly deal with the
ApiSchedule type which is not build for ease of edits or rendering.
Rename and refactor the types passed over the API to be based on an
entity that's either living or a tombstone. A living entity has a
deleted property that's either undefined or false, while a tombstone
has a deleted property set to true. All entities have a numeric id
and an updatedAt timestamp.
To sync entities, an array of replacements are passed around. Living
entities are replaced with tombstones when they're deleted. And
tombstones are replaced with living entities when restored.
An account refers to the user the active session is logged in as. As
such it doesn't make sense outside of the /auth API paths that deals
with the current authenticated user. Move /api/account to
/api/auth/account to reflect this.
Replace the convoluted useAccountSession composable with a pinia store
that in addition allows for the consolidation of all session related
functions to grouped into one module.
Render the timeslots as an editable table of times with associated
event. When the event it's linked to is edited the time slot is removed
from the original event it belonged to and added to the possibly new
event it now belongs to. This gives a somewhat intutive editing
experience when editing time slots linked to events with multiple times.
Add allowedAccountTypes page metadata which the authenticated middleware
uses to further restrict the types of accounts that can access the page.
If the account type is insufficent to access the page it will return an
HTTP 403 Forbidden status, which is rendered using the error page.
To make it possible to render the timetable in the user's local time we
need to know the timezone to render it in on the server. Otherwise
there will be hydration errors and paint flashing as the client renders
a different timezone.
Add a server global default timezone that can be overriden on a
per-account bases to prepare for timezone handling the timetable.
Provide a basic account system with login and server side session store
identified by a cookie. Upon successful login a signed session cookie
is set by the server with the session stored on the server identifying
which account it is logged in as. The client uses a shared useFetch on
the session endpoint to identify if it's logged in and which account it
is logged in as, and refreshes this when loggin in or out.
