# 31-May-2026 — stop "Add non-<day> walk" button appearing on non-walk events listings [ref #269](https://github.com/nbarrett/ngx-ramblers/issues/269)

## [build 659](https://github.com/nbarrett/ngx-ramblers/actions/runs/26792597212) — [commit 7e2b189](https://github.com/nbarrett/ngx-ramblers/commit/7e2b189da82e5d291ded73ac26c6276424c5f377)

_____

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.