2009-11-23 1 views
1

Есть ли способ показать локальные задачи пользователю, если у них нет необходимых разрешений? Сейчас кажется, что Drupal просто исключает их из кода страницы. Я хочу показать их, но с другим классом CSS.Как показать вкладки неактивной задачи в Drupal

Версия Drupal является 5,20

ответ

4

Несмотря на некоторые отличия в отношении создания локальных задач между Drupal 5 и 6, Mac прав, что логика игнорирует записи, недоступные для текущего пользователя, довольно глубоко встроена в функции menu.inc. Если вы хотите поискать себя, начните с theme_menu_local_tasks() и следуйте вызовам функций оттуда.

Если бы мне пришлось реализовать функцию, которую вы ищете, я бы предпочел не предлагать Macs беспорядок с настройками доступа к меню напрямую. Вместо этого я бы переопределил theme_menu_local_tasks() с пользовательской версией и дублировал логику поиска записей там. Первый запуск будет использовать первичные и вторичные ссылки, как и раньше, а второй будет делать то же самое, что и impersonating another user (вероятно, пользователь 1 в этом случае). Таким образом, я бы получил две версии локального разметки задачи, которые мне тогда нужно было как-то различить, чтобы найти те, которые не разрешены для текущего пользователя, поэтому нужен дополнительный класс CSS.

Обратите внимание, что это все равно будет несколько уродливым, поскольку menu_primary_local_tasks() и menu_secondary_local_tasks() возвращают уже тематические списки, поэтому сравнение должно будет работать над разметкой, возможно каким-то образом разыгрывая теги li. Поэтому стоит потратить некоторое время на то, чтобы попытаться сделать то же самое (выбор локальных задач как двух разных пользователей), но используя функции более низкого уровня, чтобы получить записи перед тем, как сделать это.

Примечание: Если вы в конечном итоге используете user impersonation logic, обязательно используйте безопасную вторую версию, которая отключает сохранение сеанса во время олицетворения.

+0

Спасибо, сделали именно это. Это сработало. Пользовательское олицетворение не было необходимым, но спасибо за ссылку в любом случае. –

+1

Мне тоже нравится этот подход. Самое большое преимущество, которое я вижу по сравнению с тем, которое я ранее предлагал, заключается в том, что эта шкала лучше масштабируется: поскольку разметка генерируется какой-то функцией «diff», а не путем выбора записи в меню по ее текстовому контенту, то быстрее применять это решение если количество меню, которое вам нужно настроить, повышено. Он также не полагается на js/jQuery, который (хотя поддерживается почти каждым браузером) является «зависимостью» больше, чтобы ваши страницы отображались правильно. – mac

3

Я знаю версию D6 из hook_menu намного лучше, чем D5-х. AFAIK - однако - вы не можете переопределить это поведение, поскольку оно жестко запрограммировано в menu.inc.

Если я правильно с тем, что выше, обходным путем (а безвкусным, я должен признать) может быть:

  1. Удалить контроль доступа из пункта меню, так что все пункты меню видны все пользователи.
  2. Включите контроль доступа непосредственно в обратном вызове (вы сразу же внесите вкладку, но если пользователь вставляет URL-адрес напрямую, это предотвратит доступ к страницам, которые они не должны видеть).
  3. На странице, отображающей вкладки, загружайте другой файл js в соответствии с тем, какие роли у пользователя есть. Файл js для пользователей с ограниченным доступом будет выбирать вкладки в зависимости от их текстового содержимого (по крайней мере, на вкладках D6 не получается «индивидуальный» класс: они получают только общую «вкладку»), она удаляет ссылку на вкладки, у пользователя нет разрешения на посещение, и он добавит пользовательский класс к тем вкладкам, которые должны отображаться по-разному.
  4. Добавьте CSS-тематику для своего пользовательского класса.

Как уже говорилось ранее, я не знаю, что такое D5, поэтому также может оказаться, что вы можете добиться того, чего хотите, гораздо более чистым способом!

+2

+1 - Я бы использовал другой подход (как предлагается в отдельном ответе), только для предотвращения необходимости добавления проверки доступа ко всем затронутым вызовам меню, что было бы громоздким для поддержания.Но эта версия является допустимым вариантом и может быть легче/более подходит для случаев с менее общей потребностью в настройке. –