04.05.2017
Подводные камни в приложениях Bitrix24 и как их обходить
Несколько лет назад для управления задачами мы использовали последовательно несколько систем: ActiveCollab, Redmine, Zoho, Мегаплан. Потом надолго остановились на отличном решении Worksection. Когда его функционала стало не хватать - ушли от него в сторону Jira. В итоге остановились на Bitrix24, который близок к идеалу, но вот отчета о затраченном времени в стиле Worksection или плагинов для Jira в корпортале очень не хватало.
Собственно это и подвигло на разработку приложения отчетов для Bitrix24.
Первой неприятностью стало ограничение на количество запросов в секунду к API B24, которое звучит как “Разрешается два запроса в секунду. Если лимит превышается, то ограничение начинает срабатывать после 100 запросов.”
Вторым моментом который вызвал недоумение было отсутствие события при добавлении/изменении времени затраченного на задачу. При наличии события можно было бы использовать вебхуки и не мучать cron, но чего нет, того нет.
В результате было принято решение читать данные о задачах через API, хранить данные в MongoDB, а сами отчеты строить уже из MongoDB, не трогая Bitrix24 запросами.
В Базе Данных нам нужно хранить подразделения, пользователей, группы, задачи, время. Каждая сущность - коллекция (таблица) БД. Плюс к этому созданы три таблицы. Под настройки, ACL и уведомления.
Само приложения представляет из себя одностраничный сайт. Весь изменяемый контент генерируется на стороне сервера и доставляется в приложение посредством XHR.
Фронтенд приложения написан на bootstrap + jQuery. С Bitrix24 API работаем с помощью bitrix24-php-sdk
Интересный момент всплыл при работе с группами. Через API можно получить только те группы к которым относится пользователь API. При этом задачи из остальных групп доступны, а вот сами группы нет.
То есть для того чтобы приложение функционировало нормально, необходимо добавить пользователя, который устанавливал приложение, во все группы. Это конечно неприятно, но решаемо административными методами.
Перейдем собственно к разработке приложения.
Установка приложения (для разработчика)
До того как мы опубликуем приложение в Marketplace при установке нужно руками прописать:
- Путь к приложению
- Путь к инсталлятору
- Установить права доступа приложения
- Имя приложения
При установке приложения Bitrix24 обращается к скрипту инсталляции и передает в него все необходимые данные за исключением ID и ключа приложения.
После установки нужно будет прописать ID и ключ приложения в базу данных.
Для приложения размещенного в Marketplace выдаются ключи которые неизменны для всех установленных приложений.
Массив сохраняемых данных выглядит вот так
По сути из запроса нам нужны только:
- DOMAIN - url вашего bitrix24
- AUTH_ID - ключ по которому происходит авторизация (живет 1 час)
- REFRESH_ID- ключ по которому происходит получение нового AUTH_ID (живет 1 месяц)
Остальные данные неизменны и мы сами определяем их.
Как работает авторизация в API
Так выглядит код инициализация API B24
После этого нам нужно проверить жив ли наш ACCESS_TOKEN и если он уже истек, то обновим его. После чего запишем новые ACCESS_TOKEN и REFRESH_TOKEN
!!! REFRESH_TOKEN изменяется при запросе нового ACCESS_TOKEN и его тоже нужно сохранить в БД !!!
Вообще то установка ACCESS_TOKEN и REFRESH_TOKEN может происходить прямо из данных запроса (ниже есть пример как это сделать). Но валидные ключи есть только для загрузки приложения порталом Bitrix24. В дальнейшем же, для XHR, мы этих ключей не имеем. Поэтому была принята договоренность - после подключения API обновляем ключи.
Нужно отметить что приложение будет работать от пользователя который его установил. Даже в том случае когда оно используется другим пользователем. Это решает проблему с доступом к группам(см выше).
После того как мы подключились к API и получили однозначно работающий ключ, можно заняться самими запросами.
Например, вот так мы получим всех пользователей
А вот так задачи, измененные сегодня
О том, какие бывают запросы и что именно можно получить с помощью API, можно прочитать в официальной документации.
Документация по Bitrix24 API размещена тут
ACL в приложении
Реализация ACL была следующей задачей, которую хотелось решить.
На портале есть пользователи, которым не нужно приложение. В приложении есть настройки, которые не всем можно менять. Поэтому ACL - это жизненно необходимая вещь.
Т.к. приложение - это одностраничный сайт, определять ID пользователя будем один раз, при запуске приложения.
Для этого выполним нехитрую процедуру и получим ID
И далее в XHR передаем этот ID. Конечно, не только ID, а еще какой-нибудь хэш от ID и текущих прав пользователя, для пущей безопасности.
На стороне сервера мы проверим соответствие параметров запроса этому хэшу и при корректности выдадим права этому запросу.
Собственно, на этом можно и закончить.
Приложение Timereport будет опубликовано в Marketplace в ближайшие дни.
Будет полезно:
