Standalone: running core upgrade through web UI logs you out on completion

The $session->reset(2) in CRM_Upgrade_Form::doCoreFinish logs the user out from the web UI at the end of a successful upgrade.

It's a bit disconcerting.

I wonder if on Standalone we can:

• bypass the session reset
• take a note of the logged in user, and create a new session and log them in after the reset

@totten any thoughts on how to handle this?

added comp:Standalone label

changed the description

Seems like it's not a problem for other CMSs because Civi's session doesn't include the login.

In that case, the expectation for session::reset has always been that the function does not log you out. I imagine the fix then is to modify the function so that it doesn't delete session variables related to login.

added sig:bug triaged labels

mentioned in issue #5576 (closed)

mentioned in issue #5797 (closed)

Yeah, it is a bit disconcerting.

The history of the call to reset the session is also a bit disconcerting. It's like watching a ball bobbing on an ocean wave.

Interesting fact: This has been around since v2.1.

And guess what happened in v2.2? They introduced a carve-out for Standalone! But of course, the ball bounces around as we refactor code; decide Standalone is bad; then refactor more; then decide Standalone is good; etc etc. So the history doesn't really give us clarity on why this might be needed.

To me, this line feels like a special-case of a more general tension about whether to reset session/form-state during an upgrade.

• The general arguments are like:
  • "Yes" ==> Form-controllers aren't maintained with version-portable storage-contracts. You won't realize that an upgrade has mucked-up the internals of form-state until much too late. Resetting is a valid precaution.
  • "No" ==> Form-resets are annoying, and they're unnecessary 99% of the time, and the annoyance is particularly big for people who apply patch-upgrades.
  • (The most recent/operative interpretation is #29610, which sides with "no".)
• The special-case may be a little different from code POV, but I think it's the same fundamentally:
  • If you do have a substantive break in form-state-storage, then you'd want to clear it for both the current-user and everyone else.
  • If you do not have a substantive break in form-state-storage, then you'd want to retain form-state for both the current-user and everyone else.

My personal hunch: the odds are 4:1 that we don't really need to call $session->reset(). But it's hard to be certain. Is a hunch good enough? Or do we look for some nuanced middle-ground?

Approaches:

1. Stop doing resets (for all UFs). Hope we're not missing something important.
2. Continue doing resets on most UFs -- but skip on Standalone. (Much like v2.2 did.) Hope this somehow makes sense.
3. Do a partial-reset (for all UFs). Keep some properties under $this->_session['CiviCRM'] like ufID, userID, authx.

A rendition of the third approach: https://github.com/civicrm/civicrm-core/pull/32402

mentioned in commit 6f6dd129

mentioned in commit 7176f792

changed milestone to %6.2.0

closed