[Alpha v19.0.8] Roster Block no longer allows you to force a specific location via URL

[leahjennings]

Description

We use iPads in classrooms for volunteers to manage rosters. Because our location tree is long and not just kids classrooms, we custom built a page that has a link to each classroom's roster, prefilling which location the roster was for based on the URL parameter (LocationId). The new roster block no longer allows this capability, forcing the person to navigate the location tree.

Actual Behavior

If you pass a LocationId in via the URL parameters, the roster block ignores it.

Expected Behavior

I would expect the new roster block to behave similarly to the old one in that you can force which location the block is for via the URL.

Steps to Reproduce

• On a Rock instance running v19, go to Settings > Locations
• Identify the Id of a location
• Navigate to the check-in manager roster page
• Edit the URL and append the parameter LocationId=####, where #### is the id you noted earlier
• Notice how the block does not update based on the parameter

Issue Confirmation

• Perform a search on the Github Issues to see if your bug is already reported.
• Reproduced the problem on a fresh install or on the demo site.

Rock Version

Rock McKinley 19.0 (19.0.8)

Client Culture Setting

en-US

[cabal95]

@leahjennings I believe this issue is caused by the custom Lava you have related to the other issue. I just tested this on pre-alpha (after removing your test lava), and ?LocationId=### worked correctly in the URL.

Please let me know if you can verify that to be the case and if it is safe to close this issue.

[leahjennings]

Thanks @cabal95! I removed that utility code, tested and can half confirm. If I pass that parameter while I am logged in (as someone in RSR - Rock Administration), then it does work and sets the block appropriately. However, if I use a different account (the one we use on the weekends), it does not set the block accordingly. I do not see any authorization errors in the console, so I don't think it's an API thing. And the account itself actually can manually set everything in the context menu without issue.

This is the context setter block security, and the user I am testing with is in RSR - Check-in Manager Access

If this leans more troubleshooting doesn't seem related to the bug, I'm happy to continue testing and/or taking the troubleshooting offline.

[cabal95]

@leahjennings That's rather weird to be sure. Thanks for the updated information, I'll work on testing with a new user/Person that has no permissions except access to these pages.

If you get to it, can you test two additional things:

1. Try testing without the rckipid in? Just in case that is somehow causing things to go wonky.
2. Try testing in an Incognito window to ensure no existing cookies or other browser state might be somehow force-overriding the selection. (I don't think this would be the case as that would probably leave you locked to a single location)

[leahjennings]

So I tried both, and got no different results. Here's some info to be aware of:

• I go to https://devdatabase.mynorthside.com/page/871?LocationId=51336 in a private window
• It requires you to login, so I enter the credentials
• The page loads, but no campus is selected, and no location
• I set the campus, and still no location
• I refresh the page so the campus is kept hoping that it loads the location from the parameter, but nothing

I also tested that same sequence in a regular browser window, with and without the rckipid, and same result.

[cabal95]

Hey @leahjennings Thanks for the details. I was able to track down why this was not working. The logic for the built-in "handles all requests" code that was handling locationId parameter was only kicking in if there was already a Location in entity context. So because a location had never been picked, the URL was not able to override anything.

I have added logic to the check-in context picker to specifically handle a locationId parameter and set the context appropriately.