Как упростить выбор пользователя.

[vlad_simple]

Приветствую борцов с нетривиальными задачами непрямыми способами.
Постоянно сталкиваюсь с задачами, которые, похоже не предполагалось решать средствами самой программы.
Вот и сейчас. Как мне кажется, вполне логично было бы предусмотреть фильтрацию пользователей по группам.
Но такую возможность прямую не нахожу.
Создаю в действии поле с типом Пользователь и при выполнении получаю список ВСЕХ групп и пользователей.
Вероятно можно опять обратиться к SQL.
Но как себе, интересно, сами разработчики видели выбор пользователя на предприятии человек в 200?
Местная поддержка посоветовала сделать пользователей в виде обычных объектов с атрибутами любого рода и фильтровать их уже как захочется.
Но, получается, мне надо пользователей будет вводить дважды, связывать их учетки, т.к. для обеспечения безопасности нативные записи пользоваетей необходимы.
Не писать же в самом деле код для разграничения доступа для этих, дополнительно созданных, объектов-пользователей?
В связи с этим вопрос.
Кто как борется с задачей упрощения выбора пользователя?

[Александр]

если у

сделать пользователей в виде обычных объектов с атрибутами любого рода

пользователей кроме ФИО и контактных данных и вхождения в группы юзеров есть любая уникальная информация - без объектов юзеров не обойтись. Тоже касается и групп = структура предприятия - на объектах.
Все дублируют - добавил юзера в БД - на его основе сделал объект Юзер (мы их связываем через id; атрибут "id" объекта юзера = id юзера БД )
Юрез уволился - отключаешь активность для Юзера БД, а Юзера Объекта - а архив Юзеров объектов - история типа вся на месте

[Disillusioned]

Если настроить окно поиска, чтобы оно открывалось в режиме запроса, а не вываливало сразу весь список пользователей, то поиск по нескольким первым буквам фамилии - вполне комфортен...

[Anderyt]

у нас тоже есть дерево объектов-сотрудников, повторяющее орг. структуру компании, выбор исполнителя и адресата идет из него. в атрибуты можно запихать кучу всего, поиск может получиться очень разносторонний.
в списке, кстати, порядка 700 сотрудников.
причем, искать можно не только по вхождению сотрудника в группу какого то отдела, но и по вхождению в направление деятельности (это выше отдела), и по вхождению в сектор или группу (это уже внутри отдела). плюс есть признаки начальник-подчиненный.
то есть при поиске инженером своего начальника отдела система автоматом подставляет одного-единственного начальника, а при поиске рук-лем сектора своих инженеров - выдается список ТОЛЬКО ЕГО инженеров, без подчиненных руководителя другого сектора в ЭТОМ ЖЕ отделе.
для простоты, конечно, можно использовать выбор пользователей с поиском по первым буквам. это если юзеры не будут ошибаться с выбором (случайно или специально)

[vlad_simple]

Спасибо за идеи!!!
Вобщем, просто как всегда не получится.
А как проще организовать структуру?
Через атрибуты (нач отдела, отдел такой-то....)
или через связи???
То, что в атрибутах объектов надо писать ИД пользователей, а не имена/фамилии я уже скумекал.

[Anderyt]

у нас сделано так.
есть дерево объектов, которое повторяет орг. структуру. есть объекты-подразделения, в них - объекты-штатные единицы, в них - объекты-сотрудники.
основная инфа хранится у объектов-сотрудников. помимо фио, должности, телефона и кабинета есть строковый индекс. это строка из 10 символов, в которой закодировано место подразделения конкретного сотрудника в общей иерархии и уровень управления конкретного сотрудника.
то есть:
04 00 00 00 00 - направление Проект
04 05 00 00 00 - отдел АСО в направлении Проект
04 05 02 00 00 - сектор 2 отдела АСО в направлении проект
04 05 02 03 00 - группа 3 сектора 2 отдела АСО в направлении проект
это индексы подразделений (для отделов, секторов и групп есть свои объекты), а также индексы руководителей соответствующих подразделений, то есть
04 05 00 00 00 - индекс начальника отдела АСО в направлении Проект
04 05 02 03 00 - индекс руководителя группы 3 сектора 2 отдела АСО в направлении проект
при этом у всех простых исполнителей (НЕ руководителей) в группе последние два символа - хх, то есть 04 05 02 03 хх

так выглядит структура сотрудников изнутри. снаружи - простое дерево.
ясно, что приходится обеспечивать непротиворечивость связей между объектами (а они только подчиненные) и индексов, но зато для выбора сотрудника нам как бы и не нужно дерево. идет просто поиск объекта-сотрудника с индексом, удовлетворяющим определенной маске.
04 __ 00 00 00 - все начальники отделов в направлении Проект
04 __ __ __ 00 - все руководители разного уровня в направлении проект
04 05 02 __ __ - все сотрудники сектора 2 отдела АСО в направлении проект
для работы с этой структурой есть действие над объектами, которое запускается по кнопке на форме задачи в карте работы. кнопка знает, кого мы хотим найти (рук. группы, начальника или всех подчиненных для руководителя) и запускает действие с нужным параметром. действие, если необходимо, определяет индекс текущего юзера, вычисляет на его основе маску индекса и ищет объекты-сотрудники по этой маске.

