# 29-Jan-2026 — Understanding InputSource and EventPopulation [#110](https://github.com/nbarrett/ngx-ramblers/issues/110) [#119](https://github.com/nbarrett/ngx-ramblers/issues/119)

_____

This article explains the **InputSource** and **EventPopulation** enumerations, how they work together, and how their usage evolved through issues #110 and #119.

## Overview

NGX-Ramblers supports two main ways for groups to manage their walk and event data:

1. **Local management** — Walks are created, imported, and maintained in the local database
2. **Walks Manager sync** — Walks are synced from the Ramblers Walks Manager API to the local database

Two key enumerations control this behaviour:

- **EventPopulation** — A group-level setting that determines how walks are sourced
- **InputSource** — A per-event field that records how each event entered the system

## EventPopulation (Group Configuration)

This setting is configured per-group in System Settings and determines how walks/events are sourced.

### Before Issue #110

| Value | Behaviour |
|-------|-----------|
| `LOCAL` | Walks created/imported locally, stored in local database |
| `WALKS_MANAGER` | **Queried Ramblers API live for every request** — slow and lost local enrichments |
| `HYBRID` | Blended local + live Ramblers data together |

### After Issue #110

| Value | Behaviour |
|-------|-----------|
| `LOCAL` | Unchanged — walks managed locally |
| `WALKS_MANAGER` | **Syncs from Ramblers API to local database**, then queries locally — faster and preserves enrichments |
| `HYBRID` | **Removed** — no longer needed as WALKS_MANAGER now syncs locally |

### After Issue #119

| Value | Behaviour |
|-------|-----------|
| `LOCAL` | Unchanged |
| `WALKS_MANAGER` | **Queries local database only** — all API routing removed. Setting now only controls which sync job runs and UI display logic |

## InputSource (Per-Event Metadata)

This field is stored on each event and records how that event entered the system.

### Before Issue #110

| Value | Meaning |
|-------|---------|
| `FILE_IMPORT` | Imported from a CSV file |
| `WALKS_MANAGER_IMPORT` | Imported when switching from Walks Manager to Local population |
| `URL_TO_ID_LOOKUP` | Minimal record linking SEO-friendly slug to Ramblers ID |
| `MANUALLY_CREATED` | Created manually via the UI |
| `UNKNOWN` | Legacy or unknown source |

### After Issue #110

| Value | Meaning |
|-------|---------|
| `FILE_IMPORT` | Unchanged |
| `WALKS_MANAGER_IMPORT` | **Deprecated** — redundant with WALKS_MANAGER_CACHE |
| `WALKS_MANAGER_CACHE` | **Added** — synced from Ramblers API to local cache |
| `URL_TO_ID_LOOKUP` | **Removed** — no longer needed |
| `MANUALLY_CREATED` | Unchanged |
| `UNKNOWN` | Unchanged |

### After Issue #119 (Current)

| Value | Meaning |
|-------|---------|
| `FILE_IMPORT` | Imported from a CSV file |
| `WALKS_MANAGER_CACHE` | Synced from Ramblers Walks Manager API |
| `MANUALLY_CREATED` | Created manually via the UI |
| `UNKNOWN` | Legacy or unknown source |

## The Problem Solved by #110 and #119

### Before #110

Groups configured with `EventPopulation.WALKS_MANAGER` had a poor experience:

- Every page view triggered a **live API call** to Ramblers
- This was **slow** (network latency on every request)
- Local enrichments were **lost** (edit history, custom fields, migration tracking)
- The UI showed stale or incomplete data

### After #110

All Walks Manager data is now **synced to the local database**:

- A background sync job pulls data from the Ramblers API
- Data is stored locally with `InputSource.WALKS_MANAGER_CACHE`
- Queries are faster (local database)
- Local enrichments are preserved

**However**, some code still routed queries to the live API based on `EventPopulation`.

### After #119

All routing logic was **removed**:

- Every query goes to the local database regardless of `EventPopulation`
- The `EventPopulation` setting now only controls:
  - Which sync job runs (Ramblers API sync vs manual entry)
  - UI display logic (e.g., showing "Sync from Walks Manager" button)

## Current Valid Combinations

| EventPopulation | InputSource Values | Meaning |
|-----------------|-------------------|---------|
| `LOCAL` | `FILE_IMPORT`, `MANUALLY_CREATED` | Group manages walks locally via CSV import or manual entry |
| `WALKS_MANAGER` | `WALKS_MANAGER_CACHE`, `MANUALLY_CREATED` | Group syncs from Ramblers, can also create walks locally |

## Technical Details

### The Problematic Code (Before #119)

```typescript
// WalksAndEventsService - BEFORE
async queryById(walkId: string): Promise<ExtendedGroupEvent> {
  switch (this?.group?.walkPopulation) {
    case EventPopulation.WALKS_MANAGER:
      // PROBLEM: Fetches from live API, losing local enrichments
      return this.ramblersWalksAndEventsService.queryById(walkId);
    case EventPopulation.LOCAL:
      return this.localWalksAndEventsService.queryById(walkId);
  }
}
```

### The Fix (After #119)

```typescript
// WalksAndEventsService - AFTER
async queryById(walkId: string): Promise<ExtendedGroupEvent> {
  // Always use local database
  return this.localWalksAndEventsService.queryById(walkId);
}
```

### Why Local Data Matters

The local database contains enriched data that the Ramblers API doesn't provide:

| Field | Local Database | Ramblers API |
|-------|---------------|--------------|
| `events` | Edit history with timestamps | Not available |
| `migratedFromId` | Migration tracking | Not available |
| `fields.venue` | Local venue details | Not available |
| `fields.riskAssessment` | Risk assessment data | Not available |

By always querying locally, we preserve all this enriched data.

## Related Issues

- [#110](https://github.com/nbarrett/ngx-ramblers/issues/110) — Server-side pagination and caching implementation
- [#119](https://github.com/nbarrett/ngx-ramblers/issues/119) — Cleanup: Consolidate WALKS_MANAGER_IMPORT to WALKS_MANAGER_CACHE and remove interactive API queries