leihbackend

leih.lokal Karlsruhe management system. Succesor of LeihLokalVerwaltung. Built with PocketBase as a backend.

Run

Local

1. Download Pocketbase

wget https://github.com/pocketbase/pocketbase/releases/download/v0.34.0/pocketbase_0.34.0_linux_amd64.zip
unzip pocketbase*
rm CHANGELOG* LICENSE* *.zip

2. Create schema / run migrations

./pocketbase migrate

3. Run Pocketbase

./pocketbase serve

4. Create admin account at http://localhost:8090/_/ (if none existing yet).

Docker / Podman

# Option 1: pull official image
docker pull ghcr.io/leih-lokal/leihbackend:latest

# Option 2: Build own image
docker build -f Containerfile -t leihbackend:latest .

# Create persistent volume
docker volume create leihbackend_data

# Run the container
docker run -d \
    --name leihbackend \
    -p 8090:8090 \
    -v leihbackend_data:/pb/pb_data \
    -e DRY_MODE=false \
    leihbackend:latest

Configuration

Custom environment variables

• DRY_MODE: Run the app in dry mode, i.e. don't send any mail or delete anything. Default: true.
• IMPORT_MODE: Run the app in import mode, i.e. don't perform any sort of data validation or side effects when creating new records. Default: false.
• LOG_LEVEL: Log level to use for stdout (0 = INFO, 4 = WARN, 8 = ERROR). Default: 4.
• LL_INACTIVE_MONTHS: Number of months after which a customer is considered inactive and schduled for deletion. Default: 24.
• LL_DELETION_GRACE_PERIOD_DAYS: Number of days to wait until deletion customer after reminder mail was sent. Default: 7.
• LL_NO_WELCOME: Do not send welcome e-mails upon new customer registration. Default: false.
• LL_NO_DELETE_INACTIVE: Do not delete inactive customers automatically. Default: false.

API Endpoints

See Web APIs reference for documentation on what endpoints are available and how to use them (especially with regard to filtering, searching, etc.).

Custom routes

• GET /api/autocomplete/street (public)
• GET /api/reservation/cancel (public)
• GET /api/customer/csv (superusers only)
• GET /api/item/csv (superusers only)
• GET /api/rental/csv (superusers only)
• GET /api/reservation/csv (superusers only)
• POST /api/misc/emergency_closing (superusers only)

Authentication

For now, we'll only have superusers (see Authentication) (as primarily other internal services are meant to consume the APIs) as well as a few public endpoints (see below). In the future, we might actually want user accounts for our customers and thus define more elaborate API rules and filters then.

To call API endpoints (admin-only at the moment), an auth token needs to be passed, which can be created as shown in auth.http.

Authorization

Requirements

By default, all operations are superuser-only, despite the following exceptions.

Customers

No public access.

Items

• Public list and view access for items whose status is not deleted
• Field internal_note must be filtered

Rentals

No public access.

Reservations

• Public create access for new reservations
• Reservation cancellation endpoint /reservation/cancel is public (but requires the cancellation token, obviously)

Tests

Important

Test cases are currently implemented in a way such that depend on one another. That is, if one test fails, subsequent tests are likely to fail as well due to inconsistent state, because tests currently are responsible for properly cleaning up their own data. We should change tests to work indepdendently.

Requirements

• NodeJS
• sqlite3

Setup

cd tests && npm install --dev

Run

cd tests && bash run_tests.sh

Roadmap

For the long-term roadmap and future plans for out software setup, please refer to the wiki.

Developer Notes

Deletion

• Deletions from customers cascade to all entities referencing customers using a foreign key, i.e. deleting a customer will also remove all their rental objects.