Pull to refresh

Comments 86

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

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

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

Jira очень generic система. Многих вещей там просто невозможно добиться по-человечески. Multiple assignments, например.
Ога — взять платную jira, выучить java, написать плагины. Отличный workflow.
UFO just landed and posted this here
Да есть такое, поэтому я сразу оговорился: для внутреннего использования. В плане безопасности, мы эту стадию пропустили. Поэтому буду рад, если кто-то заинтересованый в этом проекте внесёт свой вклад в это направление.
Мне казалось что в 2014 году увидеть собирание запроса руками, а не использование параметров вообще невозможно, ан нет. Но зачем? Что для MySQL + PHP нормальных провайдеров не изобрели еще что ли до сих пор?
Да есть, конечно. Например, в PDO.
классная штука! я только сейчас отсюда и узнал про такое решение)
Изобретено давным-давно. Также как различные фреймворки/шаблонизаторы/ORM.
Почему автор избрал такой путь – загадка.
Я не знаю как вы с этим спите. Я когда подобное сделаю, потом не могу спокойно жить. Меня постоянно грызет совесть. :)
факт, что продукт внутренний не исключает безопасность) Вы думаете, у вас мало людей, которые бы не отказались получить админ-доступ в систему тикета и невозбранно пограбить корованы?
Для тех кто любит собирать запросы руками (я сам люблю что уж там) я бы предложил использовать PostgreSQL с его $$-quoting. Можно писать запросы типа INSERT INTO names VALUES ($qt$Вася$qt$);

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

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

Впрочем я не навязываю, PDO тоже вариант, просто проинформировал автора что есть такая возможность.
Судя по указанному вами месту в доке, $$-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 что–то мы в оффтоп скатились, если есть желание, то приглашаю в личку.
Думаю в личку это плохая идея, если кто то найдет этот диалог то ему наверное будет интересно стоит использовать 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-иньекций. Разве нет?
является защищенным от SQL-иньекций. Разве нет?
Да я не об этом.
Ваш код чудесным образом можно (и нужно) переписать без dollar quoting
pg_query_params( 'INSERT INTO peoples ( name ) VALUES ( $1 )', array( $_POST[ 'name' ] ) );
Ну можно, например, вместо обращений к $_POST[] использовать filter_input(). Кстати, не слишком старые интерпретаторы будут это в ворнингах предлагать делать.
Вы не могли бы пояснить, что плохого в отмеченной строке?
А, всё ясно, спасибо!
Когда то, очень давно в своих велосипедах делал так:
<?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. Веселые были времена :)
Ну это как раз не очень хорошо :) Экранировать надо непосредственно перед постановкой в запрос. А то мало ли что ещё захочется со строкой сделать.
Я ж говорю, веселые были времена. Мне кажется, можно вообще не использовать экранирование, если делать приведение типов, например к int.
И к какому типу вы будете приводить строку вида «Вася Иванов»?
Давно придуманы плейсхолдеры с автоматическим экранированием.
Понятно, что все строки нужно экранировать. Я говорю о тех случаях, когда идет отбор по полю типа int, float, date и т.д. и т.п.
В современных реалиях приведение типов в запросе абсолютно ненужная вещь: этим занимается драйвер БД.
Инъекцию уже подправили.
Но таки да: стиль не айс, учитывая, что есть mysqli/PDO/ORM с вкусняшками, а mysql объявлен деприкейтнутым.
Можно добавить еще «Шаблоны заявки» т.к. часто есть группа однотипных заявок. И типовые решения с возможностью быстрой ссылки на Центр знаний.

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

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

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


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

Articles