This question arises from some work @vasharma05 is doing on the frontend, specifically to be able to track patients that a user clicks on to keep them as part of the “recent results”. For 3.x, we’re modelling this similarly to what we do in 2.x, i.e., using a user property to track the recently viewed patients. However, when trying to update the user property, we end up losing the users session location.
Essentially, what seems to be happening is this: when the user is saved, the REST API calls a function called refreshAuthenticatedUserIfNeeded(), which refreshes the user session if the user being modified is the currently logged-in user. This makes sense because the user context stores some cached data about the user that might be changed.
However, the refreshAuthenticatedUser() as part of its logic calls setUserLocation() and this is the function I don’t understand, first, why it’s there and second, why it works the way it does.
setUserLocation() is straight-forward enough: if the user has a location set as their default location, the session location is set to the default location. Otherwise, the location is cleared. This change was added as part of TRUNK-1959 and, frankly, I don’'t really understand the reasoning. While it makes sense to ensure the user context has a fresh copy of the user, I don’t really understand why resetting the location like this is desirable behaviour. However, since this seems to have been in place for 12-ish years, it seemed to make sense to ask rather than just overwrite things.
To @vasharma05’s immediate issue, is there any real objection to adding a REST endpoint that would allow updating a user property without updating the full user?