The menu that offered pages a kitchen could not open

The tester signed in as a kitchen. On our system that is a vendor grant on one venue inside a hall: the kitchen’s owner from their side of the counter, and not the hall’s owner. They opened the avatar menu at the top of the back office and found Staff & access and Business details listed, two pages that belong to the hall. They tapped one. Nothing happened. They tapped the other. Nothing happened. Both rows went in the report as broken, and from where they stood both were.

What the router was doing is the part worth writing down. A page the role may not open has no route, so the router fell through to its default, which is the dashboard. The tester was already on the dashboard. So a tap on a forbidden page was indistinguishable from a tap that did nothing. A silent fallback is a reasonable choice for a typed address that does not exist. It is the wrong choice for a button the screen itself drew.

Three rows, one rule

The menu rows are now filtered by the same rule the hub page uses to decide which tiles to draw, so a kitchen sees Venue settings, Language and Log out and nothing it cannot open. The dashboard’s task list had the same fault from a different angle: a task whose page the role cannot reach, or whose work is ours rather than the venue’s, sent you to the router’s silent default. It sends you to the full setup list instead, which is a page everybody can open and which says what the task is. And a page change now closes the panel, which was the third row on the same screen.

We drove it with a local kitchen account made for the purpose and deleted afterwards: three rows behind the avatar, none of them dead. The general rule is that a menu is a promise. Every entry on it must open something, and the way to keep that promise is to draw the menu from the same list the doors are hung on, not from a second list that has to be remembered.