вся эта система обеспечивает узкие списки выбора (рук сектора отдела АСО не может отправить исполнителю в другой отдел, например), если этого требует конкретный бизнес-процесс. а руководители находятся вообще автоматически (руководитель по определению один, объект-сотрудник с индексом, заканчивающимся НЕ на хх, тоже один).

плюс был разработан ряд процедур и видов на сервере БД, которые позволяют выбирать сотрудников или отделов одной строкой, не устраивая поиск объекта-сотрудника. например, можно получить ИД руководителя подразделения с определенным индексом, или название подразделения, к которому относится сотрудник с определенным ИД или индексом.

эта система была разработана еще году в 2003 и только развивалась, не меняясь кардинально. хотя, возможно, сейчас уже есть другие возможности выбора объектов-сотрудников из шаблонов докооборота, не прибегая к запуску действия над объектами (выпадающий список из нескольких фамилий прямо на форме задачи смотрелся бы наверное намного симпатичнее)

воооот...

[vlad_simple]

Спасибо за столь развернутый ответ.
Получается используется сразу две сbстемы доступа к объектам
1. это по сложносформированному атрибуту для упрощения поиска
2. и по дереву для упрощенного паредставления

[Anderyt]

Получается используется сразу две сbстемы доступа к объектам1. это по сложносформированному атрибуту для упрощения поиска 2. и по дереву для упрощенного паредставления

в принципе да. вообще, дерево нужно для человека. и для юзеров, и для админов. чтобы не запутаться в иерархии, ну и чтобы было красиво
а для системы, по сути, нужны только объекты с атрибутами. все эти объекты могли бы быть в каком-то одном корне, то есть в виде простого списка, а не дерева, и поиск сотрудников по индексам работал бы с тем же успехом.

еще раз прочитал название этой темы, подумал, и понял, что мой вариант нифига не для упрощения выбора пользователя

[vlad_simple]

Ну уменьшение списка пользователей с помощью фильтра это уже упрощение.

[Старик Крупский]

Справочник сотрудников и справочник пользователей вещи несколько разные. Сотрудников обычно больше, чем юзеров. Поделюсь опытом. Лет несколько назад я расширенным импортом из таблицы umplusers, если не изменяет память, выгружал список пользователей и создавал сотрудников. Грубо говоря, закачали из AD юзеров и расширенным импортом создали сотрудников. Я на этом и закончил, но если смотреть дальше, то импорт можно запускать хоть каждую неделю. Выгружать пользователей и искать сотрудников по атрибуту с кодом пользователя. Если нашел - пропустил, не нашел - создал. Можно еще и поупражняться с группами-отделами, входимостью сотрудника в отделы, но с входимостью уже неоднозначно, т.к. сотрудник работает в одном отделе, но сопоставленный юзер может входить в несколько групп...
Короче, это простор для размышления...

[Anderyt]

а мы, например, относимся к справочнику сотрудников (объектов) как к справочнику пользователей системы. не каждый новый юзер сети (и тем более, не каждый новый сотрудник компании) становится пользователем системы и объектом-сотрудником. но для каждого юзера есть объект-сотрудник (исключая несколько системных юзеров). а для некоторых объектов-сотрудников юзеров нет.
и всем говорим, что дерево сотрудников - это вам не телефонная книга и не справочник сотрудников, это список пользователей системы. добавляем в него только по конкретной заявке руководителя подразделения. если человек не будет пользоваться системой - зачем его регистрировать и, тем более, ставить АРМ?
а случай, когда для объекта-сотрудника нет пользователя, вызван нашим стремлением упорядочить работу с ФИО сотрудников. раньше для некоторых случаев использовались классификаторы сотрудников (то есть НЕ объекты-сотрудники), например, для выбора исполнителей по письму. было удобно в том смысле, что не надо было регистрировать пользователя и сотрудника, чтобы зарегистрировать письмо с его авторством, надо было просто сделать объект-классификатор и все.
но по мере масштабирования список объектов-классификаторов все больше стал приближаться к списку объектов-сотрудников и пользователей, и нас начала напрягать необходимость синхронизации этих списков между собой. сейчас есть простенькая процедура для создания объекта-сотрудника БЕЗ создания пользователя. и новый сотрудник может быть выбран в качестве исполнителя по письму.
в общем, лучше, чтобы список сотрудников, который будет использоваться в интерфейсе, был один. но со списком пользователей сильно не разбежишься, поэтому остановились на двух списках - пользователях и сотрудниках. и все. классификаторы с ФИО стараемся исключать.