我自己亲自做的:  如果权限太多.超过了最大字节数范围...那么点 保存权限 时

下面就是post当前的路径无法执行到user_ admin_ permissions_ submit 函数,也就无法进行302跳转

 /admin/people/permissions/3  是修改管理员角色的权限

/admin/people/permissions/2  是修改普通注册用户角色的权限

管理员角色（rid=3）拥有所有权限（包括 administer permissions）。

关于 /admin/people/permissions/3 不执行 user_admin_permissions_submit 方法的问题，这通常与 Drupal 核心对管理员角色的特殊处理有关，而非某个特定权限导致。以下是具体原因和解决方案：

根本原因

1. Drupal 设计逻辑

• 管理员角色 (rid=3) 在 Drupal 7 中有特殊硬编码处理，默认拥有所有权限，即使界面显示未选中。

• 系统会忽略对管理员角色的权限修改，这是为了防止管理员意外锁定自己。

• 核心文件 user.module 中的 user_role_grant_permissions() 函数会强制跳过管理员角色的权限检查。

• 提交处理函数 user_admin_permissions_submit() 会排除管理员角色的权限更新。

关键证据

在你的SQL数据中：

sql
(3, 'administer permissions', 'user')  -- 管理员拥有权限管理的权限

但即使删除这条记录，管理员仍会保留该权限，因为 Drupal 核心逻辑强制赋予。

解决方案

1. 最佳实践
   不要依赖默认管理员角色，创建一个新角色（如 "Site Admin"）并分配所需权限，然后使用这个角色代替 rid=3。

2. 强制修改（不推荐）
   如果想强行修改管理员权限，需要以下步骤：

   php
   // 在自定义模块中实现 hook_form_alter()
   function YOURMODULE_form_alter(&$form, &$form_state, $form_id) {
     if ($form_id == 'user_admin_permissions') {
       // 移除对管理员角色的特殊处理
       unset($form['role_names'][3]['#disabled']);
     }
   }

   同时需要手动修改数据库，并清除缓存。

3. 验证方法
   直接测试非管理员角色（如 rid=2）的权限修改是否正常，如果正常则确认是 Drupal 对 rid=3 的特殊逻辑导致。

结论

这不是某个特定权限导致的，而是 Drupal 7 的核心设计机制。要精细控制权限，建议避免使用默认管理员角色（rid=3），而是创建并使用自定义管理角色。