[ic] Strange setting of form vars to values upon login

Jon Jensen jon at endpoint.com
Wed Jan 18 04:48:33 UTC 2017

On Tue, 17 Jan 2017, Josh Lavin wrote:

> I propose in UserDB.pm:
> -               if ($status = $user->login(%options) ) {
> -                       ::update_user();
> -               }
> +               $status = $user->login(%options);
> Basically, don't call update_user() when logging in. The update_user() 
> sub updates the values (this is exactly what the "return" action does; 
> snippet below).
> This behavior pre-dates source-control, so I don't know why it was 
> added, but it seems wrong -- why would we want a login form to save its 
> parameters to Values space, when you could get that by calling the 
> mv_action of "return"?

In the simple case, what you are saying makes sense to me.

However: I haven't traced through it completely, but the login method 
calls the get_values method which can load various user account values, 
which can end up in values space or scratch or both, depending on 
settings. So I think there is a possibility that without that update_user 
call, some things may not get set in values space from the user's account 

In other words, perhaps those form values getting copied over is just an 
accidental, and perhaps, as you suspect, unneeded, side-effect. But other 
values may be getting copied there besides what's in the form.

Since you say this logic predates version control it would be very helpful 
if Mike can weigh in, if he remembers the reason for it or knows of any 
code that depends on it. If he doesn't know, we should probably trace the 
behavior closely in the face of user account settings being loaded with 
various UserDB options and see how it behaves.


Jon Jensen
End Point Corporation

More information about the interchange-users mailing list