forum.clarionlife.net

Help! Нужен доступ к процедурам приложения разный для разных пользователей. Раньше писал в коде программы.
Но это не совсем правильно, трудно настраивать, нет гибкости. Посмотрел шаблоны. По моему здорово сделано в
Dasscabc.tpl . Но есть проблема, там все завязано на das63sx.dll , даже сгенерить пример из поставки не
получается. Есть библиотеки das63sx.lib и das63sxl.lib. Может кто подскажет как их развернуть в процедуры, чтобы генерить самому для разных версий Clarion. Или вообще решать задачу по другому. Многие наверняка это
уже делали. Изобретать велосипед не хочется. Большое спасибо за помощь.

Во-первых, не знаю про Dasscabc.tpl. Во-вторых, наверно, есть куча подходов. И конкретики в вопросе нет.
Я в своё время (и сейчас у меня работает также) идею взял у 1С. Для каждого экрана (ведётся специальная таблица в БД) есть четыре возможности - просмотр, добавление записи, редактирование записи, удаление записи. Ну и есть таблица где хранится информация пользователь-права доступа (группы тоже могут быть). Естественно, при входе в экран проверяется это дело. Экраны самому в таблицу добавлять не надо, программа при загрузке пробегает по меню фрейма и добавляет, если что-то новое появилось. Просто и сердито, кое-чего не хватает в этой схеме.
В другом проекте сделано по другому. Тупо описана некая возможность (например, "поставить подпись"). Эти возможности хранятся в отдельной таблице БД. Есть таблица где хранится информация пользователь-права доступа для этой возможности. При такой схеме есть возможность управления доступом на сложных экранах, когда много кнопок и т.д.
Ещё видел у других - привязываются к доступу на таблицы SQL. Т.е. проверяют, что для данного пользователя включено на серваке. Но мне не понравился такой подход. Надо админу сервака отслеживать доступ при сложных списках не по одной таблице.

kreator писал(а):
Я в своё время (и сейчас у меня работает также) идею взял у 1С. Для каждого экрана (ведётся специальная таблица в БД) есть четыре возможности - просмотр, добавление записи, редактирование записи, удаление записи. Ну и есть таблица где хранится информация пользователь-права доступа (группы тоже могут быть). Естественно, при входе в экран проверяется это дело. Экраны самому в таблицу добавлять не надо, программа при загрузке пробегает по меню фрейма и добавляет, если что-то новое появилось. Просто и сердито, кое-чего не хватает в этой схеме.
В другом проекте сделано по другому. Тупо описана некая возможность (например, "поставить подпись"). Эти возможности хранятся в отдельной таблице БД. Есть таблица где хранится информация пользователь-права доступа для этой возможности. При такой схеме есть возможность управления доступом на сложных экранах, когда много кнопок и т.д.

Я делаю похоже, но немного иначе. Для оконных процедур по умолчанию задаются правила - запрет просмотра и только просмотр. Внутри оконной процедуры можно специальным шаблоном навесить дополнительные правила доступа и список соответствующих им контролов для срытия или недоступности. При генерации app список оконных процедур и дополнительных правил сохраняются в текстовом файле. А другой шаблон при генерации одного из app затягивает эти списки и создает код заполнения служебных таблиц объектов доступа. Оконные процедуры группируются по категориям. Существует также специальная служебная оконная процедура, в которой собраны правила доступа, не привязанные к конкретным оконным диалогам. Все это отрабатывает автоматически. В ручном коде можно использовать стандартную процедуру проверки прав, указав в качестве параметров имя оконной процедуры и дополнительное правило, если нужно.

Тоже делал аналогичную вещь. Для каждой процедуры, где требуются права, описывается список полномочий в данном окне. Например, для
справочника клиентов могут быть определены полномочия Клиент+, клиент- и Клиент= для добавления, удаления и правки клиента.
Вот, например, в одной из процедур определяются (шаблонами) ресурсы
В программе (шаблонами) определяются действия, если у оператора (или группы операторов) есть ресурс, если нет ресурса и т д (например, если нет ресурса Клиент+, то кнопка ?Insert в окне недоступна). Стандартные действия - hide, unhide, enable, disable, return и, при необходимости, какой-то самописный код.
Например, так (код из реальной программы, но опять же генерится шаблоном)
Фишка в том, что администратор может зайти в процедуру правки списка клиентов, нажать волшебную кнопку и раздать полномочия для оператора или группы операторов прямо в интерфейсе программы. Естественно, всё это дело хранится в БД.

Последний раз это эксплуатировалось в 2004 году, увы...

