v1.13.0

Авторизация 

Изменена зависимость регистра в логине пользователя

Теперь логин при авторизации будет приводиться к единому виду. Например: test, Test, TEST — все значения нормализуются к одному значению. Это уменьшает процент “ложных” отказов при входе из-за раскладки/копипаста/привычек набора.

Если в базе исторически существовали учётки, отличающиеся только регистром (например, test и Test), система автоматически переименует одну из записей, добавив префикс d1_, d2_ и т.п., чтобы обе учётки остались различимыми и доступными.

Проверка сложности пароля при регистрации пользователя

При регистрации/смене пароля включена политика надёжности: система оценивает пароль и блокирует варианты, которые не проходят минимальный порог безопасности.

Базовые требования: от 8 символов, наличие строчных и прописных букв, а также символов (спецзнаки). При несоответствии правилам возвращается ошибка — пароль не принимается. 

Менеджер проектов

Создание автодокументации по проекту 

Добавлена функция, которая формирует единый файл-отчёт по проекту. Документ собирается из ключевых частей проекта и даёт "снимок" конфигурации: страницы и их параметры/видимость, визуализации, источники данных, модели данных, ограничения RLS и скрипт загрузки. Удобно для ревью, передачи проекта, аудита и быстрого погружения без ручного обхода настроек.

Документ собирается по разделам (в фиксированном порядке), чтобы его можно было читать как техпаспорт проекта

• Страницы проекта — список страниц, размеры, фон (ссылка), видимость (скрыто/открыто), ограничения на уровне страницы (PLS) и ID.

