Scott Idem d3bf314c62 fix(launcher): refresh file lists periodically to prune deleted/hidden files
The Launcher's background sync never called load_ae_obj_li__event_file for
presenter/session files. That function contains stale-record pruning that
removes deleted or hidden files from Dexie; without it, the Launcher's IDB
retained stale file records indefinitely until manually cleared.

Changes:
- refresh_presenter_data: add inc_file_li=true so presenter files are pruned
  every 120s via the existing presenter loop
- refresh_current_session_files(): new function that fetches/prunes session-
  level file lists for the selected session
- timer__file_list: 60s interval for refresh_current_session_files
- $effect on event_session_id: fires refresh_current_session_files immediately
  on session switch (no wait for next timer tick)

Propagation time: deleted/hidden files visible on remote Launchers within
~60s (session files) or ~120s (presenter files) automatically.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-27 20:12:10 -04:00
2026-01-26 16:19:05 -05:00
2026-02-19 19:20:16 -05:00

One Sky IT's Aether App - SvelteKit v2 with Svelte v5

This uses SvelteKit version 2.x with Svelte version 5.x, DexieJS 4.x, TailwindCSS 4.1, and Skeleton.

Modules

Core (/core/)

Admin-only views for foundational Aether objects. Minimal UI — primarily used for data management.

  • Accounts (/core/accounts/, /core/accounts/[account_id]/)
  • Activity Logs (/core/activity_logs/)
  • Addresses (/core/addresses/, /core/addresses/[address_id]/)
  • Contacts (/core/contacts/, /core/contacts/[contact_id]/)
  • Lookups (/core/lookups/) — Countries, subdivisions, time zones
  • People (/core/people/, /core/people/[person_id]/)
  • Sites (/core/sites/, /core/sites/[site_id]/)
  • Users (/core/users/, /core/users/[user_id]/)

Events (/events/)

The primary client-facing module for conference and event management.

Event List (/events/)

Event Detail (/events/[event_id]/)

Each event has four sub-modules, each in its own SvelteKit route group:

Presentation Management (/(pres_mgmt)/)

Manages the full conference program.

  • /events/[event_id]/pres_mgmt/ — Dashboard
  • /events/[event_id]/locations/ — Location list
  • /events/[event_id]/location/[event_location_id]/ — Location detail
  • /events/[event_id]/presenter/[presenter_id]/ — Presenter detail
  • /events/[event_id]/session/[session_id]/ — Session detail
  • /events/[event_id]/reports/ — Presenter, session, and file reports

Launcher (/(launcher)/)

Kiosk display system; runs on-site to show session schedules and presenter info.

  • /events/[event_id]/launcher/ — Launcher home
  • /events/[event_id]/launcher/[event_location_id]/ — Location-specific display

Badges (/(badges)/)

Badge printing and management for event attendees.

  • /events/[event_id]/badges/ — Badge list
  • /events/[event_id]/badges/[badge_id]/ — Badge detail
  • /events/[event_id]/badges/[badge_id]/print — Print a single badge
  • /events/[event_id]/badges/[badge_id]/review — Review before printing
  • /events/[event_id]/badges/print_list/ — Bulk print queue
  • /events/[event_id]/badges/stats/ — Badge statistics
  • /events/[event_id]/templates/ — Badge template management

Leads (/(leads)/)

Exhibitor lead capture via QR scan or manual entry.

  • /events/[event_id]/leads/ — Exhibit list
  • /events/[event_id]/leads/exhibit/[exhibit_id]/ — Exhibit detail and lead capture
  • /events/[event_id]/leads/exhibit/[exhibit_id]/lead/[exhibit_tracking_id]/ — Lead detail

Event Settings (/settings/)

  • /events/[event_id]/settings/ — Event configuration (basic info, pres mgmt, badges, abstracts)

Journals (/journals/)

The "frontier" module — most fully-featured and used as the canonical implementation reference.

  • /journals/ — Journal list
  • /journals/[journal_id]/ — Journal detail and entry list
  • /journals/[journal_id]/entry/[journal_entry_id]/ — Journal entry detail and editor

IDAA (/idaa/)

Custom module for the IDAA client. Built on core Aether objects (Events, Posts, Archives).

  • /idaa/ — IDAA home / dashboard

Archives (/idaa/archives/)

  • /idaa/archives/ — Archive list with media player
  • /idaa/archives/[archive_id]/ — Archive detail and content list

Bulletin Board (/idaa/bb/)

Built on the Posts and Post Comments objects.

  • /idaa/bb/ — Post list
  • /idaa/bb/[post_id]/ — Post detail and comments

Recovery Meetings (/idaa/recovery_meetings/)

Built on the Events object.

  • /idaa/recovery_meetings/ — Meeting list with search/filter
  • /idaa/recovery_meetings/[event_id]/ — Meeting detail

Video Conferences (/idaa/video_conferences/)

  • /idaa/video_conferences/ — Video conference list (Jitsi integration)
  • /idaa/jitsi_reports/ — Jitsi usage reports

Hosted Files (/hosted_files/)

  • /hosted_files/ — File list and upload management
  • /hosted_files/video_util/ — Video processing utility

Testing (/testing/)

Developer sandbox pages — not for production use.

  • /testing/ae_obj_field_editor/ — V3 field editor playground
  • /testing/data_store/ — Data store V3 playground
  • /testing/editor_test/ — CodeMirror / TipTap editor tests
  • /testing/hosted_files/ — File upload tests

How to build and deploy SvelteKit:

