[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
settings.
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
--
Jon Jensen
End Point Corporation
https://www.endpoint.com/
More information about the interchange-users
mailing list