[Pustik]

to ALL
В заключении темы хочу предоставить отчет о том, что у нас получилось. Я просто перечислю что мы смогли сделать , что нет . Для сравнения возьму проект Mazzy на его ссылке. Изначально методология у нас была идентичной, только конечно грамотность написания кода у нас на порядок ниже ). Мастер есть мастер. Но тем не менее есть и преимущества и недостатки. Может быть эта информация поможет кому – нибудь.

Преимущества :
1) В своем статическом методе настройки фильтра мы используем изменение не только Query(), но и QueryRun().Query(), что позволяет нам закрыть дырки для пользователей, используя функцию <Найти>. В проекте Mazzy пользователь все-таки может обойти даже заблокированные фильтры. Тема <работа Range на форме>.

2) В этом же методе Mazzy использует запрос вида :
while select accessRecordList
join userGroupList
where userGroupList.userId = = userID
&& ( userGroupList.groupId = = accessRecordList.groupID
|| userGroupList.userId = = accessRecordList.userID )
join TmpSysQuery
where accessRecordList refTableID == tmpSysQuery.Table_Id
{…………..уст-ка фильтра………….}
Мы все-таки посчитали, что это не совсем корректно, ведь получается, сколько раз UserId встречается в таблице userGroupList, - столько раз и установится этот фильтр.
Конечно фильтры “!A” и “!A,!A,!A,!A” ,будут возвращать один и тот же результат , но согласитесь……

У нас все гораздо проще:
while select accessRecordList
where accessRecordList.userId = = userID &&
!accessRecordList.GroupId
{…………..уст-ка фильтра………….}

3) Разделение SQL – запроса , о котором говорилось выше, на два (для пользователей и групп пользователей), позволило нам более понятно, динамично и рационально настраивать фильтры в нашей настроечной форме. А именно:

while select userGroupList where usergrouplist.userId = = UserId
{
while select forceplaceholders accessRecordList where
accessRecordList.GroupId = = userGrouplist.groupId &&
!accessRecordList.UserId
{…………..уст-ка фильтра………….}} – для групп пользователей


while select accessRecordList
where accessRecordList.userId = = userID &&
!accessRecordList.GroupId
{…………..уст-ка фильтра………….} – для пользователей

Например: пользователь Иванов относится к группе ‘Технолог‘
Задача1: группа ‘Технолог’ видит: A,B,C,D
польз. Иванов видит: только A

и наоборот
Задача2: группа ‘Технолог’ видит: A
А вот польз. Иванов видит: A,B,C,D

У нас обе Задачи легко настраиваются, а главное настройка очень понятна самому настройщику.
Пытался настроить Задачу2 в проекте Mazzy -- честно говоря, так и не удалось.

Недостатки :
1) Для того, что бы использовать изменение QueryRun().Query() , нам пришлось передавать параметр FormDataSource. Это конечно не так динамично как у Mazzy. Т.е. нам приходиться в каждой форме, где необходимо устанавливать фильтр прописывать строку(например для справочника номенклатуры) :
MY_RLS::updateQuery(InventTable_ds); в то время как у Mazzy :
AccessRecordList_maz::updateQuery(this.query());
Таким образом, наш код в ядро не пропишешь.
2) Еще один большой недостаток. Предположим на какое-то поле нужно наложить фильтр типа A,B,C,D. В нашем случае по этому полю не будет работать поиск. Т.е. если пользователь захочет отфильтровать записи по этому полю только для A, он все равно получит A,B,C,D, - но никогда пользователь не увидит Е,F.. и т.д.. У Mazzy это сделать можно, но и найти E,F для пользователя не составит большого труда. Как сделать идеально, мы так и не придумали. Но главное для нас что бы пользователь не смог видеть то , что ему не положено , а искать можно и по другим полям , или на худой конец , пользоваться услугами сортировки.

Может быть я в чем то не прав , это только моя точка зрения , правда подкрепленная тестированием.

Буду рад, если эта информация кому-нибудь поможет.