Platform Admin Area¶

The platform admin area is exclusively accessible to users with the platform role admin. It enables platform-wide management of all tenants and users — independent of the tenant-scoped tenant-admin role.

Prerequisites¶

• Platform role admin (distinct from the tenant-admin role)
• Access via /admin/platform (in full mode)

Distinction: Platform-Admin vs. Tenant-Admin¶

Tenant Management¶

In the Admin > Tenants section you can:

• View all platform tenants (name, slug, member count, creation date)
• Deactivate or delete individual tenants
• View tenant quotas and limits
• Manage a tenant's members on their behalf

User Management¶

In the Admin > Users section you can:

• View all user accounts on the platform
• Lock or deactivate user accounts
• Assign platform roles (admin, viewer)
• Trigger password resets for users
• Process GDPR requests (data deletion, data access)

Statistics¶

The Admin > Statistics section provides an overview of:

• Number of active tenants and users
• Active planting runs platform-wide
• Celery task queue status
• Storage usage (ArangoDB, TimescaleDB, Redis)

OIDC Providers¶

Under Admin > OIDC Providers you configure federated authentication providers (e.g. Google, GitHub, corporate OIDC instances). These settings apply platform-wide to all tenants.

See Authentication for details.

Enabling Plant Photo Identification¶

Photo identification is an optional feature that requires API credentials from a third-party service. As long as no key is configured, the backend reports available: false and the entire camera/upload UI remains hidden for all users.

The Pl@ntNet API key is an instance-wide setting — a single key applies to all users of the instance. The free tier allows 500 identifications per day across the entire instance.

Step 1: Obtain a free Pl@ntNet key¶

1. Open my.plantnet.org in a browser
2. Create an account or sign in
3. Navigate to Account > API key
4. Copy the displayed API key

Step 2: Enter the key via the Admin UI (recommended)¶

This is the preferred method — no pod restart required, no file changes, takes effect immediately.

1. Sign in as a platform admin
2. Open Account Settings (click your profile picture in the top right)
3. Select the Integrations tab
4. Scroll to the Plant Identification section
5. Enter the copied API key in the Pl@ntNet API Key field
6. Click Save

The key is stored in masked form — it is never visible in plain text in API responses or logs. The field indicates whether the key is sourced from the database (UI entry), from an environment variable, or is not set at all.

Optional: Test the key immediately

After saving, click Test Connection. The backend sends a test request to Pl@ntNet and reports whether the key is valid and how many requests remain for today.

Optional: Remove the key

Click Remove to delete the database-stored key. If no environment variable is set either, photo identification is deactivated immediately.

Alternative: Set the key as an environment variable¶

The environment variable PLANTNET_API_KEY remains fully supported — it is suitable for automated deployments, GitOps workflows, or when UI access is not used.

kubectl create secret generic kamerplanter-secrets \
  --from-literal=PLANTNET_API_KEY="your-api-key" \
  --namespace kamerplanter

# helm/kamerplanter/values.yaml (excerpt)
backend:
  envFrom:
    - secretRef:
        name: kamerplanter-secrets

# helm/kamerplanter/values.yaml (local only, do not commit)
backend:
  env:
    PLANTNET_API_KEY: "your-api-key"

# .env (do not commit)
PLANTNET_API_KEY=your-api-key

docker compose up -d

Step 3: Verify activation via API¶

Call the status endpoint:

curl -s http://localhost:8000/api/v1/recognition/status | python3 -m json.tool

Expected response when the key is correctly set:

{
  "available": true,
  "adapter": "plantnet",
  "daily_limit": 500,
  "remaining_today": 498
}

After successful configuration, the camera/upload function and the Add by Photo button in the species overview appear automatically in the UI. Users see the consent dialog the first time they use the feature — from that point on it is fully functional.

Optional fine-tuning¶

The following variables do not usually need to be changed. They have sensible default values. A full description is available in the Environment Variables reference:

Privacy note¶

Photos are not stored on the Kamerplanter server — they are transmitted to Pl@ntNet (CIRAD/INRIA, France/EU) for analysis only and discarded immediately afterwards. EXIF metadata (GPS, camera model) is stripped before transmission. Each user must consent to image transfer once. Full details: Privacy (GDPR) — Photo Identification.

Enabling Pest Detection¶

Pest detection is disabled by default (PEST_DETECTION_ENABLED=false). As long as no adapter is configured, the backend reports adapter: null and the "Check for Pests" button remains hidden for all users.

Adapter 1: Local symptom adapter (self-hosted, recommended)¶

