forum.clarionlife.net

Идея в следующем. В таблице записать USE: переменные процедуры (ресурсы). Они же являются ключами.
Поиск по имени USE: переменной. Также таблица Users (пользователи). Таблица соответствия IdUser и IdUse
(рес-польз.). Сначала сканируются процедуры приложения (где нужен ограниченный доступ), и запись в таблицу.
В отдельной программе вводятся User-а (пользователи) и устанавливаются права доступа к ресурсам,
которые в таблице с USE: (ресурсы). При работе программы, при открытии Window, сканируются USE: ,
по имени находятся в таблице (ресурсы), по IdUse и IdUser в таблице (рес-польз.) проверяются права доступа.
Для этого и нужны значения USE: . Может кто подскажет, как организовать обход процедур приложения
для занесения их в таблицу процедур. Чтобы получить IdProc, а по ним IdUse в процедуре.
При запуске программы, то что доступно User в Queue. Поэтому должно работать быстро.
Немного сумбурно, ну как-то так. Если что-то получится, сделать доступным для всех. Ну пользуемся же мы
DecimalDot, ConvertDigitToStringSum, OneProcOneTime и прочее, за что огромное спасибо авторам.
Доступ тоже получается как стандартный, если Гуру сделают шаблон вообще будет здорово.
Мне пока не по силам, учусь.

Это надо задавать права на каждый контрол в каждой процедуре? А если контрол или процедуру переименовали?
А администратору доступа ковыряться в идентификаторах процедур и контролов? Не цимес...

Yufil писал(а):Это надо задавать права на каждый контрол в каждой процедуре? А если контрол или процедуру переименовали?
А администратору доступа ковыряться в идентификаторах процедур и контролов? Не цимес...

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

Попроще как-то надо. Мировая тенденция - простой интерфейс. Каждый контрол в каждом окне - это чересчур. У меня в разработках как правило парадигма Броуз-форма (или EIP), Броуз может иметь кнопки Insert, Change, Delete, View. На них и вешать доступ. Ну и сам Броуз на просмотр. Что ещё надо?

kreator писал(а):Попроще как-то надо. Мировая тенденция - простой интерфейс. Каждый контрол в каждом окне - это чересчур. У меня в разработках как правило парадигма Броуз-форма (или EIP), Броуз может иметь кнопки Insert, Change, Delete, View. На них и вешать доступ. Ну и сам Броуз на просмотр. Что ещё надо?

Простой пример, как решить такую задачу выше указанным принципом, если есть закупочные(входящие) цены и продажные(отпускные), закупочные цены + продажные видит одна группа пользователей, а только продажные видит другая. И таких примеров куча . Буду рад, если подскажите простое решение

Два полномочия - "Видит закупочные цены", "Видит продажные цены", включаем в окно главного меню
В зависимости от наличия полномочий устанавливаем глобальные флажки и показываем то, что надо...
Придётся всё-таки выковыривать шаблон и всё, что с ним связано

gopstop2007 писал(а):Простой пример, как решить такую задачу выше указанным принципом, если есть закупочные(входящие) цены и продажные(отпускные), закупочные цены + продажные видит одна группа пользователей, а только продажные видит другая.

Разные роли - менеджер по продажам, менеджер по закупкам. В принципе, два разных экрана.

gopstop2007 писал(а): Буду рад, если подскажите простое решение

Ограничение отображения информации в LIST недавно обсуждали вот здесь:
http://forum.clarionlife.net/phpbb/view ... %83#p25679

Безусловно отдельные окна на разные права доступа к информации - это идельно-универсальное решение, но слишком уж затратно, как по объему кода, так и по его поддержке ....

А если контрол или процедуру переименовали? - то значит уже переделали APP. Имя процедуры при настройке доступа
видно, уже легче. Не все окна требуют разграничения доступа, значит там и не проверять. При разработке окна
можно указывать что контролировать. Если в Броуз нужно отображать по разному для разных групп пользователей,
можно попробовать фильтр в зависимости от группы. В общем все это есть уже в Dasscabc.tpl в разделе _Templates\DAS.
На мой взгляд сделано красиво. Но все функции в DLL, поэтому что-то изменить невозможно. И я хотел-бы сделать
что-то подобное, но вытащить из готовой DLL.
Но всетаки - как по номеру получить значение USE: ?
А ведь у DAS это все работает.

artgkx писал(а): Но всетаки - как по номеру получить значение USE: ?

Самый надежный вариант наверное такой. Шаблон при генерации кода пробегает по всем контролам и пишет что то типа:

MyClass.AddControl('?Button:1',1)
MyClass.AddControl('?Button:2',2)
MyClass.AddControl('?List',3)
! В шаблоне это делается элементарно.

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

artgkx писал(а):Но всетаки - как по номеру получить значение USE: ?

Я в БД храню то, что записано в prop:HLP (тильду оттуда убираю, если она есть), фактически аналог Use. Ну и вроде ClaFieldName для окон работает, но я не пользую.

gopstop2007 писал(а): закупочные цены + продажные видит одна группа пользователей, а только продажные видит другая. И таких примеров куча . Буду рад, если подскажите простое решение

Если в качестве СУБД используется что-то вроде SQL, то вопрос отсечения лишних данных может решаться на уровне СУБД (хранимой процедуры или вьюшки) -- возвращайте null в том поле датасета, которого не должен видеть пользователь с ограниченными полномочиями.

Yufil писал(а):Два полномочия - "Видит закупочные цены", "Видит продажные цены", включаем в окно главного меню
В зависимости от наличия полномочий устанавливаем глобальные флажки и показываем то, что надо...

так сейчас и использую

kreator писал(а):Разные роли - менеджер по продажам, менеджер по закупкам. В принципе, два разных экрана.

поддержка двух разных экранов, которые отличаются на 10%-50% - время затратно, при дублировании ручного кода и изменений

Игорь Столяров писал(а):

gopstop2007 писал(а): Буду рад, если подскажите простое решение

Ограничение отображения информации в LIST недавно обсуждали вот здесь:
http://forum.clarionlife.net/phpbb/view ... %83#p25679

Я в курсе , уже сформировалось как надо сделать, осталось только реализовать

Вообще, из своей практики, если программа массовая, то желательно кроме таблицы доступа определить и группы доступа (или как пишет Вячеслав роли). То есть по обязанностям пользователя определить к чему он имеет доступ. Желательно это сделать заранее предопределено, с возможностью корректировки.
При добавление нового пользователя просто определяет группа доступа (роль) и все.