Changes to the User Permissions Not saving.

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 ...

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...

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 ?

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

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

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.

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.

@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.

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!

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

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

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.