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

Комментарии

• Stranger

  January 2005 отредактировано 18:23

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

  January 2005 отредактировано 18:23

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

  February 2005 отредактировано 18:23

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

  February 2005 отредактировано 18:23

  konstsch написал:

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

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

  February 2005 отредактировано February 2005

  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

  February 2005 отредактировано 18:23

  написал:

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

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