Если Вы когда-либо создавали запросы SelectQuery с CustomSQL-колонками, Вы наверняка обратили внимание на то, что запрос, прекрасно работающий под учетной записью администратора может оказаться нефункциональным под учетной записью пользователя, если в CustomSQLColumn используются таблицы, администрируемые по записям.
При этом обращение к тем же таблицам средствами дизайнера отчетов вполне успешно. В чем же секрет?
Дело в том, что если таблица администрируется по записям, дизайнер запросов при работе под пользователем автоматически подставляет вместо нее представление. А поскольку CustomSQL-колонки вставляются в запрос как есть, в результате у пользователя нет доступа к таблице, и есть доступ к предоставлению.
Схема работы:
Для того, чтобы запрос работал корректно, следует в CustomSQLColumn использовать не таблицу, а ее алиас, заданный в блоке FROM. В случае необходимости - присоединить таблицу в одном из JOIN-ов и также обращаться по алиасу.
Есть еще один способ - сразу указать в CustomSQLColumn представление таблицы. Однако такой способ медленнее, кроме того, запрос станет нефункциональным, если Вы отключите администрирование по записям.
В любом случае, при создании запроса в дизайнере постарайтесь все то, что можно реализовать минуя SQL-колонки сделать штатными средствами, и использовать их только для не реализуемых вычислений.
В том, что сделано при помощи дизайнера, разработчики могут добавить дополнительные проверки, а за запрос, написанный в CustomSQLColumn отвечаете лично Вы.
