Every time I go to Save User Permissions, the changes just disappear!
I set my preferred settings throughout my 5 or 6 roles and when I'm done I go to the bottom and Click 'Save Permissions'. A similar problem occurs with my Menus. Where when I set them and click Save the changes disappear
I need to know what I should do. This is a site that is due to release in 10 days!

I'm running on MySql ver. 5.0.51a
PHP MyAdmin ver. 5.2.6
Also I have many Modules. Many are dev's, but I've had zero problems with the permissions until today.
A quick solution would have many thanks.
-Jacob

Comments

ocforum’s picture

Now I get an Error that says: "Validation error, please try again. If this error persists, please contact the site administrator." Anyone have any ideas? I have checked the Logs and they only report errors from UR_access, so I disabled that and the Tribune and yet I still get an Error.

earnie’s picture

Category: bug » support
Status: Active » Postponed (maintainer needs more info)

Could this be a browser cache issue; make sure the browser is set to refresh the cache with each visit? Which browser are you using? I've yet to use version 6 but I wouldn't think a highly visible bug like this would persist this long.

earnie’s picture

One other thing. Check the apache log files. I'm thinking your mod_security module is preventing the update.

gauravkumar87’s picture

you most probably have multiple people working on the same install at the same time.. this seems to be a concurrency issue.. i've faced this before.. say for eg.. two people are updating blocks on admin/build/blocks they are bound to overwrite each others settings. The best way to verify this is check what settings are saved in the db, that way u'll get a clear picture of what's saved ( believe me this concurrency issue causes settings to be invisible even if they are present in the db).

I would suggest you clear your cache.. and have some concurrency control.. well thats another big issue in drupal ...

ocforum’s picture

so what gauravkumar87 is say is that If one or more of my Admins were also working it could cause this error, right? well, what about the same user logged in in a different browser? not actually changing the same thing but doing administrative tasks?

ocforum’s picture

Oh and I've been weaving back and forth between Safari(not fun), Firefox, and IE 7. Where would I check my apache logs? I'm on a shared server, not sure if that makes the difference, and this just recently became a problem. I've had the site running fine for about a week and a half.

earnie’s picture

Where would I check my apache logs?

That depends on where they've been configured. Usually in something like /etc/httpd/logs. Pay attention to modsec_audit.log. The control panels usually give you access to these files else you'll have to open a ticket with your host provider.

ocforum’s picture

does this have anything to do with SecFilterEngine Off you said that my mod_security may be causing the problem and in my hosts forum, people recommended turning that off. I'll go and check to see if i can't find it and if I don't I will try a ticket

gauravkumar87’s picture

low level db locking is one thing that drupal doesnt take care of ( well its more of a mysql thing) .. so any administrative tasks that write to the db on the same table could have caused this... and no the same user logged in different browsers doesnt matter.. lemme give u an example.. u have the same settings pages open in two browsers.. and u update and save something on one browser.. and on the second browser u change somethin else and save (without refreshing) .. u updates the stale copy soo changes will be overwriiten or atleast u will have unexpected results...

ocforum’s picture

Ok I understand what you mean, and I have narrowed the Permissions that can't be changed down to the tribune module, what i don't get is that i can set the View tribune permission but not the Post tribune Permission, and it still either gives an error and clears or gives no error and clears. earnie is recommending check my apache log but so far haven't gotten ahold of it. Others at my host are saying that changing SecFilterEngine Off will fix it. You say it could be low level blocking, is that still a possiblilty with info i gave you or not. If it is how can I tell and then how would i Fix it?

earnie’s picture

I see you've opened #299510: Errors when setting permissions for Tribune. which is what I would have told you to do. You could have just as easily moved this issue to the Tribune project. Either mark #299510: Errors when setting permissions for Tribune. as duplicate and move this one to the Tribune module or close this one.

ocforum’s picture

Project: Drupal core » Tribune
Version: 6.3 » 6.x-1.0
Component: user system » Miscellaneous

Ok now I'm in the right spot!

ocforum’s picture

Is there the module developer here that could help me?

SeeSchloss’s picture

hmm... yes I'm here (sorry I'm a bit busy these days, drupalcon and all) although I'm not sure I understand how this is related to my module ?

SeeSchloss’s picture

I've looked a bit and I don't understand how this could happens, for me it's either some weird configuration issue with the server, or a drupal bug. The module really doesn't do anything fancy with perms

earnie’s picture

i can set the View tribune permission but not the Post tribune Permission

@ocforum, by "View" did you mean "access tribune"? I agree with SeeSchloss but I don't think it is Drupal either which leaves an environment issue on your side.

