4.1 Upgrader Permission

[PaleoCris]

Hello folks,

 I've been trying to figure this one out for about 12 hours now. We decided to go ahead and upgrade from 3.4 to 4.1 and I started that process last night. First, I took full back ups of everything and then I continued with the upgrade instructions in the documentation. Everything was going perfectly fine without a hitch until I ran into a message that a SQL query should be manually run because of the size of the specific table. That was done successfully, but doing so took so long that the security token expired and it prompted me to log back in. When I try to log back in now, I get a message that says: "You do not have permission to run the upgrader."

 I opened a support ticket just before 1AM, but it appears you don't get a lot of support even on critical issues on the weekends.  The site has been down now for about 12 hours and I'm worried I'm going to have to wait until Monday morning for any help from Invision with this...It's probably a long shot, but I figured I'd make this thread and see if any of you guys have any ideas on what to do next. Maybe it's something fairly simple and I just haven't thought of it. I was working with my hosting company for many hours. We restored the database to see if it was corrupted or something which didn't work....Then they actually fully restored the 3.4 version which brought the site back online. I uploaded all the files to the server just as I did before and still got the same error about not having permission, which is perplexing to say the least.

-Cris

[Adlago]

7 minutes ago, PaleoCris said:

 When I try to log back in now, I get a message that says: "You do not have permission to run the upgrader.

Try login an email address and password.

[PaleoCris]

Hello Adlago,

 Thanks for the reply. I'm getting this same message when I put that info in and hit "Login". I have tried both my account which has root admin permissions and I tried to get another admin to log in. We all get the same message.

-Cris

[AndyF]

The account you're using when you visit the upgrader, it does have its primary (main) group as an admin yes ?

IIRC 3.x would allow you to use a 'secondary group' admin (perhaps a mod as primary but with secondary admin group permissions) to run the upgrader but IPS4 needs the primary group to be admin.

[PaleoCris]

Andy,

 Yes, the primary member group for two of the account we tried is admin with full permissions.

-Cris

[Adlago]

Link to your sait?

[AndyF]

I think in this case it would be best to await a ticket reply then, especially as its 'mid upgrade' itself by the sounds of it.

Its difficult to say from here why its doing that its almost as though the account you're using does not have admin permissions. Do you know how to use phpmyadmin ?

A support tech will be able to take a look and advise on a course of action to rectify this.

A 'DIY' check would be to see what the admin group currently is set at in conf_global (check it rather than assume its still what default would be) and then examine the admin accounts via phpmyadmin to see if their primary group is this one. I'd not really recommend doing this unless you have a full backup *and* are 100% sure you know what you are doing. This is partly why I've not gone into major detail with this paragraph.

 

5 minutes ago, Adlago said:

Link to your sait?

It could be, I see what you are saying. I'd expect with a bad pass or suchlike it would throw a different error such as " The password you entered is incorrect " , the issue seems to stem from not having sufficient permission to run the upgrade itself, a bit like trying to use a regular member account to run it.

[PaleoCris]

I appreciate the replies. I pulled an all-nighter between working with the hosting company, restoring database backups, etc, so this has not been fun. :/

I checked conf_global and confirmed that the admin ID there is the same as what is listed in phpMyAdmin for my account. Strange stuff.

 

-Cris

[Adlago]

Check in your database table "core_admin_permission_rows"

In row_id=4; row_id_type = group;row_perm_cache=*;row_updated=0

 

[PaleoCris]

Hmmmmmm. When I clicked it, I got the following message: " MySQL returned an empty result set (i.e. zero rows). (Query took 0.0001 sec)"

 That definitely doesn't seem right, eh?

[Adlago]

Try this

Click INSERTION in menu above

Create row with values above that I gave.

It is possible to upgrade your leave.

[PaleoCris]

Well, I thought that was going to do it for sure... I believe I added everything correctly. 

row_id = 4 row_id_type = group row_perm_cache = * row_updated = 0
Still receiving the message about not having permission. The 4 is the same as my member group ID, too.

Thank you very much for taking the time to help out.

[TSP]

5 hours ago, PaleoCris said:

Well, I thought that was going to do it for sure... I believe I added everything correctly. 

row_id = 4 row_id_type = group row_perm_cache = * row_updated = 0
Still receiving the message about not having permission. The 4 is the same as my member group ID, too.

Thank you very much for taking the time to help out.

For that to work your primary user group for the account you're logging into needs to be in that group. Is it? Do a query against your members table: 

SELECT * FROM prefix_core_members WHERE email='youremail@address.com';

Look for the group_id columns in the result. 

And is that "4" the group ID that's defined as the admin group in conf_global.php too? It should be the number for the admin group on 3.4.

[PaleoCris]

1 hour ago, TSP said:

For that to work your primary user group for the account you're logging into needs to be in that group. Is it? Do a query against your members table: 

SELECT * FROM prefix_core_members WHERE email='youremail@address.com';

Look for the group_id columns in the result. 

And is that "4" the group ID that's defined as the admin group in conf_global.php too? It should be the number for the admin group on 3.4.

TSP,

 Thank you for taking the time to respond. In my conf_global.php file, the admin group ID is 4. Under the members table for my account, my nember group ID is also 4. That is my primary group, too...I'm definitely at a loss on this one.

 A few minutes after I posted this thread, Invision tech support replied to the ticket saying it was a tier II technical support issue and I'd have to wait for business hours on Monday. I will update this thread with the solution when they find it just in case anybody else happens to run into this. One interesting thing to note is that I have a full copy of the working datebase that allows me to log into the AdminCP on 3.4. After the upgrader permissions problem, we completely restored and the entire site was running on 3.4 normally. As soon as I uploaded the 4.1 files (a fresh download), it gives the permissions error....this is before any database modifications whatsoever. 

Site permissions work fine before the files are uploaded...and it gives the no permission message as soon as they are. Weird.

-Cris

[Adlago]

Download again file 4.1 from client area?

[TSP]

So you restored the database to 3.4, but you still have the table core_admin_permission_rows? (And probably other IPS 4-tables) In that case, that would be a problem. You should've done the restoration so any new tables after the restoration of your database to 3.4 also deleted any new tables that didn't exist when the backup was taken. 

Either way, IPS will be able to help you. It sounds like you hit the problem that interrupted the upgrade at a bad time. Probably before the upgrader hit the 4.1.6.1 mark. I see that the \IPS\Member\Setup-class always returns false, but that doesn't seem to be used at all however, but there might be some autoload-magic going on that I don't see that would cause it to be loaded when in Setup. 

Either way, since I'm unable to debug this myself, it's just all a bit of guesswork, so you'll have to wait for IPS on this one I think

[PaleoCris]

I'm sorry, I actually have ipf_core_admin_permission_rows. I assume that's just the 3.4 version of the same table...the names have just been dropped in 4.1. There are no 4.1 tables currently in the database. 

I don't know if you guys have ever experienced down time and had the flood of Facebook messages, emails, etc. of panicking members, but it's not fun. I'm glad it's approaching normal business hours so IPS can start working on this. Lesson learned....Never do major upgrades or anything else even slightly "risky" on a Friday evening/Saturday morning.

I linked this thread in the support ticket I have open. Maybe something in it will help IPS figure it out. Thanks for all the help TSP, Adlago and Andy. I'll post here when they let me know what the issue was.

-Cris

[PaleoCris]

I just wanted to let everybody know that IPS fixed the issue this morning, whatever it was. I didn't hear anything about what the problem was before it was finished and support ticket closed, but I don't care. I'm just glad to have everything working as it should and be running IPS4. 

 Thanks for the help guys!