• Визуализации проекта — по каждой странице отдельная таблица с виджетами: тип, название, координаты/слой (Z), размеры, видимость, блокировка, ID, модель данных и итоговый SQL (или отметка про виртуальные дан

• Источники данных — список источников, подключённые таблицы, статус задания на обновление (активно/неактивно) и расписание (cron-строка).

• Модели данных — связи внутри каждой модели: таблица/поле → тип join → таблица/поле.

• Ограничения RLS — правила, субъект (пользователь/группа), на какие модели распространяется, переменные/значения и статус (активно/неактивно).

• Скрипт загрузки — фиксируется текущая логика загрузки данных проекта.

Доступ к автодокументации открыт только ролям Админ и Разработчик.

Описание версии проекта

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

Редактировать/создавать комментарий может только автор изменений (кнопка доступна только ему). Если автор у версии не указан — возможность оставить комментарий доступна пользователям с правами управления проектом. Текст показывается в строке ограниченно, полный — во всплывающей подсказке. 

Уведомление об окончании лицензии

При входе в систему показывается предупреждение, если до окончания лицензии (в т.ч. “на публикации”) осталось меньше 15 дней. Это снижает риск внезапной остановки работы из-за просроченного ключа и заранее направляет пользователя к правильному действию (продление/обращение к администратору). 

Дополнительно в карточке/ячейке пользователя отображается роль и количество дней до окончания, а при критическом сроке появляется заметный индикатор с тултипом. 

Редирект скопированного/перемещенного проекта в указанный поток

После копирования или перемещения система автоматически перенаправляет пользователя в указанный поток.

Конструктор дашбордов 

Экспорт проекта в PDF

Добавлена выгрузка проекта в единый PDF-файл (в том числе из нескольких страниц). Система формирует PDF последовательно по страницам проекта, сохраняя реальные размеры каждой страницы. 

Для контроля источника выгрузки на первой странице файла фиксируются логин пользователя и дата/время экспорта (водяным знаком). Готовый файл сохраняется на устройство, а при необходимости может быть отправлен на указанную почту.

Опция отправки на почту доступна для пользователя, чей email внесен в сведения об учетной записи. 

Режим презентации при просмотре проекта

Добавлен режим презентации для просмотра дашборда в формате "слайдов" — с полноэкранным отображением и автопереключением страниц.

• Запуск/остановка: на верхней панели справа (рядом с профилем/чатом) доступна кнопка Play для запуска и Stop для завершения режима.

• Настройка интервала: при запуске задаётся время между переходами в секундах (по умолчанию 60 сек). Интервал один общий для всего показа — нельзя задавать разное время для разных страниц.

• Последовательность страниц: страницы переключаются строго по порядку в проекте. Управлять сценарием показа можно только перестановкой страниц в структуре проекта.

• Логика таймера: при переходе на другую страницу (включая ручной) отсчёт таймера начинается заново, чтобы переключения были предсказуемыми.

• Доступность: режим доступен в том числе для роли Зритель и при активации переводит просмотр в полноэкранный режим.

Авторефреш страницы 

Добавлено автообновление данных без перезагрузки UI: по таймеру выполняется запрос данных через стандартный запрос get_data. Интервал задаётся в секундах, минимально допустимый — 60 сек (если указать меньше — значение автоматически поднимается до 60). 

Автообновление синхронизировано с пользовательскими действиями: при любом ручном обновлении данных (например, фильтрация/смена параметров) таймер сбрасывается, чтобы не накладывать запросы друг на друга.

Диспетчер данных

Коннектор к Битрикс 

Бизнес-требования

https://apidocs.bitrix24.ru/api-reference/

• У открытого API есть ограничения:
  • Есть несколько разных тарифов, ограничивающих кол-во строк в запросе
  • Необходимо ставить задержку между запросами, чтобы не получать эту ошибку
  • Все ошибки возвращают код, по которому их можно идентифицировать и выводить в интерфейсе:
    • Лимиты 
• Для авторизации нужны API-key, логин и пароль
  • или API-key и домен первого уровня (адрес состоит из названия битрикса пользователя и фиксированного домена)
  • API-key можно получить с админского аккаунта в настройках
• Нужны все GET-методы из CRM:
  
  • Сделки
  • Лиды
  • Контакты
  • Компании
  • Коммерческие предложения
    • Нужен один GET из БП и роботов – Получить список бизнес-процессов
    • Нужны три GET из Задач:
      • Поля задачи
      • Получить список задач
      • История задачи
    • В параметрах запроса должна быть возможность указать, с какой даты загружать (обязателен для заполнения)
    • Учесть оптимизацию запросов
    • Предупреждать пользователя о лимитах
    • Выбирать поля для фильтрации через раскрывающийся список, а не ручным вводом (на изучить, если есть возможность получать из Битрикс список полей)
    • Тестовое подключение
    • Предпросмотр результата

  • Решение

    *Все параметры, вводимые пользователем в интерфейсе, в запросах указаны в угловых скобках: <ПАРАМЕТР>

    Ограничения API

    Интенсивность запросов:

    • Каждый входящий запрос от приложения увеличивает условный "счетчик запросов" на стороне Битрикс24
    • Как только значение "счетчика" превышает пороговое значение Х, каждый следующий входящий запрос блокируется. Приложение в ответ получает статус  503 с кодом ошибки Query_limit_exceeded
    • Параллельно значение счетчика автоматически уменьшается на Y раз в секунду
    • Значения X и Y зависят от тарифного плана в Битрикс:
      • 5 и 250 для тарифа Энтерпрайз
      • 2 и 50 для остальных тарифов (ориентируемся на этот вариант)
    • Битрикс24 учитывает только IP-адрес, с которого происходит обращение при выполнении REST-запроса. Ограничение на интенсивность запроса общее для всех клиентов, работающих с одним Битрикс
    • Запрос не равен записи из таблицы. Метод list позволяет получать по 50 записей, а метод batch может содержать 50 запросов по 50 записей

    Ресурсоёмкость:

    • В облачной версии Битрикс24 во всех ответах REST-запросов в массиве time с дополнительной информацией о времени выполнения запроса добавлен дополнительный ключ operating, который говорит о времени выполнения запроса к конкретному методу
    • При превышении общего времени выполнения запросов сверх 480 секунд в рамках прошедших 10 минут данный метод блокируется для всех приложений
    • Все остальные методы продолжают работать

    Исходя из данных ограничений должен быть использован метод batch

    Особенности API

    1. Пагинация по параметру start – указывает смещение в итоговом наборе данных после применения фильтров. Шаг – 50 строк

    2. Если после фильтрации строк меньше 50 (страница), подзапрос с большим start возвращает первую страницу данных повторно – это не ошибка.

    3. Нет возможности заранее узнать точное количество строк после фильтрации.

    4. Batch-запрос содержит до 50 подзапросов.

    5. На один batch-запрос можно получить максимум 2500 строк (50 запросов * 50 строк).

    UI/UX + логика обработки запросов коннектора в системе

    Интерфейс

    Новый тип источника – Bitrix24

Внутреннее окно источника:

• Название – "Новое подключение"
• Поле ввода "Название подключения"
• Поле ввода "URL вебхука"
• Текст – "Как получить данные для подключения" в виде гиперссылки
• Кнопка "Назад"
• Кнопка "Далее"

Все поля обязательны для заполнения

Следующее окно для выбора сущности:

В первой версии для реализации предлагается выгружать все доступные поля из источника (благо на их количество нет никаких ограничений) и производить исключение ненужных столбцов уже в таблице выбора данных на стороне FB

• Название – "Новое подключение"
• Текст – "Выберите источник данных в системе"
• Раскрывающийся список "Источник", содержит в себе значения "CRM", "Задачи", "Бизнес-процессы", "Copilot". По умолчанию стоит "CRM"
• Раскрывающийся список (без названия), появляется только если в предыдущем списке выбран вариант "CRM", содержит в себе значения "Сделки", "Лиды", "Компании", "Коммерческие предложения", "Смарт-процессы". По умолчанию стоит "Сделки"
• Чекбокс "Прерывать последовательность запросов в случае ошибки", по умолчанию активен
• Текст – "Фильтры"
• Строка фильтрации (следующие компоненты в одну строку):
  • Поле ввода "Поле" (по умолчанию в первое поле должно быть введено "DATE_CREATE")
  • Раскрывающийся список (без названия) со значками:
    • = (по умолчанию)
    • != (в коде "!")
    • >=
    • >
    • <=
    • <
    • LIKE (в коде "%")
    • Поле ввода "Значение"
  • Кнопка "Добавить" (например, "+")
  • Кнопка "Удалить" (можно удалить даже первое условие)
• Кнопка "Тестовое подключение"
• Кнопка "Предпросмотр"
• Кнопка "Создать"
• Кнопка "Назад"

Все поля обязательны для заполнения (и в фильтре, если строки фильтрации добавлены)

Окно предпросмотра результата:

• Полностью аналогично окну предпросмотра файла без всех управляющих кнопок:
  • Расположено справа от настроек окна выбора сущности
  • Содержит в себе результат выполнения ограниченного запроса – столбцы с данными
    

    

    
    

Логика

При нажатии на источник "Bitrix24" открывается внутреннее окно источника

Внутреннее окно источника:

• В поле "Название подключения" вводится название, которое будет отображаться в списке коннекторов и использоваться в скрипте загрузки
• В поле URL вебхука вставляется готовый URL вебхука из Битрикс24
• Гиперссылка "Как получить данные для подключения" ведёт на документацию с алгоритмом создания вебхука в Битрикс и получения данных для подключения
• Кнопка "Назад" возвращает пользователя в окно выбора типа источника
• Кнопка "Далее" запускает проверку корректности вебхука:
  • Выполняется GET-запрос к указанному URL вебхука с минимальным тестовым запросом (например, получение одной записи или метаданных)
  • Если ответ содержит корректные данные (HTTP 200 и валидный JSON), подключение считается успешным
    • Открывается окно выбора сущности
  • Если ответ содержит ошибку (например, 403, 404 или невалидный формат), отображается сообщение об ошибке с предложением проверить URL

Окно выбора сущности:

*Здесь описано, куда попадают данные из интерфейса. Правила формирования запроса см. после данного подраздела

• С помощью списка "Источник" выбирается один из методов Битрикс АПИ (см. про каждый метод в разделе "Объекты для выгрузки")
• Второй раскрывающийся список служит для уточнения метода для CRM (в остальных вариантах пока что доступен только один метод)
• Чекбокс "Прерывать последовательность запросов в случае ошибки" передаёт в параметр "halt" значение 1 (если чекбокс активен) или 0 (если неактивен)
• Строка фильтрации формирует условие filter для ограничения данных для поля согласно операнду по значению
  • Все операнды в запросе эквиваленты вариантам из списка для пользователя, за исключением "не равно" (!=) и "как" (LIKE). "Не равно" записывается в формате "!", а "как" в формате "%".
  • Поле нечувствительно к регистру, условие чувствительно к регистру
  • Можно вводить несколько условий: для этого есть кнопка "Добавить" – создаёт ещё одну строку фильтрации со значениями по умолчанию
  • При создании новой строки все элементы модального окна сдвигаются вниз. Когда число таких строк достигает 4, для всех новых строк добавляется прокрутка в окне, а элементы модального окна перестают сдвигаться
    • Пример – окно ввода границ для цвета по значению (после добавления 4 появляется прокрутка)
      

      

      
      
  • Кнопка "Удалить" появляется при наведении курсора на существующую строку. При удалении не спрашивается подтверждение, все последующие строки сдвигаются на одну вверх
• Кнопка "Создать" отправляет запрос и формирует подключение к Битриксу (новый источник)
  • Если какие-то из параметров указаны неверно (подключение не может сформироваться), то показываем пользователю сообщение: "Не удалось установить подключение. Получена ошибка:" + ответ с ошибкой
• Кнопка "Назад" возвращает во внутреннее окно источника Битрикс
• Кнопка "Тестовое подключение" при нажатии отправляет пустой POST-запрос к Битрикс и ожидает ответ без ошибки.
  • Если в ответ приходит ошибка, то показываем сообщение: "Не удалось установить подключение. Получена ошибка:" + ответ с ошибкой
  • Иначе показываем сообщение "Подключение успешно"
• При нажатии на кнопку "Предпросмотр" отправляется точно такой же запрос, как и при нажатии на кнопку "Создать", но:
  • Устанавливается ограничение (Limit) на 100 строк
  • Источник не создаётся, окно остаётся открытым
  • В случае успеха ответ заменяет предыдущий результат в области предварительного просмотра (справа от настроек)
  • В случае ошибки показываем пользователю сообщение: "Не удалось установить подключение. Получена ошибка:" + ответ с ошибкой
  • До первой успешной попытки предпросмотра область справа будет пустой

Параметр "start" используется только для пагинации при последовательной выгрузке и не поддерживает прямое ограничение по диапазону записей (например, с 458 по 8162)

Формирование запроса (В1)

Данный вариант формирования запросов на 100% проверен и работает, но может быть неоптимален на больших объёмах данных. 

Правила формирования batch-запроса

Для любого метода формируется POST-запрос:

https://<URL_вебхука>/rest/batch

Таким образом вызывается метод batch, который содержит в теле запроса:

• "halt" – параметр, определяющий, нужно ли прерывать серию запросов в случае ошибки хотя бы в одном из них
• "cmd" – совокупность подзапросов, из которых состоит batch, с шагом 50 (параметр start)
• "auth" – параметр авторизации, в него передаётся Access-Токен, полученный при авторизации подключения к конкретному Битриксу

В каждый подзапрос добавляется фильтр согласно параметрам из интерфейса

Пример запроса, в котором:

• Метод – CRM-Сделки
• Фильтр: TITLE = 3
• Две страницы данных

Обработка и дозагрузка данных

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

• Накапливать все полученные строки
• Отслеживать уникальные значения ID
• При получении повторяющихся ID считать, что данные закончились – сохранять полученный до повторяющихся ID результат и заканчивать загрузку

Так, единственным флагом для окончания загрузки будет повторение уникальных значений ID. Следовательно, в случае ошибки разработки (например, если одинаковые ID не будут найдены, что по логике невозможно) загрузка зациклится – необходимо учесть этот момент и не допускать ошибок)

Подобное завершение загрузки будет работать, потому что при завершении списка строк для загрузки следующий start вызовет самую первую страницу, и ID повторятся.

За один запуск можно отправлять до 50 batch-запросов, поэтому необходимо:

• Запрашивать batch-запросы последовательно, смещая start в последующих запросах на последний start из предыдущего:
  • При первом вызове отправлять до 50 batch-запросов
  • Каждый новый вызов производить не чаще чем раз в 0,5 сек (см. ограничения API)
  • В каждом новом вызове максимум один batch-запрос
• Останавливать загрузку, если на очередном batch-запросе не появляется ни одной новой строки

При этом в интерфейсе источник создаётся сразу после нажатия на кнопку "Создать". Формируется новый коннектор в списке со статусом "Занят" до тех пор, пока не завершится дозагрузка данных

Формирование запроса (В2)

Существует более быстрый способ получения больших объёмов данных, который описан в документации Битрикс:

https://apidocs.bitrix24.ru/settings/performance/huge-data.html

Требуется дополнительный ресерч!

Результат

• Для обоих вариантов результатом загрузки должен являться массив объектов с уникальными записями.

• Результат сохраняется в БД (аналогично файловому источнику)

Редактирование подключения

При редактировании подключения открывается окно выбора сущности (последнее), кнопка "Создать" заменяется на "Сохранить".

Все измененные параметры перезаписывают созданное подключение при нажатии на кнопку "Сохранить". Список доступных для изменения параметров аналогичен созданию подключения.

Объекты для выгрузки

Всего в Битрикс24 используется множество различных сущностей, из которых можно получить данные. Для каждой сущности (CRM, Задачи, БП) используется типовой списочный метод, который подставляется в запрос. При создании коннектора можно выбрать одну конкретную сущность.

Список методов:

• CRM:
  • Сделки – crm.deal.list
  • Лиды – crm.lead.list
  • Контакты – crm.contact.list
  • Компании – crm.company.list
  • Коммерческие предложения – crm.quote.list
  • Смарт-процессы – crm.type.list
• Задачи – tasks.task.list
• Бизнес-процессы – bizproc.workflow.instance.list

Многопоточная загрузка

Проблема

Для реализации многопоточности для ускорения загрузки данных необходимо определить поле, по которому будет происходить разделение на потоки. Поле должно содержать только уникальные данные – это и необходимо определять в рамках этого решения.

Цель минимум – ускорить импорт больших файлов (от 1 млн строк) в реализации на Go как минимум в 2 раза по сравнению с загрузкой на node.js

Цель максимум – реализовать загрузку файла объёмом 2+ млрд строк менее чем за 1 час