ocforum’s picture

sorry for the delay, lost internet access, Yes by View Tribune I mean Access.
I have talked to my hosts and they say I can't see my apache logs.

earnie’s picture

Maybe time for a new host provider. See http://give-me-an-offer.com/recommended_drupal_hosts for a possible suggestion.

ocforum’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

Ok, thanks for your help!

Guzzi’s picture

Hi ocforum,

Im experiencing the same problem, but not with this module, since it is not installed :-). Nothing on the forum worked for me so far. Site development (commercial) is impossible now since I cannot move blocks around and cannot change permissions of modules.

Did you have any luck in fixing this problem and if yes, can you hint me in the right direction?

Thanks & greetings from The Netherlands

Guzzi’s picture

Project: Tribune » Drupal core
Version: 6.x-1.0 » 6.14
Component: Miscellaneous » update system
Status: Closed (fixed) » Active
earnie’s picture

Guzzi, open an new issue. You may reference this one.

Coornail’s picture

Project: Drupal core » Tribune
Version: 6.14 » 6.x-1.0
Component: update system » Miscellaneous
Status: Active » Closed (fixed)

If someone finds this issue again:

Check your error logs, if you see something like that:
... ALERT - configured POST variable limit exceeded - dropped variable '2[some permission here]' ...

Then your suhosin settings are too strict.
Edit the file that holds the suhosin settings (on debian it's /etc/php5/apache2/conf.d/suhosin.ini), and increase suhosin.post.max_vars.

kubrt’s picture

Thank you for this, it's exactly what I've been experiencing after enabling per CCK field access.

On my system, the suhosin configuration is under

/etc/php5/conf.d/suhosin.ini

and I had to change both

suhosin.post.max_vars = 1500
suhosin.request.max_vars = 1500

to make the permissions page work again.

bumathan’s picture

Thank you very much for sharing this fix :)

prodosh’s picture

Issue tags: +Suhosin, +permission, +OpenAtrium, +saving, +debian6

@kubrt @Coornail:
Many thanks for that.
I was having the same problem with an Open Atrium installation and changing the suhosin variables took care of that on a default Debian 6 (Squeeze) installation with PHP downgraded to 5.2.17 from the default 5.3 setup.

rolandu’s picture

I experienced the same problem (/admin/user/permissions wouldn't save) and it took me a long time to figure out a solution. Here is what I did... I am not an expert at server configuration, so this was quite difficult for me - some of these steps might seem obvious to you.

- Checked the database for errors
- Checked if the data is too large for the table (table "permission") - I found an old article somewhere saying that they ran out of space and had to change the field to "longtext" - it seems that that article referred to an old drupal version, as "longtext" is the default format in D6. So you should only run into this problem now if you have millions of permissions.

Next, I wanted to verify whether the problem was about the size of the form, as this is mentioned at several places. If you go to /admin/user/roles you can change permissions on a per role basis. This means a much smaller form will be created (i.e. it will have much fewer fields). I discovered that this worked, so the problem had to be about the number of fields the form has.

I opened the source of the page /admin/user/permissions and did a text search for type="checkbox", I discovered that the page has 3712 checkboxes (yes, I have lots of modules). So that's the number of fields that are submitted (at least I suspect that).

Problem was, I used a shared hosting provider and couldn't access the server config, so I had to figure out where to put which setting...

I applied this to Drupal's settings.php:
ini_set('pcre.backtrack_limit', 10000000);
ini_set('pcre.recursion_limit', 500000);

In the PHP 5 section of the .htaccess file I set these:
php_value max_input_vars 5000
php_value max_input_time 120
php_value suhosin.post.max_array_index_length 512
php_value suhosin.post.max_name_length 512
php_value suhosin.post.max_vars 5000
php_value suhosin.request.max_array_index_length 512
php_value suhosin.request.max_vars 5000

The first two lines are for PHP itself; the other are for the "suhosin" extension that has been mentioned before in this thread.

Before changing settings, you can check the current settings using phpinfo(); and be sure to make backups of your files before changing ;-)

This has worked for and I hope it helps someone else, however you might have a completely different problem.

Good luck!

kenianbei’s picture

A better solution that doesn't require modifying the .htaccess file is to install the filter_perm module:
https://drupal.org/project/filter_perms

Cyberflyer’s picture

Thanks! The Filter Permissions module solved the problem Drupal Commons (6) and CiviCRM 4.3.1.

robin_b’s picture

The suhosin did the trick as mentioned in #24. Note that the settings file was entirely in comments, so don't let that scare you away.