detaildata и права на таблицы

konstsch

как все таки можно организовать небольшую логику в отчете.

например есть несколько detaildata связанные с таблицами БД(и соответсвенно с правами на эти таблицы)
Как сделать так, что если прав на чтение данных нет, просто не строить этот DetailData а пропустить?

Stranger

Проверить есть ли права на чтение и не строить

konstsch

дак это понятно.
хотелось бы примерчик.

а то очень много всего не понятного, я конечно могу задать кучу тупых(для вас, для меня актуальных) вопросов.
т.к. непонятно очень много, например:
создавать отчет в ручную в onManualBuild, или просто при проверки прав уничтожать бэнд-ы; как сделать что бы query сам не переходил в активное состояние(у меня он почему делается активным) и т.д. и т.п.

Vano

2 konstsch:

Позвольте и мне вставить свои 5 копеек.
Первое - Чем плохо то, что пользователю покажется сообщение об ошибке, что у него нет прав на таблицу, по которой строится отчёт ?
Второе - если вы ограничиваете пользователя на уровне базы данных, то почему нельзя его ещё ограничить на уровне отчётов (чтобы он не пугался ошибок о нехватке прав на SELECT) ?
И наконец третье - представим такую ситуацию: ты всё таки "победил" проверку прав при построении отчёта, пользователь построил "кастрированный" (а больше его никак нельзя назвать )) отчёт и принёс его директору. Затем другой работник с ДРУГИМ набором прав построил тотже самый отчёт уже со своими "кастрированными" данными. Теперь собственно вопрос - кого следующим вызовет к себе директор ? Ответ - программиста !!! Т.к. директор видит перед собой 2 "одинаковых" отчёта, но с СОВЕРШЕННО разными данными и будет у директора с этим программистом долгий секс с выяснениями кто имеет какие права на доступ и в какие места )

Stranger

konstsch написал:

т.к. непонятно очень много, например:
создавать отчет в ручную в onManualBuild, или просто при проверки прав уничтожать бэнд-ы; как сделать что бы query сам не переходил в активное состояние(у меня он почему делается активным) и т.д. и т.п.

Датасеты открывать ручками после проверки, ненужные компоненты делать невидимыми. Имхо этого достаточно. Но возможны варианты.

Вано, разговор про детейл идет - в одном отчете директор увидит только суммы, а в другом их же, но с расшифровкой

konstsch

Registation: TfrxDBXQuery

procedure DetailHeader1OnBeforePrint(Sender: TfrxComponent);
begin
    Registation.Active:=false;
    DetailHeader1.Visible := False;
    DetailData1.Visible := False;
end;

Ругается: "Cannot perfom this operation on a closed dataset "

to Vano

написал:

если вы ограничиваете пользователя на уровне базы данных, то почему нельзя его ещё ограничить на уровне отчётов (чтобы он не пугался ошибок о нехватке прав на SELECT)

дак это и пытаюсь сделать

написал:

И наконец третье - представим такую ситуацию: ты всё таки "победил" проверку прав при построении отчёта, пользователь построил "кастрированный" (а больше его никак нельзя назвать )) отчёт и принёс его директору. Затем другой работник с ДРУГИМ набором прав построил тотже самый отчёт уже со своими "кастрированными" данными.

узко мыслите

konstsch

написал:

procedure DetailHeader1OnBeforePrint(Sender: TfrxComponent);
begin
    Registation.Active:=false;
    DetailHeader1.Visible := False;
    DetailData1.Visible := False;
    DetailData1.DataSetName:='';
end;

Сделал так ошибку выдавать перестал.
Но я так и не понял почему Query все равно открывается и если нет прав выдает ошибку.
Свойство opendatasource=false;