Для построения сайта, в котором в основном приходиться работать с пользователями, а не с материалами сайта, необходима гибкая система управления пользователями.
Так как готового решения не было найдено, я написал модуль.
Основные изменения политики управления заключаются в том, что создаются группы, которые наследуют определенные роли. Пользователи наследуют роли уже у групп, в которых они располагаются.
Группы являются уже не служебной частью сайта, такой как «роли», а публичной. Группам можно присваивать «менеджеров», которые могут управлять пользователями группы, как пользователь с правом «администрировать пользователей» управляет всеми пользователями, включая добавление новых пользователей в эту группу.
Но это все же является возможно не правильным или не оправданным... Поэтому такое краткое описание.
Стоит ли продолжать расширять функциональность или переключиться на что-то другое?
Выкладываю код модуля на случай, если кому-то он действительно понадобиться.
Вложение | Размер |
---|---|
![]() | 9.57 КБ |
Комментарии
спасибо, конечно интересно
я пользовался еще модулем user_node - он из профиля пользователя делает полноценную CCK ноду в момент регистрации.
а "Organic groups" не удовлетворило чем то?
На сколько я понял, у OG основная цель: группировать пользователей в группы для предоставления им некоторых функций, например, возможность переписки и т. д. Но гибкого манипулирования пользователями он не предоставил.
Основная причина писать модуль было то, что прямое управление ролями пользователей утомительно при большем количестве пользователей. Причем, каждый пользователь должен наследовать несколько ролей. Не у всех пользователей объединение ролей одинаково. Создавать количество ролей для каждого вида пользователей не оправдано. Нужны были локальные администраторы пользователей. Позже расширю описание модуля...
по моему происходит дублирование уже существующего.
при раскладе, когда группа наследует права нескольких ролей, а менеджер группы волен добалять пользователей по своему усмотрению, очень легко запутатся в правах доступа.
но это всего лишь моё IMHO.
кстати, крутил-вертел OG но не нашел как назначать доступ группы к определенной ноде.
логично было бы назначать доступ в свойствах материала, но это не реализовано (
с такой задачей не сталкивались?
Возможно... Основная цель поста была увидеть поддержку идеи, а даже не показ модуля (он не совсем рабочий). За отсутствием времени, нет возможности обновить пост, поэтому опишу по подробнее здесь.
Основная цель модуля OG это создание сообществ и т.д., но гибкого управления ролями он не предоставляет.
Роли из коробки drupal дают возможность гибко настроить права пользователей, не спорю. И все удобно и хорошо, когда их мало и когда сайт сделан и не развивается..
Моя идея заключается в том, что несколько изменить представление ролей. Создав узкоспециализированные роли, мы потом их можем назначать группам. По совокупности ролей группы, генерируется роль пользователя (уже высокого уровня и представляет собой, например, руководитель). Что это нам дает?
Например, после установки модулей у нас появились новые права. Нам будет необходимо создать новую низкоуровневую роль и присвоить её группам, которым она нужна (а там уже у всех пользователей регенерируются роли высокого уровня). Если бы мы делали все по-старинке, то нам пришлось бы редактировать, к примеру, сотни две, ролей, присваивая каждой роли новые права. Конечно! Здесь можно будет придумать какой нибудь кастыль, не спорю.
Далее.. когда пользователей достаточно велико, возрастает нужда в массовом добавлении их. Делать десяток администраторов-пользователей для того чтобы они могли добавлять новых (именно необходимо чтобы секретарь мог сам создать пользователя) не есть хорошо, так как они потом смогут редактировать всех пользователей. Использование менеджеров дает возможность назначать пользователя управляющим группой. Он получает возможность редактирования профилей пользователей, добавлять новых, которые находятся в «его группах». Причем можно заблокировать некоторые группы (например где находятся аккаунты администрации). В последующем пользователя заблокированной группы не сможет изменить менеджер, даже если пользователь будет находиться в его подчинении.
В последующем планировалось сделать возможность вывода пользователей на странички. Тем самым сделать группы не только служебной частью сайта, как это обстоит с ролями.
Это как например, парадигмы программирования: структурное и объектно-ориентированное программирование. Если проект маленький или неграмотное проектирование, то использование ООП не оправдывает себя.
Похоже Чизхолм был прав: «Любые предложения люди понимают иначе, чем тот, кто их вносит.»
>> кстати, крутил-вертел OG но не нашел как назначать доступ группы к определенной ноде.
К сожалению , нет.
PS Прошу прощения за грамотность – все на скорую руку..
А возможность присваивать роли на определенный период?
по-моему, в пуле модулей OG есть такое, не помню точно ка называется - типа OG_user_roles