fix: expand actively_monitored_wells to include wells from all groups(BDMS-974/1178)

[likithabommasani21]

BDMS-974/1178: Expand actively_monitored_wells to include wells from all groups

Why

• actively_monitored_wells filtered wells with WHERE lower(trim(g.name)) = 'water level network' — a string match on a group's display name, restricting the layer to one group even though its name implies all actively monitored wells.
• If that group were ever renamed, the filter would stop matching and the layer would silently return zero rows with no error (Section 4.3, R3).
• A separate proposal to rename this layer to water_level_network_wells was withdrawn — the name was fine, the filter was just too narrow.

How

• New Alembic migration (986e0eb85ab3) drops and recreates both ogc_actively_monitored_wells and its internal mirror ogc_internal_actively_monitored_wells, removing the group-name predicate. The status_value = 'Currently monitored' filter is untouched — that's the real definition of "actively monitored."
• Verified against production data first: confirmed via a real query that no currently-monitored well has zero group memberships, so the existing inner-join structure is safe as-is (no need to switch to a LEFT JOIN).
• Wells belonging to multiple groups intentionally appear once per group (no aggregation) — a deliberate, agreed tradeoff, not an oversight.
• Added a test (test_ogc_actively_monitored_wells_includes_wells_from_other_groups) proving a well in a group other than Water Level Network now shows up.
• Rewrote the A4/A6 scenarios in ogc-cleanup-sprint1.feature, dropping the old rename/deprecation-header scenarios and the stale hardcoded "322" feature-count assertion (never matched real data in any environment we checked).

Notes

• Found and separately flagged (not fixed here): a duplicate group row in prod, "water Level Network" (lowercase w) vs "Water Level Network", holding one stray well (WL-0428). Worth a data-cleanup follow-up.

[github-actions]

Coverage

✅ 79.19% total — gate is 75%.

No measured coverage for the Python files changed here.

[Copilot]

Pull request overview

Expands actively monitored well OGC views to include wells from all groups while retaining the current monitoring filter.

Changes:

• Recreates public and internal views without the group-name restriction.
• Adds coverage for wells in other groups.
• Updates related OGC cleanup scenarios.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Summary
tests/test_ogc.py	Adds regression coverage for wells in non-default groups.
tests/features/ogc-cleanup-sprint1.feature	Updates A4/A6 OGC scenarios and removes stale assertions.
alembic/versions/986e0eb85ab3_expand_actively_monitored_wells_to_all_.py	Requires a public group-release filter (critical, 3 votes), coverage for the internal mirror (moderate, 2 votes), and unique feature IDs for per-group rows (critical, 1 vote).

Suppressed comments (1)

tests/test_ogc.py:597

• This migration changes both the public and internal views, but the new regression test only queries ogc_actively_monitored_wells. A regression in _create_internal_actively_monitored_wells_view() would still pass, leaving /ogcapi-internal with the old group-name restriction; run the same assertion against both relations (or exercise the internal endpoint) so both changed definitions are covered.

        row = session.execute(
            text(
                "SELECT group_id, group_name, group_type "
                "FROM ogc_actively_monitored_wells WHERE id = :thing_id"
            ),

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[likithabommasani21]

Fixed

[likithabommasani21]

@jirhiker and @ksmuczynski
Copilot flagged that a well in multiple groups now produces duplicate rows sharing the same id, breaking /items/{id} lookups (verified live — it silently returns just one group, no error, not even deterministic). Need a decision on the fix:

• Aggregate: one row per well, group info becomes arrays (group_names: [...]) instead of single values. Keeps id meaning "the well" everywhere, consistent with every other collection in this API.
• Composite ID: keep one row per (well, group), but make composite id of well and group. Keeps per-group rows, but id would no longer match the well's real id the way it does in water_wells/water_well_summary today.