Devops/update keycloak

[MikeNeilson]

Updates keycloak to a version that continuous to run in gh actions (weird, but not gonna worry about it as we should keep that up to date.

Also partially reverts a change made in #1586 that incorrectly sets the user session to the provided office id, which is intended purely as a search constraint.

[rma-bryson]

This gets called from getLocations(). Does this need to have the session office set?

[MikeNeilson]

If it does we have a design issue. getLocations is quite often called by "guests", even a non-guest should be able to search the entire database regardless of what their user office permissions are. The officeId parameter to getLocation is not a session related office, like it would be for say POST, but is instead just a limiter on the locations query that is run.

[rma-bryson]

Perhaps it isn't necessary here then. Makes me wonder where else the session office is being set but not needed.

[rma-rripken]

I did a quick search for places that set the session office id in GET type methods:
getLocation getLocations (this pr is about these)
retreiveLocationLevel
getRatingSet
retrieveLatestXML
getSpecifiedLevels
retrieveVerticalDatumInfo
getAllBasins getBasin
getStream getStreamLocations
getReachesOnStream
retrieveLockCatalog
retrieveLock
retrieveProject
catProject
retrieveStandardText

[MikeNeilson]

well, it appears @rma-bryson is correct, the vertical datum system requires that office id; however that is rather problematic as requiring the office id at this level breaks the basic functionality of you know, letting a user search though the data of the databases whether they're logged in or not.

[rma-rripken]

So its needed for vertical-datum conversion? Okay, but that only happens if the user adds the datum flag - right? Seems like we could shift the call to set the office in the session to inside just that branch and maybe add a comment on the datum flag that users need to be logged-in to use that feature or something like that.

[rma-bryson]

Wondering if we can replace the loc package call with a view query of the AV_VERT_DATUM_OFFSET?

[MikeNeilson]

Wondering if we can replace the loc package call with a view query of the AV_VERT_DATUM_OFFSET?

that might work.

So its needed for vertical-datum conversion? Okay, but that only happens if the user adds the datum flag - right? Seems like we could shift the call to set the office in the session to inside just that branch and maybe add a comment on the datum flag that users need to be logged-in to use that feature or something like that.

Doesn't really change the situation, if the user doesn't have permissions for that specific office for the datum, the set session office will still fail. Thus breaking the search in which we allow anyone to ask for the datum.

[rma-bryson]

#1594 - here's a view query update that works @MikeNeilson