Open klonos opened 6 years ago
...another problem I am currently having while working in #3339 is that #states
visibility conditions do not work with rendered permissions matrices. So this has no effect:
$form['show_permissions'] = array(
'#type' => 'checkbox',
'#title' => t('Show permissions matrix'),
);
$form['permissions'] = some_function_to_build_the_permissions_matrix();
$form['permissions']['#access'] = user_access('administer permissions');
// Hide the permissions matrix if the "Show permissions matrix" option is disabled.
$form['permissions']['#states'] = array(
'visible' => array(
'input[name="show_permissions"]' => array('checked' => TRUE),
),
);
I am either doing something wrong, or this simply does not work.
...requesting this to be considered for 1.13
Describe your issue or idea
For some time now, we have started providing subsets of the permissions within various forms throughout the UI. Examples include:
the content type add/edit form under
/admin/structure/types/add
, and the content add/edit form/admin/structure/types/manage/[content_type]
(#900):the contact form settings
/admin/structure/contact/settings
(#3190):the taxonomy vocabularies settings
/admin/structure/taxonomy/tags/configure
(#38):The main permissions page under
/admin/config/people/permissions
is HUGE . So, being able to provide matrices of subsets of permissions where the user expects them to be is a big UX+, and I am sure that more and more admin pages for core and contrib will start using this over time.Actual behavior
Injecting those permission tables in forms is currently too much work. See:
https://github.com/backdrop/backdrop/pull/2258/files
https://github.com/backdrop/backdrop/pull/1209/files
https://github.com/backdrop/backdrop/pull/1207/files
Expected behavior
We should be able to do this: