Pull to refresh

Comments 20

UFO landed and left these words here

Визуально — это очередная поверхностно подтюнингованная AdminLTE

Разве это плохо — использовать шаблон в своих разработках? Тем более, что он для этого и делался.

А что-то говорил про то, что это плохо? Просто проинформировал, что "красивости" не столь заслуга авторов helpdesk, сколь автора самой админки.

На главном скриншоте опечатка «груп». Еще одну П потеряли.
Тоже не работает. Вы хоть проверяйте что-ли. И надо отключать дебаг режим)
in Collection.php line 1045
at HandleExceptions->handleError('8', 'Undefined offset: 0', Collection.php line 1045
at Collection->offsetGet('0') in DashboardController.php line 123
Мне очень жаль, что среди порядочных Хабра-Пользователей находятся те, которые пишут матерные выражения в названиях групп и пишут политические тексты. Мы вынуждены закрыть демо. Если у кого-то есть прямое желание ознакомиться с новой версией — пишите на почту и мы любезно предоставим доступ.

Так совпало, что вы выкатили релиз первой версии в то время, как у нас на работе было решено внедрить хелпдеск. Большинство функционала пересекалось, поэтому было решено взять вашу версию за основу, но в итоге большая часть была переписана и добавлен новый функционал. Была добавлена авторизация по лдап + привязка еще к одной внутренней БД. Также полностью перерисовал интерфейс.
Сейчас подумываю также переписать все с использованием какого-нибудь фреймворка =)

Могу только скрины, т.к. находится в корпоративной локальной сети

А вы не планируете выкладывать на github например? Или себе только?
Некоторые проекты мы выкладываем: https://github.com/ZENLIX/LaraShop
А почему использовали Apple PUSH-server? Или у Вас не планируется клиент под Android? Почему для синхронизации с мобильной версией не использовали, например, Rabbit-MQ, или AWS DynamoDB / Google Firebase? Я почему интересуюсь оффлайн-синхронизацией, потому что столкнулся с подобным вопросом в своем проекте.
У нас не используется пока клиент под Android, но мы планируем его использование. Даже при этом, так как у нас единый сервер отправки PUSH-уведомлений, проблем с отправкой параллельно на Android-устройства не возникнет.
Мы используем https://github.com/davibennun/laravel-push-notification на нашем PUSH-сервере, а с него уже возможна отправка и на Apple Push, и на Android Push серверы.
Для синхронизации мы решили использовать именно API/json-обмен данными по запросу мобильного клиента. Не совсем понятно, каким образом можно использовать тот же Rabbit-MQ для синхронизации?
С помощью очередей и «потребителей». При добавлении/изменении/удалении объекта в очередь отправляется сообщение либо с ID объекта, либо объект целиком. Всё в json-формате. Удобно в том плане, что сообщение не пропадает, а лежит в очереди, пока его не прочитают веб/мобильные клиенты.
Мы это реализовали с помощью REDIS+NodeJS/Socket.IO для веб-нотификации. Нам не важны были оффлайн нотификации, они итак отражены в логах в связи со структурой проекта.
Мы хотим использовать beanstalkd для очередей, я не могу сказать поддерживает ли он весь тот функционал, как тот же Rabbit-MQ, но идея отличная.
Не страшно было делать проект с высокой нагрузкой на PHP-фреймворке? Если уже используете Node.js, почему не сделали весь Backend на нем (express.js, sequelize.js...)? Я сейчас делаю один проект на Laravel 5.1, но интересует Ваше мнение относительно выбранной технологии не только потому, что у Вас уже есть PHP разработчики. Была ли еще какая то причина?
Извините, если много вопросов задаю. Ищу полезные аргументы.
Спасибо за вопросы, наоборот задавайте, нам так же важно и Ваше мнение.
1. На данный момент проблем с использованием NodeJS — нет, это очень маленькая часть кода и функционала которая отвечает только за веб-уведомления. Поэтому затрат на дополнительные силы разработки nodejs — нет. На данный момент это не критический функционал системы, поэтому мы его не так сильно развиваем.
Если сравнивать прошлую версию 2.95 — там было его больше, например активности комментариев на странице заявок (автодобавление новых комментариев по тем же nodejs/socket.io push-событиям).
2. СтОит понимать, что для очереди сообщений мы используем БД (планируем либо REDIS, либо BeanstalkD). Для рассылки всплывающих уведомлений используем REDIS+NodeJS/Socket.IO.

Сама тема рассылки уведомлений и обработка их статусов для нас так же является важной. Мы например используем функционал уведомлений о последних событиях, но он отражается в БД, в качестве логов. Теперь будем смотреть в сторону rabbitMQ.
Only those users with full accounts are able to leave comments. Log in, please.