Доброго дня всем!
Заказчик настоятельно считает необходимым различные уровни доступа для Запроса (UserRequest) для различных пользователей. Например, Менеджер может видеть и править больше полей, чем Исполнитель.
Понятно, как это сделать в зависимости от статуса запроса, но в зависимости от пользователя такого функционала нет, есть только доступ на уровне класса целиком.
Что можно придумать в этой ситуации? Дополнительное кодирование на PHP? Workaround на основе отсаживания части полей в отдельный класс и управление доступом к нему?
Принимаю любые идеи, желательно с комментариями, почему так, а не по другому.
Заранее спасибо
Задача нетривиальная, но решаемая. У iTop есть возможность более глубокой, чем изменение XML модели данных, кастомизации через т.н. API расширений. Расширения пишутся на PHP и используют существующие интерфейсы iTop. Через интерфейс iApplicationUIExtension можно менять поведение графического интерфейса при отображении и изменении свойств объекта (см. метод OnDisplayProperties).
Не гарантирую, что это 100% сработает. Если поделитесь более подробной информацией (роли, поля), постараюсь подсказать детальнее.
Привет, Владимир!
Спасибо за ответ. Посмотрел на OnDisplayProperties и пример к нему. В принципе, это то, что нужно, но вопрос остается в том, что указать внутри if в качестве условия (эта информация должна присутствовать в методе). Для примера условно назовем эту информацию CurrentUserDeliveryModelRole и дальше текст примера.
if ( CurrentUserDeliveryModelRole == “Manager”)
{
$oPage->p('Age of the captain: ');
}
else
{
$oPage->p('Age of the captain: '.$iCaptainAge);
}
Для примера по полям. Нужно сделать так, что описание запроса Description может редактировать только Менеджер и Администратор, причем в любом статусе, Инициатор только в момент создания (потом читать) и Исполнитель только читать всегда.
Менеджер и Администратор - это роли пользователей во всей системе.
Инициатор и Исполнитель - это конкретные пользователи, связанные с текущим запросом.
Верно?
Администратор - да. Менеджер - не уверен, но в части Запросов да.
Инициатор и Исполнитель - пользователи, для разных услуг (типов запросов) их список может отличаться.
Запросы создаются в общем интерфейсе (не через портал).
Еще такой вопрос появился.
нашел в каталоге itop/addons/userrights PHP код, который судя по всему, имеет какое-то отношение к настройке прав для пользователей.
Вы что-нибудь знаете про этот addon? Как его подключить, использовать и т.п. Можно ли приспособить к моим проблемам? В документации вроде ничего нет.
Насколько мне известно, это и есть стандартный функционал прав пользователей. Он подключен по умолчанию, в решении твоей задачи не поможет.
Кстати, OnDisplayProperties, как я полагал ранее, тоже не поможет. Эта функция получает управление уже после формирования списка отображаемых полей тикета, а тебе нужно влиять на сам процесс формирования.
Самое красивое решение - переопределить функцию GetAttributeFlags для нужного типа тикета. Эта функция возвращает флаг атрибута (READONLY, HIDDEN, MANDATORY и др.), который задается для каждого статуса. Дальше на основе флага iTop отображает или скрывает, делает редактируемым или доступным только для чтения соответствующий атрибут.
То есть нужно определить список атрибутов, на отображение которых нужно влиять, и условий. Для атрибутов тикета, которых нет в списке, запускать родительский GetAttributeFlags, если атрибут в списке, выполнять проверку условия и возврящать значение нужного флага. Условия - роли пользователей (системные и в тикете), а также редактируется тикет в данный момент или просматривается.
Спасибо, Володя.
Беглый поиск по тексту показал наличие нескольких описаний этой функции в разных классах. Я не программист, я занимаюсь системной аналитикой и интеграцией. Как и в каком месте нужно переопределить, не знаю. Надеюсь, что если привлечь программиста, будет яснее. Но вопрос как был, так и остался. Есть ли внутри класса (dbobject, например) информация о роли пользователя для включения в условие if?
Нет. Эту информацию нужно брать из контекста выполнения приложения. Есть переменные, которые хранят данные о пользователе, который в настоящий момент залогинен. а у iTop есть методы для получения ролей этого пользователя.
Переопределять в отдельном модуле, в разделе <methods> модели данных нужного типа тикетов.
По теме получения данных о пользователе доков и примеров нет, нужно копать исходники.
Вот набросал небольшой пример: custom-ticket-fields-access. Работает с Запросами пользователей и изменяет правила отображения поля Описание для Инициатора и Агента. Инициатор после создания запроса не может редактировать поле, а для Агента (после его назначения) поле скрыто (ну так, для примера просто)).
Ставить поверх модуля Request Management ITIL, проверял с версией 2.0.2.
Большое спасибо за пример (все оказалось проще, чем казалось вначале) и ссылки. Я поставил этот модуль и сейчас разбираюсь, как он работает. Единственно, что подключил его не к ITIL request management, а к Simple, как у меня установлено на тестовом окружении.
Разобрался, проверил, идея работает замечательно. Остался собственно один вопрос, можно ли привязаться в условиях проверки не к существующим атрибутам класса UserRequest, таким как agent_id, caller_id и т.п, а к атрибутам других классов: ролям (ContactType) или аттрибуту Function класса Person. Это было бы идеальное решение для этого функционала. но как этого добиться, мне пока не ясно.
Смотри методы GetUserOrg() и IsPowerUSer(), описанные в index.php портала. Думаю, там всё будет понятно. В первом случае выгребаем ID контакта текущего пользователя, а дальше Get->(‘нужный атрибут’). Во втором случае проверяем, имеет ли текущий пользователь определенную роль.
ContactType - это дополнительное поле в связке персоны и команды, Смысл - описание роли конкретной персоны в конкретной команде, например, Исполнитель или Менеджер. Список ContactType определяется в типологии и может быть любым. Тикет при создании связывается с командой, а дальше идет в соответствии с DeliveryModel
Посмотрел реализацию GetUserOrg() - логика понятна. Последовательное движение по атрибутам - внешним ключам от класса к классу, пока не доберемся до нужного. В принципе, ничего сложного.
Тогда вроде никаких препятствий для необходимой имплементации системы регулирования доступа по полям в зависимости от персоны (команды) нет.
Препятствий нет. Просто нужно всё хорошо продумать. С полем Описание проблем не возникнет, поскольку доступ к нему изначально не зависит от статуса тикета. Но для других полей, возможно, потребуется помимо роли пользователя и его функции в конкретном тикете учитывать и статус самого тикета.
Также важно понимать, что большинство методов, начинающихся с Get...(), это обращения к базе. Например, GetUserOrg() делает три обращения, прежде чем вернуть организацию клиента (получение ID контакта, получение объекта контакта, получение объекта организации). Это нужно учитывать и стараться минимизировать.
Да, это я не учел, что на эту систему прав еще должен наложиться эффект от статуса тикета. Как это сделать, в каком порядке будет происходить установка iTOP’ом атрибутов полей, не понятно. Это действительно может вылиться в серьезную проблему.
Что касается Get…, то пока нет заметных задержек в GUI, то можно об этом не думать.
Т.е. игнорируя то, что написано в XML файле? Фактически мне для данного поля надо будет переопределить атрибуты для всех статусов? Так? Это не удобно, мягко говоря. Статус тикета я так понимаю, есть одно из свойств его класса.