{"id":"697ab4c74bcd26c09b04d5fe","title":"2026 01 29 Input Source And Event Population","path":"how-to/technical-articles/2026-01-29-input-source-and-event-population","contentMarkdown":"# 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)\n\n_____\n\nThis article explains the **InputSource** and **EventPopulation** enumerations, how they work together, and how their usage evolved through issues #110 and #119.\n\n## Overview\n\nNGX-Ramblers supports two main ways for groups to manage their walk and event data:\n\n1. **Local management** — Walks are created, imported, and maintained in the local database\n2. **Walks Manager sync** — Walks are synced from the Ramblers Walks Manager API to the local database\n\nTwo key enumerations control this behaviour:\n\n- **EventPopulation** — A group-level setting that determines how walks are sourced\n- **InputSource** — A per-event field that records how each event entered the system\n\n## EventPopulation (Group Configuration)\n\nThis setting is configured per-group in System Settings and determines how walks/events are sourced.\n\n### Before Issue #110\n\n| Value | Behaviour |\n|-------|-----------|\n| `LOCAL` | Walks created/imported locally, stored in local database |\n| `WALKS_MANAGER` | **Queried Ramblers API live for every request** — slow and lost local enrichments |\n| `HYBRID` | Blended local + live Ramblers data together |\n\n### After Issue #110\n\n| Value | Behaviour |\n|-------|-----------|\n| `LOCAL` | Unchanged — walks managed locally |\n| `WALKS_MANAGER` | **Syncs from Ramblers API to local database**, then queries locally — faster and preserves enrichments |\n| `HYBRID` | **Removed** — no longer needed as WALKS_MANAGER now syncs locally |\n\n### After Issue #119\n\n| Value | Behaviour |\n|-------|-----------|\n| `LOCAL` | Unchanged |\n| `WALKS_MANAGER` | **Queries local database only** — all API routing removed. Setting now only controls which sync job runs and UI display logic |\n\n## InputSource (Per-Event Metadata)\n\nThis field is stored on each event and records how that event entered the system.\n\n### Before Issue #110\n\n| Value | Meaning |\n|-------|---------|\n| `FILE_IMPORT` | Imported from a CSV file |\n| `WALKS_MANAGER_IMPORT` | Imported when switching from Walks Manager to Local population |\n| `URL_TO_ID_LOOKUP` | Minimal record linking SEO-friendly slug to Ramblers ID |\n| `MANUALLY_CREATED` | Created manually via the UI |\n| `UNKNOWN` | Legacy or unknown source |\n\n### After Issue #110\n\n| Value | Meaning |\n|-------|---------|\n| `FILE_IMPORT` | Unchanged |\n| `WALKS_MANAGER_IMPORT` | **Deprecated** — redundant with WALKS_MANAGER_CACHE |\n| `WALKS_MANAGER_CACHE` | **Added** — synced from Ramblers API to local cache |\n| `URL_TO_ID_LOOKUP` | **Removed** — no longer needed |\n| `MANUALLY_CREATED` | Unchanged |\n| `UNKNOWN` | Unchanged |\n\n### After Issue #119 (Current)\n\n| Value | Meaning |\n|-------|---------|\n| `FILE_IMPORT` | Imported from a CSV file |\n| `WALKS_MANAGER_CACHE` | Synced from Ramblers Walks Manager API |\n| `MANUALLY_CREATED` | Created manually via the UI |\n| `UNKNOWN` | Legacy or unknown source |\n\n## The Problem Solved by #110 and #119\n\n### Before #110\n\nGroups configured with `EventPopulation.WALKS_MANAGER` had a poor experience:\n\n- Every page view triggered a **live API call** to Ramblers\n- This was **slow** (network latency on every request)\n- Local enrichments were **lost** (edit history, custom fields, migration tracking)\n- The UI showed stale or incomplete data\n\n### After #110\n\nAll Walks Manager data is now **synced to the local database**:\n\n- A background sync job pulls data from the Ramblers API\n- Data is stored locally with `InputSource.WALKS_MANAGER_CACHE`\n- Queries are faster (local database)\n- Local enrichments are preserved\n\n**However**, some code still routed queries to the live API based on `EventPopulation`.\n\n### After #119\n\nAll routing logic was **removed**:\n\n- Every query goes to the local database regardless of `EventPopulation`\n- The `EventPopulation` setting now only controls:\n - Which sync job runs (Ramblers API sync vs manual entry)\n - UI display logic (e.g., showing \"Sync from Walks Manager\" button)\n\n## Current Valid Combinations\n\n| EventPopulation | InputSource Values | Meaning |\n|-----------------|-------------------|---------|\n| `LOCAL` | `FILE_IMPORT`, `MANUALLY_CREATED` | Group manages walks locally via CSV import or manual entry |\n| `WALKS_MANAGER` | `WALKS_MANAGER_CACHE`, `MANUALLY_CREATED` | Group syncs from Ramblers, can also create walks locally |\n\n## Technical Details\n\n### The Problematic Code (Before #119)\n\n```typescript\n// WalksAndEventsService - BEFORE\nasync queryById(walkId: string): Promise {\n switch (this?.group?.walkPopulation) {\n case EventPopulation.WALKS_MANAGER:\n // PROBLEM: Fetches from live API, losing local enrichments\n return this.ramblersWalksAndEventsService.queryById(walkId);\n case EventPopulation.LOCAL:\n return this.localWalksAndEventsService.queryById(walkId);\n }\n}\n```\n\n### The Fix (After #119)\n\n```typescript\n// WalksAndEventsService - AFTER\nasync queryById(walkId: string): Promise {\n // Always use local database\n return this.localWalksAndEventsService.queryById(walkId);\n}\n```\n\n### Why Local Data Matters\n\nThe local database contains enriched data that the Ramblers API doesn't provide:\n\n| Field | Local Database | Ramblers API |\n|-------|---------------|--------------|\n| `events` | Edit history with timestamps | Not available |\n| `migratedFromId` | Migration tracking | Not available |\n| `fields.venue` | Local venue details | Not available |\n| `fields.riskAssessment` | Risk assessment data | Not available |\n\nBy always querying locally, we preserve all this enriched data.\n\n## Related Issues\n\n- [#110](https://github.com/nbarrett/ngx-ramblers/issues/110) — Server-side pagination and caching implementation\n- [#119](https://github.com/nbarrett/ngx-ramblers/issues/119) — Cleanup: Consolidate WALKS_MANAGER_IMPORT to WALKS_MANAGER_CACHE and remove interactive API queries\n","contentHtml":"

29-Jan-2026 — Understanding InputSource and EventPopulation #110 #119

\n
\n

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

\n

Overview

\n

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

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

Two key enumerations control this behaviour:

\n\n

EventPopulation (Group Configuration)

\n

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

\n

Before Issue #110

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ValueBehaviour
LOCALWalks created/imported locally, stored in local database
WALKS_MANAGERQueried Ramblers API live for every request — slow and lost local enrichments
HYBRIDBlended local + live Ramblers data together
\n

After Issue #110

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ValueBehaviour
LOCALUnchanged — walks managed locally
WALKS_MANAGERSyncs from Ramblers API to local database, then queries locally — faster and preserves enrichments
HYBRIDRemoved — no longer needed as WALKS_MANAGER now syncs locally
\n

After Issue #119

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ValueBehaviour
LOCALUnchanged
WALKS_MANAGERQueries local database only — all API routing removed. Setting now only controls which sync job runs and UI display logic
\n

InputSource (Per-Event Metadata)

\n

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

\n

Before Issue #110

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ValueMeaning
FILE_IMPORTImported from a CSV file
WALKS_MANAGER_IMPORTImported when switching from Walks Manager to Local population
URL_TO_ID_LOOKUPMinimal record linking SEO-friendly slug to Ramblers ID
MANUALLY_CREATEDCreated manually via the UI
UNKNOWNLegacy or unknown source
\n

After Issue #110

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ValueMeaning
FILE_IMPORTUnchanged
WALKS_MANAGER_IMPORTDeprecated — redundant with WALKS_MANAGER_CACHE
WALKS_MANAGER_CACHEAdded — synced from Ramblers API to local cache
URL_TO_ID_LOOKUPRemoved — no longer needed
MANUALLY_CREATEDUnchanged
UNKNOWNUnchanged
\n

After Issue #119 (Current)

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ValueMeaning
FILE_IMPORTImported from a CSV file
WALKS_MANAGER_CACHESynced from Ramblers Walks Manager API
MANUALLY_CREATEDCreated manually via the UI
UNKNOWNLegacy or unknown source
\n

The Problem Solved by #110 and #119

\n

Before #110

\n

Groups configured with EventPopulation.WALKS_MANAGER had a poor experience:

\n\n

After #110

\n

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

\n\n

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

\n

After #119

\n

All routing logic was removed:

\n\n

Current Valid Combinations

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
EventPopulationInputSource ValuesMeaning
LOCALFILE_IMPORT, MANUALLY_CREATEDGroup manages walks locally via CSV import or manual entry
WALKS_MANAGERWALKS_MANAGER_CACHE, MANUALLY_CREATEDGroup syncs from Ramblers, can also create walks locally
\n

Technical Details

\n

The Problematic Code (Before #119)

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

The Fix (After #119)

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

Why Local Data Matters

\n

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

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
FieldLocal DatabaseRamblers API
eventsEdit history with timestampsNot available
migratedFromIdMigration trackingNot available
fields.venueLocal venue detailsNot available
fields.riskAssessmentRisk assessment dataNot available
\n

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

\n

Related Issues

\n\n"}