The local adapter detects damage patterns and symptoms (webbing, honeydew, suction damage) directly on the instance — no third-party service, no privacy consent required from users.

Enable via environment variables:

PEST_DETECTION_ENABLED=true
PEST_DETECTION_SYMPTOM_ENABLED=true
PEST_DETECTION_PRIMARY_ADAPTER=local_pest_symptom

kubectl create secret generic kamerplanter-secrets \
  --from-literal=PEST_DETECTION_ENABLED="true" \
  --from-literal=PEST_DETECTION_SYMPTOM_ENABLED="true" \
  --from-literal=PEST_DETECTION_PRIMARY_ADAPTER="local_pest_symptom" \
  --namespace kamerplanter

# helm/kamerplanter/values.yaml (excerpt)
backend:
  envFrom:
    - secretRef:
        name: kamerplanter-secrets

# .env (do not commit)
PEST_DETECTION_ENABLED=true
PEST_DETECTION_SYMPTOM_ENABLED=true
PEST_DETECTION_PRIMARY_ADAPTER=local_pest_symptom

docker compose up -d

# helm/kamerplanter/values.yaml (local only, do not commit)
backend:
  env:
    PEST_DETECTION_ENABLED: "true"
    PEST_DETECTION_SYMPTOM_ENABLED: "true"
    PEST_DETECTION_PRIMARY_ADAPTER: "local_pest_symptom"

Adapter 2: Cloud detection (Kindwise — optional, requires consent)¶

The Kindwise cloud adapter transmits photos to the Kindwise service (Brno, Czech Republic — EU) for analysis. It is disabled by default and requires explicit user consent (consent purpose pest_detection_cloud).

Enable via environment variables:

PEST_DETECTION_ENABLED=true
PEST_DETECTION_CLOUD_ENABLED=true
PEST_DETECTION_CLOUD_API_KEY=your-kindwise-api-key
PEST_DETECTION_PRIMARY_ADAPTER=local_pest_symptom   # local remains default; cloud selectable as fallback or primary

The button appears automatically in the UI after the next backend restart. Users who want to use the cloud adapter are prompted for consent on first use.

Checking the status¶

Call the status endpoint (tenant-scoped, JWT required):

curl -H "Authorization: Bearer <JWT>" \
  http://localhost:8000/api/v1/t/{tenant_slug}/pests/status | python3 -m json.tool

Expected response when an adapter is active:

{
  "adapter": "local_pest_symptom",
  "pest_detection_enabled": true,
  "symptom_enabled": true,
  "detector_enabled": false,
  "cloud_enabled": false
}

If pest_detection_enabled: false or adapter: null, the button remains hidden in the UI.

Optional fine-tuning¶

The following variables do not usually need to be changed. A full description is available in the Environment Variables reference:

Privacy note¶

• Local adapter: Photos do not leave the instance; no consent required; EXIF is removed before any processing.
• Cloud adapter: Photos are sent to Kindwise (EU); users must consent once for the purpose pest_detection_cloud; DPA contractually required; EXIF stripped twice (frontend + backend).
• Photos are never stored permanently — only the detection result and an anonymous image hash are retained.

See Privacy (GDPR) for details.

Curating Reference Images for Plant Identification¶

The self-hosted plant identification (DINOv2) compares user photos against a stored reference index. If that index contains blurry, misidentified, or otherwise unsuitable images, recognition accuracy for the affected species deteriorates.

As a platform admin you can deselect individual reference images after a visual inspection — they are then excluded from recognition but remain in the system (soft delete, reactivatable at any time). The full guide including the coverage threshold (< 5 active images), API endpoints, and FAQ is available at:

Curating Reference Images

Approving user pest photos (moderation)¶

On the pest detail page, users can contribute their own photos for a pest. These images are private at first (visible only to that user's garden/tenant). As a platform admin you can promote especially good shots to be globally visible.

Moderation lives in the admin area, in the "Contributed pest images" card:

1. Select the pest in question.
2. You see all contributed images across all tenants with a preview, provenance (user/tenant/date) and status (private/global).
3. Promote sets an image to global — it then appears in the gallery for all users (served through a global, read-only delivery path that exposes promoted images only). Demote reverts it (with confirmation).

Frequently Asked Questions¶

See Also¶

• Tenants & Gardens — Tenant management as tenant-admin (REQ-024)
• Privacy (GDPR) — Data subject rights and GDPR compliance
• Authentication — JWT, OAuth2/OIDC, service accounts
• Identify Plant by Photo — End-user guide
• Environment Variables — Full variable reference