# 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):

```bash
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:

```bash
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`:

```bash
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

```bash
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

1. The footer on every signed-in page reads
   `© 2026 Martinhal IT - Joao Vaz - Version 2.3`.
2. **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.
3. 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.
4. 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.