Рабочие отчеты - концепция идеи и практическое использование

Репортер на самом деле универсальный. Внедряется он примерно так: 1) необходимо описывать сущности; 2) необходимо писать бизнес-логику выборки данных; 3) необходимо делать публичный интерфейс к отчетам.

На примере задач: описаны сущности задача (модуль задач), пользователь (ядро). Логика выборки в основном упирается в права доступа - репортер должен получать только данные, к которым есть доступ, а не вообще все. В модуле задач в принципе выборки уже были. Созданы компоненты отчетов, которые по сути подключают компоненты репортера с нужными параметрами.

В основе работы репортера лежит принцип ORM. На основе описаний сущностей и связей между ними строится запрос к БД. Сущности могут быть из разных модулей. По нашей практике мы видим, что отчет "на заданную тему" может быть внедрен за пару рабочих дней. API опубликуем в начале следующего года.

Штатной возможности не предусмотрено, но при необходимости реализовать будет несложно. И все же хотелось бы двигаться в сторону развития конструктора запросов и ORM, а не обходных путей

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