Заметки
Как упаковать модуль для маркетплейса
Как упаковать модуль для маркетплейса: Корень архива, install, version, права.
Как упаковать модуль для маркетплейса. Основной фокус: Корень архива, install, version, права.
Задача
Разобрать поведение локального или OAuth-приложения, placement, слайдер или установку.
Задача — как упаковать модуль для маркетплейса. Корень архива, install, version, права.
Главное — не искать один универсальный метод, а сначала определить сущность, права и слой API, через который выполняется действие.
Как это устроено
Приложение работает внутри контекста портала: место встройки передаёт параметры, OAuth ограничивает права scope, а iframe накладывает ограничения браузера и безопасности.
В Bitrix24 права почти всегда считаются не одной настройкой, а комбинацией роли, группы, структуры, владельца, привязки к сущности и контекста текущего пользователя.
Если сценарий проверяется под администратором, отдельно повторите его под обычным пользователем. Для прав, CRM, задач, Диска и приложений это часто даёт другой результат.
Рабочий подход
Проверяйте установку приложения, handler URL, права, scopes и фактический результат BX24.placement.info. Для карточек CRM не просите пользователя вводить ID вручную — берите его из контекста размещения.
Сделайте минимальный тест на одной сущности, сохраните входные данные и ответ метода, а затем расширяйте решение на массовый сценарий.
На коробке удобнее добавлять временное логирование рядом с местом выполнения кода, а в облаке — сохранять входящие и исходящие REST-запросы в свой журнал интеграции.
Частые ошибки
Если после placement.bind открывается install.php, часто проблема не в самом placement, а в URL обработчика, незавершённой установке или старой записи размещения.
- Проверять сценарий только под администратором и не видеть проблему прав обычного пользователя.
- Пытаться решить доступ скрытием элемента интерфейса, хотя данные остаются доступны через другой путь.
- Не логировать фактический запрос и ответ, из-за чего ошибка выглядит случайной.