29.04.2003, 10:14 | #1 |
Участник
|
Текущая роль пользователя
Здравствуйте все!
Никто не подскажет - можно ли в C/AL коде получить роль текущего пользователя? Хотя бы ее название... Хотелось бы разграничить доступ к строкам таблиц по ролям руками - потому что стандартный механизм фильтрации таблицы прямо в роли тянет за собой некоторые проблемы... Со своими таблицами он еще проходит - а со стандартными не очень... Кстати - если кто-то решал такую проблему - не поделитесь подходом? C уважением! Сергей Андросов. |
|
29.04.2003, 11:44 | #2 |
Участник
|
можешь посмотреть темы "Роли в Attain" и "безопасность в attain" - там все это обсуждалось
|
|
29.04.2003, 12:01 | #3 |
Участник
|
Добрый день.
Я думаю можно попробовать так: 1. Определить globals: user: Code role: Code MemberOf: Record (MemberOf) 2. User := USERID; MemberOf.SETFILTER("User ID", User); if MemberOf.FIND('-') then Role := MemberOf."Role ID"; |
|
30.04.2003, 12:28 | #4 |
Участник
|
Re: Текущая роль пользователя
Цитата:
Изначально опубликовано Сергей Андросов
Хотелось бы разграничить доступ к строкам таблиц по ролям руками Цитата:
Изначально опубликовано Сергей Андросов
стандартный механизм фильтрации таблицы прямо в роли тянет за собой некоторые проблемы... Со своими таблицами он еще проходит - а со стандартными не очень... Цитата:
Изначально опубликовано Сергей Андросов
Кстати - если кто-то решал такую проблему - не поделитесь подходом? Все таблицы в Attain разделим на 3 вида: 1. Таблицы без SumIndexFields и без FlowFields 2. Таблицы с SumIndexFields 3. Таблицы с FlowFields С первым видом таблиц вообще никаких проблем не возникается (могут накладываться какие угодно фильтры, ошибок не будет), поэтому мы их не рассматриваем. Установление фильтров на таблицы второго типа, проблем при работе собственно c таблицей тоже не создает. Проблемы возникают только при работе с таблицами, которые содержать FlowFields, вычисляемые по таким таблицам. Как я уже писал, проблема возникает из-за того, что для вычисления значения FlowField система пытается прочитать данные закрытые фильтром безопасности. Решение данной проблемы содержится в самой технологии SIFT. Для того, чтобы ограничить набор записей, по которым вычисляется FlowField, нужно использовать FlowFilter. FlowFilter должен быть по тому же параметру, по которому устанавливается фильтр безопасности и иметь тоже значение что и фильтр безопасности. В вашем случае для ограничения доступа к операциям самым разумным будет использовать для фильтрации одно из глобальных измерений (для примера пусть это будет «Отдел»). Его значения – список подразделений (ЦО). Так как все операции в Attain содержат глобальные измерения в SumIndexFields, а все таблицы, содержащие FlowFields по операциям, уже содержат необходимые FlowFilter, то никаких изменений в системе делать не нужно. Далее создаются роли. По ролям устанавливаются фильтры безопасности по полю «Отдел Код» таблиц операций, а также по полю «Отдел Filter» таблиц, FlowField которых рассчитываются на основе записей таблиц операций. И в первом и во втором случае для одной роли указывается одно и тоже значение. Естественно, 100% гарантии не даю, но на небольших тестовых примерах (по бюджетам, финансовым операция) данный подход работает. |
|
30.04.2003, 12:56 | #5 |
Участник
|
этот подход верный только в отношении операций - но здесь тоже есть подвох.
нажав "показать все" - все операции и соответственно суммы становятся доступны. хотя если задача только в том чтобы пользователь просто не видел ненужной информации - то проблем нет. |
|
30.04.2003, 13:35 | #6 |
Участник
|
Цитата:
Изначально опубликовано Alex_V
этот подход верный только в отношении операций Даже если в таблице с FlowField нет нужного FlowFilter его намного проще добавить, чем переписывать код системы а затем еще иметь проблемы с обновлениями версий. Других ограничений у данного подхода я не вижу. Если это не так, то жду пример на базе стандартной функциональности. Цитата:
Изначально опубликовано Alex_V
но здесь тоже есть подвох. нажав "показать все" - все операции и соответственно суммы становятся доступны. Цитата:
Изначально опубликовано Alex_V
хотя если задача только в том чтобы пользователь просто не видел ненужной информации - то проблем нет. |
|
30.04.2003, 13:46 | #7 |
Участник
|
можешь попробовать на примере таблицы 374 - G/L Acc. Budget Buffer - она используется при отображении сумм по бюджетным операциям. Установи фильтр на поле Global Dimension 1 Filter (естественно должны быть бюджетные операции с данным кодом и значением измерения). при просмотре итогов - вываливаются все операции на кнопку "показать все" (это без всяких модификаций кода). И кстати по поводу сообщения - в ряде случаев оно выскакивает уже после того как отображены "недоступные" операции.
Ненужная информация - та которая просто не должна мозолить пользователю глаза. А есть еще понятие - недоступной информации - которую пользователь не может получить ни в каких случаях. |
|
30.04.2003, 14:15 | #8 |
Участник
|
Цитата:
Изначально опубликовано Alex_V
можешь попробовать на примере таблицы 374 - G/L Acc. Budget Buffer - она используется при отображении сумм по бюджетным операциям. Установи фильтр на поле Global Dimension 1 Filter (естественно должны быть бюджетные операции с данным кодом и значением измерения). при просмотре итогов - вываливаются все операции на кнопку "показать все" (это без всяких модификаций кода). И кстати по поводу сообщения - в ряде случаев оно выскакивает уже после того как отображены "недоступные" операции. Никаких перечисленных тобой симптомов не обнаружено. P.S. Поле "Отдел Фильтр" в форме бюджета недоступно для изменения P.P.S. Версия Attain 3.60.01 |
|
30.04.2003, 14:25 | #9 |
Участник
|
Что-то картинки не сохраняются
|
|
30.04.2003, 14:48 | #10 |
Участник
|
делал все аналогично - но результат - такой как я сказал (видим отфильтрованные по коду измерения но при нажатии показать все(в форме 120-G/L Budget Entries) - показывается все). плюс еще - при таком выставлении фильтров - в бюджетные операции(форма 120-G/L Budget Entries) нельзя добавить новую операцию - ф-ия GET которая используется для получения последнего номера - также ругается на права доступа.
|
|
30.04.2003, 15:43 | #11 |
Участник
|
Цитата:
Изначально опубликовано Alex_V
делал все аналогично - но результат - такой как я сказал (видим отфильтрованные по коду измерения но при нажатии показать все(в форме 120-G/L Budget Entries) - показывается все). |
|
30.04.2003, 15:49 | #12 |
Участник
|
да верно-моя ошибка - не уточнил. смысл в том что я его не ставил как раз по причине-нельзя добавить новые записи в этом случае. Установка фильтров на таблицы операций во всех случаях в конечном итоге приведет к ошибке нарушения прав доступа.
|
|
30.04.2003, 15:55 | #13 |
Участник
|
Цитата:
Изначально опубликовано Alex_V
да верно-моя ошибка - не уточнил. смысл в том что я его не ставил как раз по причине-нельзя добавить новые записи в этом случае. Установка фильтров на таблицы операций во всех случаях в конечном итоге приведет к ошибке нарушения прав доступа. P.S. Хотя может ты уже переписал весь Attain (см. безопасностьв Attain)? И мы говорим о различных системах? |
|
05.05.2003, 08:07 | #14 |
Участник
|
Забираю свои слова относительно того, что можно реализовать систему безопасности на уровне записи без модификации системы. Alex_V оказался прав. Т.е. технологически это возможно (на этом основывалось мое утверждение), но практика программирования, принятая в Attain, когда программисты пишут код в предположении, что они имеют доступ ко всей таблице, этому препятствует. Например, в нашем примере с операциями бюджета формировние ИД новой записи производится следующим образом (Table 96 G/L Budget Entry):
LOCAL PROCEDURE GetNextEntryNo@4() : Integer; VAR GLBudgetEntry@1000 : Record 96; BEGIN GLBudgetEntry.SETCURRENTKEY("Entry No."); IF GLBudgetEntry.FIND('+') THEN EXIT(GLBudgetEntry."Entry No." + 1) ELSE EXIT(1); END; Естественно, если этот код выполняется от имени пользователя, который не видит всех данных, то он будет работать некорректно. Аналогичным образом производится формирование ИД практически для всех операций :-(. |
|
05.05.2003, 11:31 | #15 |
Участник
|
именно это я и имел ввиду - просто переделывал сам подобные вещи - хорошо что задача оказалась небольшой по размеру
|
|
11.11.2004, 09:21 | #16 |
Участник
|
Средство безопасности на уровне записей
Нам удалось разработать средство, которое позволяет обеспечить доступ на уровне записей. Мы смогли разделить доступ к таблице "Фин. Книга Операций" по разным счетам. Т.е. в нашем случае пользователи получили доступ только к разрешенным счетам из плана счетов. Учетные процедуры работают без проблем.
Если кого-то интересует наше опыт, шлите письма по адресу albert@infosco.com |
|
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|