как в БД Книги настроить ограничения пользователям на редактирования и удаления?

Разные возможности. Можно заложить это ограничение в dbnflc - не давать конкретному пользователю сохранять запись. Можно вообще поставить минус этой БД и ее нельзя будет редактировать. Можно более точечно заложить в рабочий лист - что можно менять, а что нет.
Все определяется конкретной задачей.

Так как буквально сегодня пришлось реализовывать данный функционал по заявке одного из пользователей, то делюсь результатами. Возможно функционал не на 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 пользователем А. Роман.

У нас наши задачи на ограничения решены на основе советов, которые тут на форуме мне дал Геннадий Сергеевич Панарин. Схема действий оказалась несложной и вполне реализуемой для меня (без знания языка форматирования), а результат именно тот, который нам нужен. Вот ссылка на то обсуждение: [irbis.elnit.org]



Редактировано 2 раз. Последний раз 28.06.2022 10:13 пользователем roit.

Татьяна Ароновна, то о чем идет речь в другой теме это организация отдельных РЛ со своим списком разрешенных полей.
Эта технология может скрыть от пользователя все поля кроме тех, в которые ему разрешен ввод/корректировка, но она не решает задачи запрета корректировки чужих записей и разрешения создавать новые записи в БД.