The deployment is fully integrated into the unified Aether Docker Environment (aether_container_env). The application is built inside a clean Docker container using vite build --mode <env>, which reads the corresponding .env.<env> file for PUBLIC_ variables.

Environments

Environment Env file Vite mode API server
dev .env.dev dev dev-api.oneskyit.com
test .env.test test test-api.oneskyit.com
prod .env.prod prod api.oneskyit.com

Commands (from aether_app_sveltekit/)

# Active development — Vite HMR, no Docker
npm run dev

# Build Vite output only (no Docker)
npm run build:dev
npm run build:test
npm run build:prod

# Build Docker image and restart container locally
npm run build:docker:dev
npm run build:docker:test
npm run build:docker:prod

# Deploy to remote server (SSH → linode.oneskyit.com → deploy.sh)
npm run deploy:remote:test
npm run deploy:remote:prod

Technical Details

  • Unified Orchestration: All services (API, UI, Redis) are managed via ~/OSIT_dev/aether_container_env/docker-compose.yml.
  • Dockerfile: Multi-stage build. Stage 1 (builder) runs vite build --mode $BUILD_MODE using .env.$BUILD_MODE. Stage 2 (runtime) creates the final lightweight Node image.
  • Environment Handling:
    • PUBLIC_ variables are baked into the image at build time via the .env.<mode> file.
    • Private runtime variables are passed via the Docker Compose .env file in aether_container_env/.
  • Remote deploy: aether_container_env/deploy.sh handles git pull + Docker build + restart on the server. Triggered via npm run deploy:remote:*.

Client-Side Cache & IDB Version Management

The app uses Dexie (IndexedDB) as a local cache for API data (SWR pattern). To prevent stale cached records from persisting across deploys, two version-tracking systems exist in src/lib/stores/store_versions.ts:

localStorage store versions (AE_LOC_VERSION, etc.) Track the schema of persisted Svelte stores (ae_loc, ae_events_loc, etc.). Bump when a store's shape changes in a breaking way (field type change, required rename). The check runs synchronously at module import time, before any store hydrates.

IDB content versions (IDB_CONTENT_VERSIONS) Track the content shape of Dexie table rows — specifically what properties_to_save writes to each table. Bump when properties_to_save in an object file changes in a way that makes existing cached rows stale (fields added/removed/renamed, computed field behavior changed). The check_and_clear_idb_table() helper reads a localStorage key per table and clears the Dexie table on mismatch. Call it from the module's layout on mount.

When to bump IDB_CONTENT_VERSIONS: If you change properties_to_save in ae_events__event.ts (or any other object file), bump the matching entry here. Failure to do so has historically caused silent "no data" states that are extremely difficult to diagnose — stale rows pass silently, filter to zero, and the error looks identical to a genuinely empty result.

Currently wired: events.event (via src/routes/idaa/(idaa)/+layout.svelte). All other tables are defined but not yet wired — see the comment block in store_versions.ts.


Developing (Local HMR)

For the best developer experience with Hot Module Replacement (HMR), start a local development server on your host machine:

npm run dev

The local dev server will communicate with the FastAPI backend running in Docker (typically via dev-api.oneskyit.com). This gives you the speed of local Svelte development with the power of the full Aether stack.

Rebuild the node_modules directory and manually install extra Svelte packages

Run the npm update to fix the node_modules directory and package.json

npm list
npm outdated
npm update
npm outdated
npm list

Other installs?: Are both still needed? I know at least one of these is. 2024-07-23

npm install --save-dev svelte-highlight
npm install --save-dev typescript-svelte-plugin

Set up and run

Packages and dependencies

npm install --save-dev svelte-highlight typescript-svelte-plugin
npm install flowbite flowbite-svelte tailwind-merge @popperjs/core

I am slowly switching from Font-Awesome to Lucide

Tiptap Editor

Need to install ShadCN and Lucide for the Tiptap editor.

npm install shadcn-svelte
npm install lucide-svelte
npm install mode-watcher

Now we initialize the ShadCN and ShadEditor packages. Follow the command line instructions.

npx shadcn-svelte@next init
npx shadcn-svelte@next add dropdown-menu button tooltip input popover separator
npx shadeditor init

More packages related to the Tiptap editor???

npm install @tiptap/extension-link @tiptap/extension-bullet-list @tiptap/extension-history @tiptap/extension-typography @tiptap/extension-underline

Environment file

The application uses standard SvelteKit .env files for build-time configuration (specifically for PUBLIC_ prefixed variables).

  • .env.dev: Used by npm run build:docker:dev and npm run build:dev.
  • .env.test: Used by npm run build:docker:test and npm run build:test.
  • .env.prod: Used by npm run build:docker:prod and npm run build:prod.
  • .env.local: Used during local development (npm run dev).

Note: Runtime variables (like private API keys or DB credentials) are managed in the deployment directory's .env file and passed to the containers via Docker Compose.


Developing

Start a local development server:

npm run dev

# or start the server and open the app in a new browser tab
npm run dev -- --open

Deployment

# Build Docker image locally and restart container
npm run build:docker:dev
npm run build:docker:prod

# Deploy to remote server (linode.oneskyit.com)
npm run deploy:remote:test
npm run deploy:remote:prod

These commands use the multi-stage Dockerfile to build the app in a clean environment and automatically restart the corresponding Docker containers.

Description
No description provided
Readme 83 MiB
Languages
Svelte 75.7%
JavaScript 12.1%
HTML 7.5%
TypeScript 2.5%
CSS 2.2%