9 replies to this topic

[mikef]

I upgraded a site from version unknown (probably 0.6.1) to 1.1 when I moved hosts. I had cause to edit a chunk for the first time today and can't do so - I get an error message "You don't have enough privileges for this action!" if I attempt to edit an existing chunk, or create a new one.
I can edit templates and snippets, and can create a new administrator user, who still has the same problem.

I've fixed the issue I was trying to fix by editting the templates to use a snippet rather than a chunk, and creating a new snippet that returns the corrected content, but would like to fix this properly.

Any ideas for what to check?

[Dean]

Yeah, I've seen some other people have the same problem... but I don't know why it happens for some people and not others.

Go into the database (phpMyAdmin) and modify the permission manually...

[Ralph]

All admins should have their chunk permissions modified during the upgrade... They may need to logout and back in before the changes take effect, however, because user permissions are stored in the manager session...

[mikef]

Ralph, on Mar 20 2009, 10:28 PM, said:

All admins should have their chunk permissions modified during the upgrade... They may need to logout and back in before the changes take effect, however, because user permissions are stored in the manager session...

Well, this admin has logged out and back in several times since the upgrade (late last year ...) This is just the first time i've tried to change a chunk. The PC has been rebooted lots of times too. This also wouldn't explain why a new admin created today wouldn't have the permissions correct to start with. I've also checked with a second browser (google Chrome) which I've not used for this purpose before, as far as I can remember - same result.

[mikef]

Having seen PaulD's related post I've had a look at the database and the permissions table isn't updated, although the content and logging tables are. Weird!

I'll back everything up and update the permissions table using phpmyadmin (to see if it gives some odd response) tomorrow. (I don't always make my best decisions at midnight!)

(I'll also check the other sites I've updated to 1.1 to see if they've updated correctly.)

Edited by mikef, 20 March 2009 - 11:57 PM.

[Ralph]

You can run the update script in the installer/upgrader again without causing any problems... Worth a shot... If the fields aren't there they won't get added for new admin's...

[mikef]

Ralph, on Mar 21 2009, 01:23 AM, said:

You can run the update script in the installer/upgrader again without causing any problems... Worth a shot... If the fields aren't there they won't get added for new admin's...

Thanks Ralph ... I'd read through the script and it looked safe to rerun.
There'll be a delay, though, while I try to figure out some other problems.

[Ralph]

mikef, on Mar 21 2009, 05:21 AM, said:

Thanks Ralph ... I'd read through the script and it looked safe to rerun.
There'll be a delay, though, while I try to figure out some other problems.

The script is definitely safe... It was tested extensively on every release of Etomite before it was included in the code base... There is virtually zero possibility of problems resulting form multiple executons of the script as it was run many times while it was being written on various combinations of data sets... It was just one part of trying to make upgrades smoother and has proven more successful than I had originally imagined... In fact, I just ran it on one of my installs last night that I had manually upgraded and found that my config.inc.php wasn't fully upgraded yet...

[mikef]

Sorry Ralph - I wasn't meaning to raise doubts about what you'd said, just saying I'd looked and already come to that conclusion.

[Cris D.]

Just let you know that I just upgraded a site from 0.6.1.4 to 1.1 and ran accross this same issue. After reading this thread (and Paul's realated one) I re-uploaded the install files and re-ran the dbpatches file, logged back out and back into the manager: and now it's working fine! What's weird is I checked the database tables first and couldn't see any missing columns or default values that would cause this. Also I got all green lights when I ran the patches script intially. Very strange indeed. Anyway - all working now