Добрый день!
Возможно ли наделить различный пользователей различными правами ?

Например: два сотрудника заносят данные в АРМ Каталогизатор. Можно ли чтобы они не могли изменять данные внесенные другим сотрудником.

Можно, но это сложно. Опишу технологию.

Как запретить пользователю редактировать записи, которые были созданы другим пользователем?

1. Необходимо, чтобы пользователи не имели права корректировать поле "ФИО исполнителя" в Личных параметрах АРМа Каталогизатор. Это делается для того, чтобы этой настройке можно было безоговорочно доверять. Это решается удалением из файла IRBIS64\setpriv.wss строки с меткой подполя FIO. После такого удаления нужно проконтролировать, чтобы во всех индивидуальных ини-файлах параметр FIO в секции Private был обязательно заполнен соответствующим значеним.
2. Поскольку штатными (чит. встроенными) средствами системы эту проблему решить нельзя, то воспользуемся механизмом ФЛК записи для той базы, в которой нужно настроить ограничение.
Проверить доступность корректировки можно форматом

if &uf('IPrivate,FIO,')<>&uf('A907^b#1') then
'1 Вам запрещено корректировать записи, созданные не вами'
fi

Вставляем этот код в файл DBNFLC.PFT. В результате этих манипулиций пользователь сможет корректировать запись, но при попытке ее сохранить, корректировки сохранены не будут.
3. Операции, проделанные в пп.1-2 не совсем удобны, поскольку пользователь все-таки потратить определенное время на корректировку записи, и предупреждение выйдет ему с самый последний момент. При этом все введенные им корректировки будут утеряны. Исключить этот момент можно, назначив на КАЖДОЕ поле ФЛК с подобной проверкой. Это не удобно и очень трудоемко, но указанный метод сейчас единственно возможный для решения поставленной вами задачи.

Упростить решение подобных проблем помогло бы расширение функциональности системы за счет введения дополнительной проверки в АРМе Каталогизатор по типу DBNFLC. Она выполняется в момент сохранения. Если был бы параметр, определяющий имя формата ФЛК, выполняемого перед вызовом записи на корректировку, то задача решалась бы более универсальнее и красивее.

ух .. не так все просто =) да и действительно не совсем удобно.

Огромное спасибо! Попробую применить на практике.

А вот как сделать так чтобы именно запрет был только для определенных пользователей,а вот для некоторых привелегированных этого запрета не было.можно так?

Несколько различных DBNFLC, прописанные в Ini-файлах пользователей. То бишь - кому что пропишите - такие проверки и будут у него работать.

Что то у меня не получается создал личные privatesetpriv.wss(удалил несколько строк с метками FIO) и privatedbnflk.pft(в конце добавил выше описанный формат записи) прописал в личном ини файле через редактор ирбиса.Но при запуске АРМа пользователя выходит ошибка list index not bounds(371) и интерфейс застывает.В личном ини файле параметр FIO заполнен.



Редактировано 1 раз. Последний раз 17.03.2010 13:15 пользователем Esil.

Путь который указал iLq - запрещать конкретному пользователю корректировать определенные поля с помощью параметрирования DBNFLC - очень оригинален (честно признаюсь, сам не сразу сообразил, как это сделать)
А сделать это можно вот как:
Допустим конкретному пользователю нельзя вводить/корректировать поля 200 и 910. Для него создается оригинальный формат dbnflc с именем dbnflc_sasha следующего вида:

if (v200<>ref(mfn,v200)) or (v910<>ref(mfn,v910) then '1Вы лишены права корректировать поля 200 и 910' else &uf('6dbnflc') fi

И в профиле этого пользователя (INI-файл Каталогизатора) надо указать в секции [Entry]

dbnflc=dbnflc_sasha

Вот и все.



Редактировано 2 раз. Последний раз 17.03.2010 14:13 пользователем Alio.

Жаль, что мои предложения по расширению ФЛК (до взятия записи на корректировку и до взятия поля на корректировку) остались без внимания Александра Иосифовича. А так хотелось услышать комментарий.

Я так понимаю что мы приходим к тому что все Каталогизаторы равны, но некторые равнее.
Предлагаю ввести в следующих версиях возможность создавать каталогизаторов нескольких типов, по аналогии с пользователями в блогах, имеют право редактировать, редакция должна быть одобрена модератором :)

Цитата:

Путь который указал iLq - запрещать конкретному пользователю корректировать определенные поля с помощью параметрирования DBNFLC - очень оригинален (честно признаюсь, сам не сразу сообразил, как это сделать) А сделать это можно вот как: Допустим конкретному пользователю нельзя вводить/корректировать поля 200 и 910. Для него создается оригинальный формат dbnflc с именем dbnflc_sasha следующего вида: if (v200<>ref(mfn,v200)) or (v910<>ref(mfn,v910) then '1Вы лишены права корректировать поля 200 и 910' else &uf('6dbnflc') fi И в профиле этого пользователя (INI-файл Каталогизатора) надо указать dbnflc=dbnflc_sasha Вот и все.

Все равно не получается.Вы не уточнили,описанный Вами метод запрещает воопще редактировать и свое и чужое?
setpriv.wss в начале я не трогал,сделал все как вы сказали в личном ини файле пользователя в секций Entry прописал нужный dbnflk,внутри dbnflk в конце добавил if (v907<>ref(mfn,v907)) then '1Вы лишены права корректировать поле 907' else &uf('6dbnflc') fi
Что может быть не так?



Редактировано 1 раз. Последний раз 17.03.2010 14:55 пользователем Esil.

Esil написал(а):
-------------------------------------------------------
> >
> Все равно не получается.Вы не уточнили,описанный
> Вами метод запрещает воопще редактировать и свое и
> чужое?
> setpriv.wss в начале я не трогал,сделал все как вы
> сказали в личном ини файле пользователя в секций
> Entry прописал нужный dbnflk,внутри dbnflk в конце
> добавил if (v907<>ref(mfn,v907)) then '1Вы лишены
> права корректировать поле 907' else &uf('6dbnflc')
> fi
> Что может быть не так?

В личном ini-файле вы прописали dbnflc_sasha ?
А dbnflc_sasha.pft состоит из строчки:

if (v200<>ref(mfn,v200)) or (v910<>ref(mfn,v910) then '1Вы лишены права корректировать поля 200 и 910' else &uf('6dbnflc') fi
Так?
Правда это условие было, как пример, и оно не удовлетворяет вашему запросу.
Для вашего запроса подходит условие, которое описал Максим:
if &uf('IPrivate,FIO,')<>&uf('A907^b#1') then
'1 Вам запрещено корректировать записи, созданные не вами'
fi

Что произошло после того, как вы прописали dbnflc?

Я создал privatedbnflc(скопировал оригинал к нему добавил "Максимовскую" запись,или же этот пфт должн состоять только из этой записи?) в setpriv.wss снес строки:
FIO
ФИО исполнителя
0
0
1
fio.mnu

Еще раз повотряю прописал в личном ини файле в секций Entry privatedbnflc.pft
И все...Пробовал перезапускать,перезагружать,ни в какую

В приведенном мною формате ошибка

if &uf('IPrivate,FIO,')<>&uf('Av907^b#1') then
'1 Вам запрещено корректировать записи, созданные не вами'
fi

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

if (&uf('IPrivate,FIO,')<>&uf('Av907^b#1'))and(v***<>ref(mfn,v***)) then
'1 Вам запрещено корректировать записи, созданные не вами'
fi

Однако если завести в Ирбисе базу прав пользователей и там хранить для каждого пользователя список баз данных и полей, которые ему разрешено редактировать или наоборот запрещено, то можно было бы формат сделать универсальным и управлять правами простыми тыками мышкой.

PS. Указанный мною формат нужно добавить в самое начала dbnflc_my.pft. Ну и конечно же простое удаление поля FIO из setpriv.wss не достаточно. Нужно проконтролировать, чтобы для каждого пользователя параметр FIO в секции Private его персонального ИНИ-файла был установлен в значение его ФИО. Это обязательно!



Редактировано 2 раз. Последний раз 17.03.2010 16:28 пользователем Панев Максим.

Максим, хорошая идея.

Единственное, что меня остановило от развития этой идеи, это то, что я не нашел unifor для получения имени текущей базы данных. Вроде был такой, а в документации такого нет :(.



Редактировано 1 раз. Последний раз 17.03.2010 21:59 пользователем Панев Максим.

Сколько не потел,не получилось,ладно уже...:?Будем ждать доработок разработчиков.Да услышат Боги просьбу гуру Максима

О каких доработках идет речь?
Здесь явное непонимание исходного вопроса.
В записи документа Бд ЭК в 907 поле сохраняются сведения о том, кто и когда корректировал документ В ЦЕЛОМ (при этом первое повторение поля 907 содержит информацию о том, кто и когда СОЗДАЛ эту запись). Никаких сведений о том, какие конкретно поля корректировал пользователь, не сохраняется. Поэтому исходную задачу: запретить корректировать те поля, которые корректировал другой пользователь ПРИНЦИПИАЛЬНО нельзя. Можно решить только две задачи:
- запретить корректировать запись, которую СОЗДАЛ другой пользователь
- запретить корректировать конкретные поля.
Как это сделать - сказано выше...

Цитата:

Esil
Я создал privatedbnflc(скопировал оригинал к нему добавил "Максимовскую" запись,или же этот пфт должн состоять только из этой записи?) в setpriv.wss снес строки:
FIO
ФИО исполнителя
0
0
1
fio.mnu

Еще раз повотряю прописал в личном ини файле в секций Entry privatedbnflc.pft
И все...Пробовал перезапускать,перезагружать,ни в какую

Вы правили этот файл вручную, не редактором? Тогда обратите внимание на 1-ю строку этого файла - там указано общее кол-во подполей в этом WSS - оно должно соответствовать истине...

Решение вопроса, поднятого в первом посте, уже приведено.

Сейчас речь идет о доработке, которую я хотел бы вынести на обсуждение: добавить дополнительно 2 ФЛК:
1. При выборе записи на корректировку
2. При взятии поля на корректировку
Эти 2 улучшения можно будет продуктивно использовать для контроля доступа пользователей к записям.
Про контроль изменения полей, созданных другими пользователями, речи не было вообще. Да и смысла в этом никакого нет. А вот запретить каким-то пользователям корректировать в определенной базе данных какие-то конкретные поля - это вполне реальная и относительно часто возникающая задача.

ЗЫ. Так все-таки есть ли unifor для получения имени текущей базы данных? Или может завести в ЯФ на ровне с MFN еще и конструкцию DBN? Получение имени текущей базы становится особоенно актуальным в связи с появлением директории Deposit.



Редактировано 1 раз. Последний раз 18.03.2010 10:23 пользователем Панев Максим.

Панев Максим написал(а):
-------------------------------------------------------
> Решение вопроса, поднятого в первом посте, уже
> приведено.
>
> Сейчас речь идет о доработке, которую я хотел бы
> вынести на обсуждение: добавить дополнительно 2
> ФЛК:
> 1. При выборе записи на корректировку
> 2. При взятии поля на корректировку
> Эти 2 улучшения можно будет продуктивно
> использовать для контроля доступа пользователей к
> записям.
> Про контроль изменения полей, созданных другими
> пользователями, речи не было вообще. Да и смысла в
> этом никакого нет. А вот запретить каким-то
> пользователям корректировать в определенной базе
> данных какие-то конкретные поля - это вполне
> реальная и относительно часто возникающая задача.
И она вполне решается существующими средствами - никакие доработки для этого НЕ ТРЕБУЮТСЯ



>
> ЗЫ. Так все-таки есть ли unifor для получения
> имени текущей базы данных?
&uf('+D')

а dbnflc_1.pft должен быть во всех БД?Или же он должен быть один общии для всех?

Решаться-то она решается, только не очень красиво. Сообщение о том, что корректировка запрещена, выйдет только после того, как корректировка уже произойдет. Будет большое криков чем пользы. Не понимаю, в чем проблема введения дополнительных ФЛК. Если их нет (по умолчанию), то и проверки пусть не делаются. Ничего и не изменится. А если возникнет необходимость, то задача будет очень удачно решена. Доработка - вопрос 30 минут. Но похоже ждать придется как всегда долго.

Панев Максим написал(а):
-------------------------------------------------------
> Решаться-то она решается, только не очень красиво.
> Сообщение о том, что корректировка запрещена,
> выйдет только после того, как корректировка уже
> произойдет.
И это очень хорошо - как наказание за то, что человек делает то, что ему не положено. Ситуация, когда он не знает о запрете, исключается.
Но впрочем, дисскуссия закончена. Преддложенные доработки не принимаются.

Поддержу НЕпринятие доработки. ИМХО лишняя дополнительная (и не слабая - подумай о ситуации пробегания курсором по полям клавишей вниз) нагрузка. Для 128-го такое еще можно реализовать - там можно будет выполнять расчёты при чтении записи (а в некоторых случаях и после представления записи, фоном) и устанавливать исходя из этих расчётов различные свойства РЛ и каждого поля/повторения поля.
В 64-м делать такие расчеты для 1-2 тысяч экземпляров какого-нибудь 910 поля... Не, не надо такое ))

Прошу также не забывать, что есть возможность запрещать ввод в конкретное поле через РЛ - указывая в качестве метода ввода !0