?
Referenced as Pull Request for: # 9230
avatar zero-24
zero-24
29 Jan 2016

Steps to reproduce the issue

Install beta1
Update e.g. via "Install from URL" to beta2

You can reproduce the Problem also via "over install" beta2 on the updated version.

Expected result

Update without problems and without logout.

Actual result

Logout...

Problem

I know that we need to flush the session once but not on every update since now that makes no sense, thanks. :)

avatar zero-24 zero-24 - open - 29 Jan 2016
avatar zero-24
zero-24 - comment - 29 Jan 2016

oops wrong cat. Please fix it to "Updating". Thanks :smile:


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9014.

avatar brianteeman brianteeman - change - 29 Jan 2016
Category Unit Tests Updating
avatar brianteeman
brianteeman - comment - 29 Jan 2016

Updates from beta to beta are not supported.

Unless we know what version they are updating from dont we still need to do it? Someone might be updating from 3.2


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9014.

avatar zero-24
zero-24 - comment - 29 Jan 2016

Unless we know what version they are updating from dont we still need to do it? Someone might be updating from 3.2

There need to be better ways to fix that.
You can require to update to 3.4.8 (that fixes that issue) and than you show the 3.5.x updates.

Or something like "isSessionFixed" befor flush it.

But hey i don't need to explain to my clients that on every joomla update they get logged out on every site and need to log in again.

Updates from beta to beta are not supported.

This has nothing to do with a beta -> beta update :smile:

Lets say George released 3.5 stable and not beta2 --> same problem.

Update from 3.4.8 -> 3.5.0 should not require a logout and login.

I know the limitations on beta -> beta updates but it also shows problems that the stable release can have / got :smile: And I reported it here.

avatar Kubik-Rubik
Kubik-Rubik - comment - 29 Jan 2016

At the moment this is the only solution that fixes the session problem certainly. We have to get sure that the session is written / refreshed properly. This behavior can be changed in future, we'll think about it.

As this is a known, intentional issue, I will close this item for now.

avatar Kubik-Rubik Kubik-Rubik - change - 29 Jan 2016
Status New Closed
Closed_Date 0000-00-00 00:00:00 2016-01-29 08:57:00
Closed_By Kubik-Rubik
avatar Kubik-Rubik Kubik-Rubik - close - 29 Jan 2016
avatar Kubik-Rubik Kubik-Rubik - close - 29 Jan 2016
avatar mbabker
mbabker - comment - 29 Jan 2016

This needs to be re-opened. The starting version was a release AFTER the session data handling was changed. As presented the bug report is fully valid; if upgrading from < 3.4.8 to 3.5 the logout is expected to occur because of all the changes. But if upgrading from >= 3.4.8 to 3.5 (includes beta-to-beta upgrades, supported or otherwise), the session is at a state that this migration/logout should not be necessary.

avatar joomdonation
joomdonation - comment - 29 Jan 2016

I haven't looked at the code which handle Joomla update, but I think we should have a way to solve this issue. Couldn't we get the current version of the site which is running the update, then only force logout if we upgrade from older version than 3.4.8 ?

Could you send me the link to the code which force logout? I will try to find a way to fix it.

avatar brianteeman brianteeman - change - 29 Jan 2016
Status Closed New
Closed_Date 2016-01-29 08:57:00
Closed_By Kubik-Rubik
avatar brianteeman brianteeman - reopen - 29 Jan 2016
avatar brianteeman brianteeman - reopen - 29 Jan 2016
avatar mbabker
mbabker - comment - 29 Jan 2016

haven't looked at the code which handle Joomla update, but I think we should have a way to solve this issue. Couldn't we get the current version of the site which is running the update, then only force logout if we upgrade from older version than 3.4.8 ?

No, you cannot. The upgrade script (which is ultimately where this processing is happening) is first triggered after the filesystem is updated. At that point it sees the new version number. You could possibly make a change in the controllers or models to store the old version number in the user state, but that can't be relied on for this update because that code isn't out in production yet.

avatar joomdonation
joomdonation - comment - 29 Jan 2016

Yes. I was thinking about storing the old version number in session (or maybe even in a temp text file)... As I haven't looked at the code yet, so I will stop commenting for now. Someone fully understands the update process should be able to solve this issue.

avatar zero-24
zero-24 - comment - 19 Feb 2016

@wilsonge please add the 3.5.0 Release Blocker Label here :smile:

avatar wilsonge wilsonge - change - 19 Feb 2016
Labels Added: ?
avatar brianteeman
brianteeman - comment - 27 Feb 2016

Closing as we have a PR. please help test #9230

avatar brianteeman brianteeman - change - 27 Feb 2016
Status New Closed
Closed_Date 0000-00-00 00:00:00 2016-02-27 13:15:19
Closed_By brianteeman
avatar brianteeman brianteeman - close - 27 Feb 2016
avatar wilsonge wilsonge - close - 27 Feb 2016
avatar wilsonge wilsonge - change - 12 Mar 2016
Labels Removed: ?

Add a Comment

Login with GitHub to post a comment