У меня права определяются не для пользователей, а для ролей. А пользователю задается определенная роль. По умолчанию разрешено все, выставляются ограничения.
Сейчас популярно одному пользователю задавать список ролей. Мне кажется, такой подход удобен в крупных системах при большом количестве пользователей и строго дифференцируемом функционале...

finsoftrz писал(а):По умолчанию разрешено все

У меня по умолчанию - запрещено всё .

finsoftrz писал(а):Сейчас популярно одному пользователю задавать список ролей.

Есть вот какой момент. Если посмотреть как Microsoft сделал управление пользователями в ActiveDirectory, то там пользователь может входить в несколько групп (они же роли). Права на эти группы могут быть противоположными. Например, Юзер1 входит в Группу1 и Группу2. Группа1 имеет право доступа к Окну1, а Группа2 не имеет. Поэтому Юзер1 не имеет права доступа к Окну1 (хотя опять же могут быть разные мнения). Я вот не стал пока заморачиваться с этим, у меня пользователь может входить в одну группу. Группа (она же роль) удобна тем, что достаточно прописать ей права, а не всем пользователям, пользователей много, а групп (ролей) на порядок меньше. Такого механизма хватает почти всегда. Если не хватает, то админ явно может выбрать пользователя для права доступа. У меня приоритет пользователя выше группы.

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

Большое спасибо за отклики. Просто по просьбе знакомой сделал программку по учету договоров, счетов,
оплаты и т.д. Я ей говорил что это все есть в 1С, но не захотела. Основной функционал работает. Но теперь
захотели чтобы эту информацию могли смотреть директор, зам. по финансам, и др. Вот тут и возникла проблема
доступа, чтобы кто-то чего-то не натворил.
Спасибо за программку получил, если хоть что-то заплатят, уже будет хорошо. Делал это что-бы мозги
не засохли на пенсии. Сам не программист, а только учусь. На этой программке осваивал Clarion 9.1.
Поэтому не судите строго. За подсказки спасибо, буду осваивать дальше.

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

Странная просьба, извините. Я раньше тоже многим делал программки с "ограниченным" функционалом, сестра работает в Сбербанке, для неё делал учёт тоже договоров и доверенностей (сейчас договора в корпоративной ЕРП, а доверенностями пользуются). Но сейчас тенденция - объединить всё под одну крышу. Тем более, если есть в организации и директор и зам. по финансам. Большинство таких моих наработок - в столе или в мусорной корзине . Может сейчас ситуация в обратку пошла - наелся народ дорогущими ЕРП?

Yufil писал(а):...Например, так (код из реальной программы, но опять же генерится шаблоном)...

А сколько будет стоить шаблончик?

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

Но можно, наверное, и ещё что-то полезное надыбать, там всяких фишек...

Вроде вырисовывается что и как надо сделать.
LOOP i# = FIRSTFIELD() TO LASTFIELD()

.
Возвращает номера контролов в окне. Как по номеру получить значение USE: .
Вроде есть функция ClaFieldName(LONG),NAME('Cla$FieldName'),CSTRING,PROC. Как правильно задействовать?
Просьба объяснить для чайников. Yufil обещал показать показать свой шаблон, а где можно посмотреть?
Может там ответы на многие вопросы.

А зачем нужно USE? Шаблон имеет доступ к элементам текущего экрана.
Проблема в том, что я последний раз работал с этим шаблоном давным-давно, последний проект 2004-2005 годы,
дальше не пригодился, даже не помню особенностей реализации.
Идея была следующей
я в шаблонах прописываю примерно следующее

Имя допуска: +Клиент
Описание: Добавление клиента
При отсутствии допуска: Сделать неактивным
Контрол ?Insert
При наличии допуска: (можно свой код написать)

Имя допуска: -Клиент
Описание: Удаление клиента
При отсутствии допуска: Сделать неактивным
Контрол ?Delete
При наличии допуска: (можно свой код написать)

Имя допуска: ПечатьКлиентов
Описание: Печать списка клиентов
При отсутствии допуска: Скрыть
Контрол ?PrintClientButton
При наличии допуска: (можно свой код написать)

Ну и так далее... Это делается в процедурах ( Window-Browse-Form), где надо
А потом администратор (имеющий права на ВСЁ) в ходе работы заходит в окно и нажимает волшебную кнопку
На экран выводится список пользователей и список полномочий, администратор крыжит, что кому можно
и что кому низзя (полномочие может быть и запретительным), всё это пишется в базу данных
Пользователь-Полномочие.

Если есть желание, напишите письмо, отправлю архив с исходниками последнего приложения, там много ещё интересных вещей можно для себя найти при желании.

Сохраняется в таблице доступа, а затем при проверке доступа пользователя выставляется атрибут
Disable или Hide, ReadOnly и т.д.

Ну да, естественно. Или выполняется самописный код, прописанный в шаблонах.