Re: как в БД Книги настроить ограничения пользователям на редактирования и удаления
Пользователь:
А. Роман (IP-адрес скрыт)
Дата: 27, June, 2022 21:05
Так как буквально сегодня пришлось реализовывать данный функционал по заявке одного из пользователей, то делюсь результатами. Возможно функционал не на 100% универсальный, но вполне применим.
В отношении удаления записей есть параметр DELETEABLE=0
но он работает на АРМ в целом. Если нужно разрешить удалять записи конкретным сотрудникам но не во всех БД, а в отдельных БД то можно добавить в файл operhint.pft тех БД в которых можно удалять записи сценарий ГК с одним оператором DELR.
Логично кстати, что при ограничении на удаление записей у пользователей параметром GLOBALABLE=0 д.б. отключена и возможность выполнения ГК в соответствующем модуле.
Пример сценария для выполнения ГК на удаление записи:
if &uf('+6')='1' and &uf('kdeleters_list.mnu!',&uf('IPRIVATE,FIO,NONAME')):'allow' then
'Удалить запись',/,
'Удалить запись логически',/,
''/#,
'4'/,
'del_record.gbl;',/,
'Команда выполнена'/,
''/#,
fi,/
В файл del_record.gbl можно поместить сценарий удаления записи:
0
DELR
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
А можно создать БД произвольной структуры и при удалении использовать сценарий, который зафиксирует в этой БД информацию об удаленной записи.
Пример такого сценария на ГК и архив с БД DELLOG в приложении к сообщению.
При этом в файлы автоввода autoin.gbl тех БД в которых выполняется удаление с переносом в архивную БД добавлен сценарий на случай восстановления записей (см. файл dellog_UNDEL_add.gbl), который удаляет запись и дополняет ее при этом данными того, кто восстановил запись.
Пока поиск записей осуществляется по MFN, в следующем релизе планируется привязаться к GUID и дополнить сценарий реорганизации БД DELLOG отвязкой от удаленных записей, если проводилась реорганизация БД (простая или с исключением физически удаленных записей).
В справочнике deleters_list.mnu должны быть перечислены логины тех, кому разрешено удалять записи и второй строкой у каждого из них allow:
Иванов
allow
Петрова
allow
...
В отношении запрета на корректировку чужих записей (т.е. тех, которые не били импортированы из ИРБИС-Корпорации или созданы с ноля самостоятельно) можно создать файл меню, например stop_list.mnu в который поместить логины тех, кому нельзя корректировать записи в БД и расшифровку к каждой из них stop
Иванов
stop
Петрова
stop
...
и в файл ФЛК БД dbnflc.pft добавить сценарий:
if a(v907) then else if S(&uf('AV907^B#1'),&uf('AV907^B#2')):&uf('IPRIVATE,FIO,NONAME') or S((V907^C))='ICORP' then else if &uf('kstop_list.mnu!',&uf('IPRIVATE,FIO,NONAME')):'stop' then /'1 Вы не можете корректировать чужие записи!'/ fi fi fi
В сценарии проверяется есть ли в записи поле 907 (при этом пользователю д.б. запрещено удалять данные из записей (параметр AccessLevel=1), и выполнение произвольных ГК Globalable=0), чтобы нельзя было удалить данные из поля 907) и при наличии поля 907 проверяется присутствие логина текущего пользователя в 1 и 2 повторениях поля 907 (в 1 и 2 потому, что при импорте из ИРБИС-корпорации в поле 907 будет не логин пользователя, а сигла библиотеки из которой импортировали запись), ну и проверяется что в записи есть только 907 поле с данными импорта из ИРБИС-Корпорации (т.к. в момент импорта создается запись с единственным повторением поля 907 с данными импорта (дата, ICORP, сигла библиотеки).
Редактировано 3 раз. Последний раз 27.06.2022 21:28 пользователем А. Роман.
Вложения:
dellog_UNDEL_add.gbl (557 bytes)
DELLOG.zip (1.25MB)