Как мы написали helpdesk

    Есть продукты, которые можно взять и использовать, но с небольшой модификацией «под себя». Так вот система заявок или helpdesk как раз к таким вещам не относится. Точнее, мы для себя не нашли подходящий продукт и решили сделать сами.



    Изначально, у нас были исходные от которых отталкивались и позже выдвигались требования:

    1. Чуть больше 2000 пользователей, которые не будут участвовать в системе заявок, но статистику обращения которых нужно фиксировать
    2. Около 30 человек персонала, которые делятся на 3-4 отдела, в котором по начальнику и все они имеют доступ к хелпдеску
    3. Система только для внутреннего корпоративного использования
    4. Извещение по email/sms
    5. Отчётность и статистика
    6. База пользователей (идеально взять с ActiveDirectory, хотя бы частично)
    Если у Вас такие же исходные, возможно Вам эта статья и система помогут.

    Позиция меня, как разработчика основывалась на сегменте готовых opensource продуктов, поддерживающих php & mysql. Изначально были рассмотрены: OsTicket, который достаточно прост, но в тоже время много функционален, что в свою очередь является минусом (много лишнего «выпиливать и прятать», а то что необходимо — дописывать). А так же более серйозное решение — OTRS, которое имеет встроенный инструмент работы с LDAP. В нём особенно понравилась форма создания заявки, в которой при вводе ID клиента подтягивалась вся информация о нём. И поэтому захотелось «золотой середины». Общий вывод таков, что под конкретные требования не подходит не один из них, но у последнего ввиду интерфейса хотя бы можно игнорировать часть требований. Имея небольшой опыт разработки php/jquery-проектов, я решился написать свою систему.

    Основными задачами были: учёт всех заявок, отчётность и контроль со стороны руководства, в какой стадии находится та или иная задача. К примеру, начальник отдела мог с вечера определить задачи на следующий день для своих подчинённых, выбрав для них приоритет. А подчинённые, прийдя на работу, могли сразу видеть список задач и в течении определённого времени их выполнять.

    Как такового чёткого технического задания у нас не было. Поэтому мы примерно определили структуру системы и её модулей.



    Как видно из модели, хотелось так же использовать систему «личных сообщений» пользователей. Но в будущем эта затея отпала, зато вместо неё мы решили добавить:
    • Комментарии на странице заявки, для того что бы можно было обсуждать заявку или отписываться по её выполнению
    • Разделить заявки на 3 категории: Входящие, Исходящие, Архив (в который заявки автоматически попадают по истечению какого-то времени, при статусе «выполнено»)
    • Центр знаний (раздел, в котором можно было бы найти ответы на интересующие вопросы, решить проблему не создавая заявку. Тут могут быть инструкции, руководства, документация)
    • Блокнот (для хранения личных заметок и записей, с возможностью делиться ссылкой на них)
    • Логирование всех действий пользователей


    Немало времени и работы уделялось процессу создания заявки. Как я уже писал выше, понравился подход в OTRS. Поэтому, что бы при звонке клиента можно было идентифицировать его, узнав о его предыдущих заявках и числу обращений, необходимо было наполнить базу клиентов. У нас часть информации о клиентах хранилась в Active Directory, другая часть — в телефонном справочнике формата doc. В AD были только: ФИО, логин, email и группа (подразделение). В справочнике doc были: ФИО, тел, кабинет. Вместе они дополняли друг друга. В этих двух источниках, единицы информации могли и не совпадать. К примеру, в LDAP находилось около 2000 записей, а в справочнике — 1200. Из них совпало ~1000. Ну и этого было достаточно.



    Наполнение базы клиентов

    Процесс определился в несколько этапов:
    1. Импорт из AD был путём PHP. Стандартно подключались в LDAP, вытягивали нужную информацию.
    2. Импорт из doc-справочника был куда интереснее. Сначала перенесли нужные данные таблиц в xls, отформатировали и сохранили в CSV.
    3. Далее импорт в MySQL-таблицу делал php-скрипт, который в цикле перебирал LDAP-записи и sql-записи и сравнивал ФИО (это единственное, что у них было общее).




    В итоге имеем сборную таблицу с более 1000 записями информации о клиентах компании. При создании заявки мы можем ввести телефон, ФИО или логин, что бы узнать информацию о клиенте, его количеству обращений и последних заявках.

    Кодинг

    Это не первый проект, в котором я выбрал такую организацию файлов. Возможно это можно назвать «шаблоном проектирования», поправьте, если ошибаюсь.



    Для меня, такая организация «общения» файлов показалась более логичной и простой. Всё расположено там, где ему место. Файл actions.php в основном состоит из блоков-действий, вроде «создать заявку», «блокировать заявку», «добавить клиента» и т.д. К нему посылается POST-запрос с определённым именем, который и вызывает нужную часть кода. Что касается описания событий на странице, то за это отвечает core.js.



    Движение заявки

    О движении самой заявки, стоит рассказать детальнее. Как правило выделяют из всего персонала 1-2 человека-оператора или дежурных, которые и принимают заявки: 80% в телефонном режиме, 20% на месте. Мы всегда придерживались мнения, что важно решить проблему ещё до создания заявки. И если эта проблема/задача не в компетенции сотрудника, то он её направляет на профильный отдел или конкретному человеку. Если получатель заявки выбран отдел, то такую заявку увидят все, кто входит в этот отдел (и конечно начальник отдела). Если же выбран конкретный человек, то такую заявку увидит этот человек и его начальник. Остальным же пользователям отдела заявка будет не видна.

    Идея заключается в том, что бы заявка не оставалась без внимания и её статус выполнения всегда мог наблюдать начальник отдела.

    В процессе разработки было решено делать 3-х уровневую систему прав пользователей.



    Суть заключается в том, что главный Администратор видит заявки всех отделов и всех пользователей. Координатор состоит в определённом отделе(-ах) и видит заявки всех пользователей именно этого отдела(-ов). Пользователь видит только те заявки, которые направлены в его отдел (всем) или конкретно ему. Заявки другим пользователям со своего отдела он не видит.



    Спустя время, мы столкнулись с коллизией: пользователи физически входили в один отдел, но фактически работа была смежной с другими отделами. И им необходимо было видеть заявки других отделов, но с разными правами. Так родилась идея «вертикально-горизонтальной» ориентации прав доступа. По вертикали — это были права пользователя: админ/координатор/пользователь. А по горизонтали — это список тех отделов, в которые он мог входить с общими правами. Логической точкой пересечения этих прямых и были общие права доступа в систему.

    При тестировании мы увидели, что не очень заметно, когда появилась новая заявка. К примеру, у человека на одном мониторе может быть открыт в браузере хелпдеск, но при появлении новой заявки он ничего не увидит. Не хорошо. И тогда мы решили сделать, как в популярной социальной сети всплывающие сообщения. Срабатывают они по разным действиям, вот так:



    Для работы всплывающих сообщений мы на определённых страницах посылаем каждые 2 секунды ajax-запрос в 208 байт, который спрашивает у скрипта на сервере: «есть ли что-то новое для пользователя?» и если есть, то клиент получает json-ответ. Конечно, для полной «красоты», это делается через сокеты. Но пока мы к этому не пришли. Так же добавили эффект мерцания title-страницы и заголовок вкладки явно кричал: «тут что-то обновилось, обрати внимание».

    Совсем недавно у нас внедрили jabber-месенджер. Поэтому мы сразу подключили helpdesk к нему и теперь извещения о новых заявках приходят и в джабер. Часть сотрудников не находится на своих рабочих местах, а работают с клиентами (устанавливают софт, обслуживают технику). Поэтому к ним особое внимание по извещению о новых заявках. Самый оптимальный и простой способ это sms-извещение. Нашли удобный сервис и через его API интегрировали нашу систему.

    Интеграция

    Важным моментом было получение доступа к системе заявок, существующих пользователей IT-подразделения. Мы создали белый список login/email. Суть его заключалась в следующем: человек при входе через web кликает на ссылку «первый вход», и вводит только свой ldap-логин. На его доменную почту приходит письмо с созданным паролем и ссылкой, на которую он переходит и получает полноценный доступ к системе. Таким образом снялась задача с администратора системы каждому выдавать учётные записи.

    Что у нас вышло?

    • Многоуровневая система прав пользователей
    • JQuery-ориентированая структура интерфейса
    • Возможность регистрации в системе из «белого списка» e-mail адресов
    • Извещение о новых заявках по e-mail, sms, и другим системам
    • Пользовательские настройки
    • Поддержка языков: Украинский, Русский, Английский
    • Всплывающие сообщения о событиях с заявками (как в VK)
    • Центр знаний — раздел для файлов документации, инструкций и хелпов со структурой прав
    • Блокнот — личный блокнот пользователя с возможностью делиться ссылкой
    • Статистика заявок
    • «Умное» создание заявок по номеру, ФИО, логину клиента
    • Приоритеты заявок
    • Комментарии и чат в заявке
    • Полное логирование всех действий всеми пользователями заявки
    • И другое...

    Заключение

    На сколько удобно и оправдано было написание такой системы покажет время. А пока мы стараемся не превращать её в «монстра», но в тоже время добавить некоторые возможности: добавление загрузки файлов к заявке, статистика и другие вещи. Моё личное критичное мнение заключается в том, что система вполне рабочая, но с кодом ещё необходимо поработать. Мне будет очень приятно услышать Вашу критику и замечания, а так же увидеть Ваш вклад в развитие проекта.

    Github: link.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 86
    • +1
      По поводу кода — шаблонизатор неплохо бы прикрутить, а то каша из php и html-кода ну как-то несерьезно.
      • +2
        Судя по изображению — там процедурный php. Так что перед внедрением концепции MVC — неплохо было бы еще и в этом направлении разобраться.
        • +3
          В общем-то, все прелести MVC можно реализовать и в рамках процедурного подхода.
      • +1
        Yet Another Helpdesk

        А почему вы начали писать именно свой, самописный, хелпдеск?
        Можно было взять ту же JIRA и настройками сделать то же самое, что есть у вас (и еще 90% функционала осталось бы в резерве).
        Что сподвигло именно на написание?
        • +2
          Уж очень много захотелось тонкостей и по натуре, слишком придирчиво относился к мелочам. Как показывает опыт — эти мелочи, которые не нравятся в работе готовых хелпдесков постепенно перерастают в мешок неприятностей, после которого уже вобще не хочется работать с системой ни пользователям, ни админам. А уж разбираться в чужом коде, не понимать как он работает, внедрять свои штуки — вобще желания не было.
          • +2
            > взять ту же JIRA и настройками сделать то же самое

            бгоооо. ты вот сначала попробуй. а потом говори.
            • 0
              Прекрасный ответ, я уже пробовал.
              • 0
                … не мешки ворочать, да.

                Jira очень generic система. Многих вещей там просто невозможно добиться по-человечески. Multiple assignments, например.
            • +7
              Ога — взять платную jira, выучить java, написать плагины. Отличный workflow.
            • +16
              Молодцы, что выложили на GitHub! Уже только за это жирный плюс.
              • +15
                На github, открываю первый файл и первое что вижу — SQL инъекция (к примеру: github.com/rustem-art/hd.rustem/blob/master/index.php#L27 ).
                • 0
                  Да есть такое, поэтому я сразу оговорился: для внутреннего использования. В плане безопасности, мы эту стадию пропустили. Поэтому буду рад, если кто-то заинтересованый в этом проекте внесёт свой вклад в это направление.
                  • +7
                    Мне казалось что в 2014 году увидеть собирание запроса руками, а не использование параметров вообще невозможно, ан нет. Но зачем? Что для MySQL + PHP нормальных провайдеров не изобрели еще что ли до сих пор?
                    • 0
                      Да есть, конечно. Например, в PDO.
                      • 0
                        классная штука! я только сейчас отсюда и узнал про такое решение)
                      • 0
                        Изобретено давным-давно. Также как различные фреймворки/шаблонизаторы/ORM.
                        Почему автор избрал такой путь – загадка.
                      • +16
                        Я не знаю как вы с этим спите. Я когда подобное сделаю, потом не могу спокойно жить. Меня постоянно грызет совесть. :)
                        • +5
                          факт, что продукт внутренний не исключает безопасность) Вы думаете, у вас мало людей, которые бы не отказались получить админ-доступ в систему тикета и невозбранно пограбить корованы?
                          • –1
                            Для тех кто любит собирать запросы руками (я сам люблю что уж там) я бы предложил использовать PostgreSQL с его $$-quoting. Можно писать запросы типа INSERT INTO names VALUES ($qt$Вася$qt$);

                            $qt$ тут канает за кавычки, вероятность встретить такое в реальном тексте стремится к нулю (тем более что можно делать хоть $VladimirIlitchLenin$), так что включения этого маркера во входных данных можно выпиливать без зазрения совести.
                            • 0
                              Зачем? Dollar-quoted в постгресе придуман совсем не для этого.

                              Хотите собирать ручками – PDO предоставляет все средства для этого и от СУБД не особо зависим.
                              • 0
                                А для чего он, в таком случае, придуман?
                                • 0
                                  Все написано в доке.
                                  Юзабельно, если надо работать с текстом непосредственно в базе, для работы через приложение интереса не представляет.
                                  • 0
                                    Судя по указанному вами месту в доке, $$-quoting просто особенно удобен при написании хранимых процедур, но ничто не мешает использовать его в приложении (если не требуется совместимость со стандартом SQL).

                                    Впрочем я не навязываю, PDO тоже вариант, просто проинформировал автора что есть такая возможность.
                                    • 0
                                      Судя по указанному вами месту в доке, $$-quoting просто особенно удобен при написании хранимых процедур
                                      Это:
                                      it can be difficult to understand when the desired string contains many single quotes or backslashes, since each of those must be doubled. To allow more readable queries in such situations, PostgreSQL provides another way, called «dollar quoting», to write string constants.
                                      вы похоже пропустили.

                                      dollar quoting имеет смысл (помимо процедур) при запросах с голым текстом
                                      INSERT INTO val VALUES ($$'много'разного'текста'$$);
                                      -- вместо
                                      INSERT INTO val VALUES ('''много''разного''текста''');
                                      


                                      На программном уровне (при работе с переменными) есть более удобные/наглядные/переносимые средства, чем использование $$-quoting.
                                      $$-quoting отличная штука, но в данном топике она упомянута совсем не к месту.

                                      PS что–то мы в оффтоп скатились, если есть желание, то приглашаю в личку.
                                      • 0
                                        Думаю в личку это плохая идея, если кто то найдет этот диалог то ему наверное будет интересно стоит использовать Dollar-quoting или нет :)

                                        В общем то, абстрагируясь от предполагавшихся авторами PosgtreSQL сценариев использования $$, я просто утверждаю что код типа

                                        // допустим $_POST['name'] имеет значение "Вася $mytag$); DELETE * FROM peoples; --"
                                        
                                        function Q($val) {return ' $mytag$'.str_replace('$mytag$', '', $val).'$mytag$ ';}
                                        
                                        pg_query('INSERT INTO peoples (name) VALUES ('.Q($_POST['name']).')');
                                        


                                        является защищенным от SQL-иньекций. Разве нет?
                                        • 0
                                          является защищенным от SQL-иньекций. Разве нет?
                                          Да я не об этом.
                                          Ваш код чудесным образом можно (и нужно) переписать без dollar quoting
                                          pg_query_params( 'INSERT INTO peoples ( name ) VALUES ( $1 )', array( $_POST[ 'name' ] ) );
                                          
                            • 0
                              Ну можно, например, вместо обращений к $_POST[] использовать filter_input(). Кстати, не слишком старые интерпретаторы будут это в ворнингах предлагать делать.
                            • +1
                              Вы не могли бы пояснить, что плохого в отмеченной строке?
                                • 0
                                  А, всё ясно, спасибо!
                                  • 0
                                    Когда то, очень давно в своих велосипедах делал так:
                                    <?php
                                    foreach($_POST as $key=>$val){
                                    if(is_array($val)){
                                        foreach($val as $key2=>$val2){
                                                $val[$key2] = mysql_real_escape_string($val2);
                                        }
                                    }
                                    else{ 
                                      $_POST[$key] = mysql_real_escape_string($val);
                                    }
                                    }
                                    

                                    Пишу по памяти. Тоже самое можно делать и с $_GET. Веселые были времена :)
                                    • 0
                                      Ну это как раз не очень хорошо :) Экранировать надо непосредственно перед постановкой в запрос. А то мало ли что ещё захочется со строкой сделать.
                                      • 0
                                        Я ж говорю, веселые были времена. Мне кажется, можно вообще не использовать экранирование, если делать приведение типов, например к int.
                                        • 0
                                          И к какому типу вы будете приводить строку вида «Вася Иванов»?
                                          Давно придуманы плейсхолдеры с автоматическим экранированием.
                                          • 0
                                            Понятно, что все строки нужно экранировать. Я говорю о тех случаях, когда идет отбор по полю типа int, float, date и т.д. и т.п.
                                            • 0
                                              В современных реалиях приведение типов в запросе абсолютно ненужная вещь: этим занимается драйвер БД.
                                • +1
                                  image
                                • +3
                                  Инъекцию уже подправили.
                                  Но таки да: стиль не айс, учитывая, что есть mysqli/PDO/ORM с вкусняшками, а mysql объявлен деприкейтнутым.
                                • 0
                                  Можно добавить еще «Шаблоны заявки» т.к. часто есть группа однотипных заявок. И типовые решения с возможностью быстрой ссылки на Центр знаний.

                                  p.s. Эхх. Где вы были пару лет назад :)
                                  • 0
                                    Очень напоминает YouTrack.
                                    • +3
                                      внешне выглядит симпатично, но код…
                                      • +2
                                        Код откровенно говно :) Это говорю Вам я, кто написал эту штуку. В этом посте мне хотелось бы меньше акцентировать на этом внимание.
                                        • +2
                                          А на что хотелось бы акцентировать внимание? Стоило ли делать свой хелпдеск? Так тут Вам-то виднее, какие у Вас и Вашего руководства были на него планы.
                                          • 0
                                            Самое очевидное, это то, что при большом желании и стремлении можно реализовать большинство средней сложности задач, даже не имея достаточных знаний в MVC, ООП, даже JS/PHP. Другой вопрос — стоит ли овчинка выделки, это уже мы посмотрим. Но в целом, для себя я вынес ключевые моменты, которые мне надо учить и подтягивать.
                                            И ещё раз спасибо за критику и комментарии.
                                            • 0
                                              Другой вопрос — как :) У меня скоро будет проект, где нужен самописный хелпдеск, вот может созреем с ребятами взять за основу Ваш гитхаб и решить проблемы с кодом. Напишу Вам в личку, перед стартом, за разрешением, если примем решение идти по такому пути. Внешка неплоха, качество сервер-сайда неприемлемо.
                                    • 0
                                      Скажите, а сколько в общем человекочасов было потрачено на разработку/тестирование/тестовую эксплуатацию?
                                      • 0
                                        Не могу ответить точно на этот вопрос, потому как не было чётких рамок, плана проекта. Это было скорее хаотичное программирование. Много чего делал просто из интереса и увлечённости этим проектом, поэтому на общее потраченное время не обращал внимания. «Глубокое тестирование» вобще не проводилось.
                                      • +1
                                        Идея хорошая, натягивать имеющиеся трэкеры на свою задачу не всегда оправдано. А качество кода очень пострадало (это я мягко, из уважения к проделанному труду и смелости поделиться этим на GitHub).
                                        • +1
                                          В соседнем топике как рас история об отказе от OTRS в пользу Jira habrahabr.ru/post/220823/
                                          • +1
                                            Количество sql инъекций просто очень большое (например, первый открытый файл), прячьте демо сайт.
                                            • 0
                                              Демо-сайт уже спрятали. Всё-таки хабра-пользователи — это лучшие тестировщики безопасности! :)
                                              Спасибо, за наводки!
                                            • 0
                                              Если захотите интегрировать телефонию с ним, то есть отличный вариант
                                            • +1
                                              Да ладно, код бывает и похуже, я свой внутренний хелпдеск примерно так же писал. Хотя переменные в запросах экранировал, конечно :)
                                              Но мне свое выкладывать стыдно :(

                                              А вот есть у нас интранет-сайт, писаный какой-то убогой гениальной веб-студией еще лет 7 назад, так я до сих пор пожинаю результаты их труда, когда обновляется пэхапе и в этом чуде что-то ломается. Когда заглядываю в код — у меня из глаз начинает немного сочиться кровь… Маркетинг давно обещает нам новый, сияющий аяксом и прочим вебдванолем, сайт, но воз и ныне там…

                                              Так что респект автору, ГУЙ очень неплохой, а остальное подтянется.
                                              • 0
                                                Спасибо за комментарий, действительно порадовал и вдохновил :)
                                              • 0
                                                использование как минимум PDO частично решило бы проблему экранирования при работе с бд и немножко защищала бы от sql инъекций. а вообще дело очень полезное. хорошо, когда руководитель понимает зачем это надо и помогает внедрять такое. а то тут у нас какбэ наоборот… ((
                                                • 0
                                                  Да вроде не частично, а полностью при использовании prepared statements.
                                                • 0
                                                  То факт, что проект выложили на гитхаб — это молодцы. Подскажите под какой лицензией? Если вдруг кто-либо захочет переписать на другой фреймворк/язык программирования?
                                                  • 0
                                                    Все уведомления на украинском?
                                                    • 0
                                                      Не должны как бы. Максимально переводили, единственное — что может не совсем точно перевели :)
                                                    • 0
                                                      А уведомления о выполнении/изменении статуса заявки нет? и где подключается смс уведомления?
                                                      • +1
                                                        Уведомления приходят по 2 событиям:
                                                        1. Создана новая заявка
                                                        2. Перенаправлена новая заявка
                                                        Для нас такой подход был более приемлем, чем спамить на почту.
                                                        SMS-уведомления выпилены в той версии, что на гитхабе.
                                                        Но сделать это не составит труда, дописав функцию напр send_sms в functions.php и включив её в actions.php блок ($type == «add»), детальнее — пишите в личку или на почту — помогу.
                                                        • 0
                                                          Спасибо, я это так к слову. Вы заявляли функционал, а в коде я не нашел. Вот и поинтересовался.
                                                      • 0
                                                        Симпатично. Но как система ведет или будет вести себя на больших объемах данных? Сколько человек разрабатывало и поддерживает данную систему? Что будет, когда эти люди уйдут?
                                                        • 0
                                                          Будет очень интересно проверить когда количество заявок достигнет пика. Пока такой возможности не было.
                                                        • –1
                                                          Это все конечно хорошо, но в 2014 году уже можно было бы познакомиться с продуктами компании Atlassian и не заниматься велопроизводством.
                                                          • +1
                                                            Согласно такой логики вообще ничего девелопить не нужно.
                                                            • 0
                                                              Еще как нужно, но есть сектора, где уже давно представлено прекрасное готовое решение.
                                                              И это решение используется как корпоративный стандарт во многих компаниях, а значит новым сотрудникам будет проще влиться в корпоративную среду.
                                                            • 0
                                                              Продукты компании Atlassian появились как-раз потому, что кто-то начал писать свой велосипед…
                                                            • 0
                                                              А меня очень заинтересовал ваш сервисдеск, как раз на днях искал что-то подобное: простое, удобное, не перегруженное и в тоже время довольно функциональное. Очень понравился интерфейс, как просторный дизайн так и хорошее юзабилити.
                                                              Пошел тестить, больше вам спасибо :)
                                                              • +1
                                                                Спасибо за проявленный интерес! Кстати, я решил дальше развивать, баг-фиксить и доделывать.
                                                                Если у Вас будут предложения или замечания — оставляйте на гитхабе.
                                                              • 0
                                                                Интерфейсы у вас сделаны талантливо. То, чего так нехватает опенсорсным хелпдескам.
                                                                С радостью попробю ваш проект, удачи. И не бросайте это дело :)
                                                                • +1
                                                                  В любом случае, автор молодец! Решил задачу собственными силами, при этом, как мне кажется, не имея достаточного опыта в разработке.
                                                                  Я тоже так начинал писать свой helpdesk, правда изначально был взят MVC и yii framework за основу, а понимание многих вещей пришло в процессе.
                                                                  • 0
                                                                    с удовольствием посмотрел бы на ваше решение. Можно ссылку на исходники?
                                                                • 0
                                                                  Интересная штука получилось, но очень нехватает добавления заявок через E-mail (pop/imap, файл).
                                                                  • 0
                                                                    Пишите на github.com/rustem-art/hd.rustem/issues/new — и Вас обязательно услышат, и сделают то что хотите.
                                                                    • 0
                                                                      Правильно ли я понимаю, что это больше хелпдеск для внутреннего пользования, нежели чем тикеты для саппорта клиентов?
                                                                  • 0
                                                                    Правильно понимаете. Клиенты как таковые могут даже не знать что у фирмы есть такая система, которая ведёт их учёт и число обращений и тп.
                                                                    • 0
                                                                      Мы создали белый список login/email. Суть его заключалась в следующем: человек при входе через web кликает на ссылку «первый вход», и вводит только свой ldap-логин. На его доменную почту приходит письмо с созданным паролем и ссылкой, на которую он переходит и получает полноценный доступ к системе.


                                                                      А почему так сложно? решение с доменной авторизацией (без хранения паролей в системе) и секьюрити группами почему не подошло? На мой вкус и проще и удобней и с блокировками в системах возиться не надо.
                                                                      • 0
                                                                        В новой версии мы сделали LDAP-авторизацию ;) И как раз по тому, что вы описали.
                                                                        В ближайшее время будет релиз.
                                                                      • 0
                                                                        Del

                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.