Бэкенд

Поиск подходящих столбцов – [ЭНДПОИНТ_ПЕРВЫЙ_ПОИСК]

Node.js формирует список задач из SQL-запроса в скрипте загрузки и отправляет их на Go (POST /v1/find-unique-columns). Go-сервис:

• Парсит все таблицы
• Оставляет только "простые" (без подзапросов, join, union) – отмечает как "неподходящие"
• Исключает таблицы, у которых меньше 100 000 записей – отмечает как "неподходящие"
• Выполняет "исключающий" поиск – определяет столбец который точно подойдёт по метаданным и группировкам:
  • Если столбец является полностью уникальным (задано условие в СУБД), то он подходит
  • Рассматриваются также наборы из нескольких столбцов: набор из всех столбцов, участвующих в группировке, всегда будет уникальным
• Собирает IndexList из точно подходящих столбцов (Specify = False) и остальных столбцов (Specify = True) и возвращает в node.js

Node.js возвращает список таблиц и столбцов (вместе с их типами данных) на фронт (разделяя подходящие и неподходящие)

Сохранение списка настроек – [ЭНДПОИНТ_СОХРАНЕНИЕ_НАСТРОЕК] 

Для данного проекта записываются все полученные флаги. В запросе на запуск скрипта POST /v1/execute передаются настройки для каждой таблицы:

• isMultithreading
• isFullColumnCheck
• Список столбцов для разделения

• Запуск скрипта в несколько потоков

  При запуске скрипта для каждой таблицы, у которой флаг isMultithreading = True должна выполняться многопоточная загрузка данных по:

  • Столбцу, указанному пользователем в настройках 
  • Столбцу, определенному при полном поиске подходящих столбцов

  Если столбец не указан и не найден, то выполняется однопоточная загрузка

  Ручной запуск и запуск по CRON-заданию имеют свои (различающиеся друг от друга) настройки многопоточности! Необходимо для ручного запуска брать свой набор настроек, а для CRON-задания свой (или грузить в один поток, если для CRON-задания не было отдельно настроено правило многопоточной загрузки)

  
  

  Фронтенд

  Кнопка "Настройки импорта":

  Расположена:

  • Рядом с кнопками "Сохранить скрипт" и "Запустить скрипт"
  • В настройках CRON-задания в модальном окне, вызываемом при нажатии на кнопку "Обновление данных" в скрипте загрузки
  • В настройках CRON-задания в модальном окне, вызываемом в панели администратора

  Действие:

  • При нажатии на кнопку выполняется проверка скрипта на сохранение:
    • Если скрипт не сохранен появляется модальное окно
    • • Название окна: "Управление потоками"
      • Текст:  "Обнаружены несохраненные изменения в скрипте загрузки. Для разделения скрипта на потоки необходимо сохранить все изменения"
      • Кнопка "Сохранить" – при нажатии выполняет стандартный PUT 
        https://fastboard-front-dev.fb-dev.winsolutions.ru/back/api/v1/script, после которого выполняется проверка на существование сохраненных настроек
      • Кнопка "Отменить" – при нажатии возвращает пользователя в скрипт загрузки без сохранения и без открытия следующего окна
    • Если скрипт сохранен, то выполняется проверка на существование сохраненных настроек
  • Проверка на существование сохраненных настроек:

Пагинация источников в скрипте загрузки 

Автокомплит в REST API

Баги и мелкие фичи

Выбор типа календаря

Создание источника с названием, которое уже используется (поменяй название)

Проблема

1. В окне импорта нельзя создать источник, если существует другой источник с данным названием
2. При попытке выполнить это действие с учётки разработчика, у которого нет доступа к существующим файлам, появляется некорректная ошибка "У вас нет прав читать данный источник" 

P.S. по всей видимости, сначала выполняется проверка на существование источника на фронте (поскольку запроса на бэк не отправляется, если источник доступен), а если источник не найден в списке загруженных, то кидается запрос на бэк, который возвращает ошибку. Возможно, имеет смысл всегда отправлять все запросы на проверку на бэк, и, если нет доступа, предлагать юзеру перезаписать существующий источник

Решение

Расположение: Скрипт загрузки → Создать подключение → Файл

НЕ ВНЕСЛА:

Объединение запросов по get_data (+SSE на node.js)