Updating the user via REST loses the session location

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?

1 Like

This forces the client to first set the user’s default location property, to the selected session location, in order for it not to be cleared by setUserLocation. This is definitely a bug, which should be fixed by changing setUserLocation not to set this.locationId to null when the user’s default location property is blank.

1 Like

My inclination is to change things around so that the user’s default location is only chosen if there is no location associated with the user. Does that make sense or will that be too breaking?

1 Like

Your proposal makes more sense!

Agree. Maintaining the user’s current location (when present) makes intuitive sense.