SQL Server Reporting Services, как наилучшим образом применять фильтры

Question

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

Пользователи приходят из разных отделов, и я хотел бы сделать это, поэтому каждый отдел может видеть только свои вещи.

Я не могу понять, как это сделать правильно.

У меня есть сейчас: - Модель, где я разместил фильтр в таблице заказов.

Фильтр может использовать GetUserID(), чтобы получить имя пользователя, но я не могу понять, как это получается из таблицы «UserDepartment», которая отображает пользователей в определенные отделы.

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

Любые подсказки?

(с помощью SQL Server 2008)

EDIT: Эта ссылка http://blogs.msdn.com/bobmeyers/articles/Implementing_Data_Security_in_a_Report_Model.aspx показывает основы того, что я пытаюсь сделать, но автор, кажется, предполагает, что каждая запись имеет поля UserName, которые могут быть согласованы.

В моем случае я хочу, чтобы все пользователи отдела X могли получить доступ к линии.

Answer 1

Предположим, что у Пользователей есть Ордена. Итак, фильтруйте пользователи, которые существуют в том же отделе, что и пользователь фильтра. Не фильтруйте заказы напрямую.

Я догадывался схемы и имена столбцов: hoep вы получите идею ...

SELECT 
    MY STuff 
FROM 
    Order O 
    JOIN 
    UserDept UD ON O.UserCode = UD.UserCode 
WHERE 
    EXISTS (SELECT * 
     FROM 
      UserDept UD2 
     WHERE 
      UD2.UserCode = @MYUSerCode 
      AND 
      UD2.DeptID = UD.DeptID) 

--or 
SELECT 
    MY STuff 
FROM 
    Order O 
    JOIN 
    UserDept D ON O.UserCode = D.UserCode 
    JOIN 
    UserDept U ON D.DeptID = U.DeptID 
WHERE 
    U.UserCode = @MYUSerCode 

Answer 2

То, что вы пытаетесь достичь трудно, используя метод GetUserID(). Чтобы использовать это ваш исходный запрос должен возвращать много избыточных данных, представьте себе что-то вроде следующего:

/* 
Table: User 
Fields: UserID, LoginName, FullName 

Table: Department 
Fields: DepartmentID, Name 

Table: UserDepartments 
Fields: UserID, DepartmentID 

Table: Order 
Fields: OrderNumber, DepartmentID 
*/ 

SELECT O.OrderNumber, O.DepartmentID, U.LoginName 
FROM Order O 
JOIN Department D ON D.DepartmentID = O.DepartmentID 
JOIN UserDepartments UD ON UD.DepartmentID = D.DepartmentID 
JOIN User U ON U.UserID = UD.UserID 

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

Теперь вы можете применить свой фильтр, как описано в приведенной ссылке. Это будет отфильтровано до одной копии строк заказа для текущего пользователя, если они находятся в правильном отделе.

Если это проблема с производительностью, есть и другие альтернативы, проще всего использовать локальный отчет (.RDLC) в ASP.NET, WinForms или WPF и передавать данные пользователя на вызов данных, чтобы фильтрация могла выполняться в SQL.

Answer 3

У нас была аналогичная проблема с этим, и в итоге я написал функцию в SQL.

Функция сделал следующее:

1. Полученное значение параметра имя пользователя из SRSS
2. Выполненный поиск по таблице разрешений и извлекаются записи (отдел идентификаторам в вашем случае).
3. вернулся в отделе идентификаторов

Тогда наш SQL заявление выглядит следующим образом:

SELECT * FROM ImportantData WHERE DepartmentID IN (SELECT Id FROM fn_GetUserDepartmentAllocations (@Username))

Это сделало заставляют нас модифицировать все запросы sql, но это позволило нам сделать это с минимальной сложной логикой.

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

CREATE FUNCTION [dbo].[fn_GetUserDepartmentAllocations] 
(
    @UserName NVARCHAR(100) 
) 
RETURNS 
    @TempPermissions TABLE 
(
    DepartmentId Int 
) 
AS 
BEGIN 

     INSERT INTO @TempPermissions  
     SELECT DepartmentId 
     FROM DepartmentPermissions 
     WHERE DepartmentAllowedUsername = @UserName 

    RETURN 
END 

Основное преимущество делать это таким образом, это также позволяет редактировать одно место, чтобы изменить всю структуру разрешений, вам не придется пройти через каждый и каждый отчет, чтобы изменить его, вместо того, чтобы изменить одно место

Например, у вас может быть менеджер, который принадлежит к 2 отделам, но не разрешено просматривать их, кроме как в четверг (я знаю глупый пример, но вы надеетесь, что найдёте).

Надеется, что это помогает

Пита