Upgrading an existing installation to Infosec v2.3

This release is a drop-in code update: it changes only application code and static assets. There are no database schema changes, no data migrations, and no new dependencies. Upgrading in place keeps every user, folder, file, access request, approval, audit log, email/mail-log entry, brand image, and version entry exactly as it was.

What changed in 2.3

New "Calendar View" page. Added to the left menu next to View Data and available to every signed-in user. It shows a month-by-month calendar that highlights the days which have events — an event being a folder's Incident Date — with a per-day count. Clicking a highlighted day lists those folders with their incident date, Legal Validity, and access state. The page reuses the existing, access-filtered /api/data/tree endpoint, so users only see the events they are allowed to see and administrators see all of them.
Footer version bumped to © 2026 Martinhal IT - Joao Vaz - Version 2.3.

The calendar stores nothing of its own: it is derived entirely from folders that already exist. No new database tables or columns are introduced and no existing rows are touched. The startup routine only ever runs CREATE TABLE IF NOT EXISTS and non-destructive ALTER TABLE ADD COLUMN steps, so starting the new build against your existing database is safe and idempotent.

Before you start (recommended)

Take a quick backup. It only takes a moment and makes the upgrade risk-free.

Docker: the data lives in named volumes, so back them up (or simply snapshot your host/VM):

docker run --rm \
  -v datahub-data:/d/data -v datahub-uploads:/d/uploads \
  -v datahub-brand:/d/brand -v datahub-avatars:/d/avatars \
  -v "$PWD":/backup alpine \
  tar czf /backup/infosec-backup-$(date +%F).tar.gz -C /d .

Plain (non-Docker): back up the persisted folders and your environment file:

tar czf infosec-backup-$(date +%F).tar.gz data uploads avatars brand .env

Your live data is confined to those locations:

data/ — the SQLite database (datahub.db)
uploads/ — uploaded files AND files produced by Data Creation
avatars/ — per-user profile pictures
brand/ — brand images used in emails
.env — your configuration (Docker users: your compose environment / .env)

The new archive ships these folders empty (placeholder .gitkeep only), so overlaying the new build never overwrites your data.

Docker upgrade

Run from the directory that contains your docker-compose.yml:

docker compose down                            # keeps volumes (never use -v)

# extract the archive's CONTENTS into this directory
unzip -o ../infosec-v2.3.zip -d /tmp/infosec-new
cp -a /tmp/infosec-new/infosec/. .

# re-apply anything you had customised in compose, then rebuild
docker compose up -d --build
docker compose logs -f

The named volumes (datahub-data, datahub-uploads, datahub-brand, datahub-avatars) are not recreated by a rebuild, so all data carries over. Do not run docker compose down -v — that deletes the volumes.

Plain (non-Docker) upgrade

cd /path/to/your/existing/install
# stop the running server first (Ctrl-C, or systemctl stop <your-unit>)

unzip -o ../infosec-v2.3.zip -d /tmp/infosec-new
cp -a /tmp/infosec-new/infosec/. .

npm install          # optional: no new dependencies in 2.3, but harmless
node init-db.js      # safe to run: creates nothing new, changes no data
node server.js       # or restart your service / process manager

cp -a copies the new code over your install without deleting your data/, uploads/, avatars/, or brand/ contents, and without touching your .env.

Verify after upgrading

Calendar View appears in the left menu, just below View Data, for all users. Open it: days that have folders with an Incident Date are highlighted and show a count; clicking one lists those folders.
A folder's incident day lands on the correct calendar date, and a non-admin only sees days for folders they are allowed to see.
Confirm all your pre-existing folders, files, users, and version entries are still present and unchanged.

Rollback

If you need to revert, restore the backup you took above and redeploy the previous build. Because 2.3 makes no schema changes, the older code runs against the current database without any conversion.

4.5 KiB Raw Blame History