31-May-2026 — stop "Add non- walk" button appearing on non-walk events listings ref #269

build 659 — commit 7e2b189

The member self-service walk-creation button added in #269 was showing on every events listing rendered through the shared events header, including CMS dynamic-content pages such as a group's /social page, where adding a walk makes no sense.

The guard in WalkDisplayService.memberCanAddWalk() compared this.urlService.area() === this.walksArea(), but walksArea() simply returns this.urlService.area(), so the condition was area() === area() - always true and filtering nothing. The button therefore appeared for any logged-in member who met the walk-creation access level and whose group stores walks locally, regardless of which page or row was being shown.

Rather than repair the area comparison (there is no separate stored walks-page area to compare against - walksPage() and groupEventPage() both resolve from the current URL too), the check now uses the row context already passed to the events header. The button shows only when the events row being rendered is a walks listing.

• memberCanAddWalk(eventsData?: EventsData) now requires eventsData.eventTypes to include RamblersEventType.GROUP_WALK, replacing the tautological area comparison
• events-header.ts and events-full.ts pass eventsData into the call

A social/group-event row (eventTypes [GROUP_EVENT]) no longer offers the walk button; a walks row (eventTypes [GROUP_WALK]) is unchanged. The walksArea() pass-through in event-contact.service.ts is still used to build event router links, so it stays.

Also removes two unused declarations noticed in the touched files: the PageService injection in events-header.ts and the advancedCriteriaToSavedCriteria import in events-full.ts.