{"id":"6a1e360cb07a4c1534ca3215","title":"2026 05 31 Issue 269","path":"how-to/committee/release-notes/2026-05-31-issue-269","contentMarkdown":"# 31-May-2026 — stop \"Add non- walk\" button appearing on non-walk events listings [ref #269](https://github.com/nbarrett/ngx-ramblers/issues/269)\n\n## [build 659](https://github.com/nbarrett/ngx-ramblers/actions/runs/26792597212) — [commit 7e2b189](https://github.com/nbarrett/ngx-ramblers/commit/7e2b189da82e5d291ded73ac26c6276424c5f377)\n\n_____\n\nThe member self-service walk-creation button added in #269 was showing on every\nevents listing rendered through the shared events header, including CMS\ndynamic-content pages such as a group's /social page, where adding a walk makes\nno sense.\n\nThe guard in WalkDisplayService.memberCanAddWalk() compared\nthis.urlService.area() === this.walksArea(), but walksArea() simply returns\nthis.urlService.area(), so the condition was area() === area() - always true and\nfiltering nothing. The button therefore appeared for any logged-in member who\nmet the walk-creation access level and whose group stores walks locally,\nregardless of which page or row was being shown.\n\nRather than repair the area comparison (there is no separate stored walks-page\narea to compare against - walksPage() and groupEventPage() both resolve from the\ncurrent URL too), the check now uses the row context already passed to the\nevents header. The button shows only when the events row being rendered is a\nwalks listing.\n\n- memberCanAddWalk(eventsData?: EventsData) now requires\neventsData.eventTypes to include RamblersEventType.GROUP_WALK, replacing the\ntautological area comparison\n- events-header.ts and events-full.ts pass eventsData into the call\n\nA social/group-event row (eventTypes [GROUP_EVENT]) no longer offers the walk\nbutton; a walks row (eventTypes [GROUP_WALK]) is unchanged. The walksArea()\npass-through in event-contact.service.ts is still used to build event router\nlinks, so it stays.\n\nAlso removes two unused declarations noticed in the touched files: the\nPageService injection in events-header.ts and the advancedCriteriaToSavedCriteria\nimport in events-full.ts.","contentHtml":"

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

\n

build 659 — commit 7e2b189

\n
\n

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

\n

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

\n

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

\n\n

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

\n

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

\n"}