Этого поля нет в RDR.ws, который был выложен тут на форуме Л.В. Сорокиной вот тут [irbis.gpntb.ru]
Я взяла этот файл с форума т.к. в дистрибутиве 2016.1 версии (получили по состоянию на D1) RDR.ws был без полей для вузовской библиотеке вообще. В 2016 же версии предусмотрена работа только с RDR
Это поле 27 Прошлые ФИО нужно всем без исключения библиотекам и вузовским, и массовым!
Я это поле вернула себе на то место где оно было (под полем отчество). Но наверное же Вы будете класть RDR.ws в D3 к версии 2016.1 и нужно его вернуть, чтобы оно в дальнейшем было у всех.



Редактировано 5 раз. Последний раз 02.06.2017 12:23 пользователем roit.

Сегодня ставлю обновление D3 к версии 2016.1. В RDR.ws, который есть в этом обновлении так и нет 27 поля!
Уважаемые разработчики! Настоятельная просьба все-таки вернуть это поле на его законное место, после отчества.
Конечно, можно так и делать при каждом переходе на новую версию исправление в RDR.ws, восстанавливая там это поле. Но оно же нужно всем!
Совершенно стандартная ситуация, когда человек меняет фамилию. Есть в любой библиотеке! Включите это пожалуйста во все будущие версии!



Редактировано 3 раз. Последний раз 02.06.2017 12:24 пользователем roit.

Татьяна Ароновна, не совсем уверен в том, что несмотря на практическую полезность данного поля его (как и ряд других полей) в принципе позволят (обстоятельства) нам с вами оставить в составе РЛ. Связано это с необходимостью соблюдения требований законодательства о защите ПД, предъявляющихся к информационным системам.

Например, в ходе недавней консультации, любезно предоставленной мне Александром Майевичем Ждановым [www.garant.ru] в числе прочего прозвучало утверждение о необходимости хранения данных в наших условиях (вузовская библиотека) в обезличенной форме.

В апреле-мае этого года коллеги из одного вуза (10-15 тыс. студентов) в ходе подготовки к проверке были вынуждены обезличить информацию в БД RDR, удалив не только фамилию, но даже и имена с отчествами. Насколько эта мера именно в таком исполнении была оправдана - вопрос открытый. Но факт имеет место быть...

Таким образом, наличие фамилии (в т.ч. предыдущей) наряду с другой информацией в БД RDR может привести к тому, что в такой конфигурации ИСПДн будет признана не соответствующей предъявляющимся к ней требованиям.

Очень надеюсь, что на форуме удастся обсудить с разработчиками эту проблематику, т.к. с 1 июля существенно возрастают штрафы и ужесточаются санкции за несоблюдение требований законодательства о защите ПД.


поэтому, вопрос о возврате поля в РЛ может очень скоро оказаться неактуальным для большинства пользователей.

В принципе, с рабочими листами для БД RDR лучше поступить следующим образом, чтобы не испытывать лишних сложностей при переходе на новую версию или при применении обновлений:

1. Внести необходимые вашей библиотеке изменения в файл RDR.ws и сохранить его как RDR_SPBGIK.ws

2. Скорректировать файл WS31.OPT для БД RDR:


920
5
+++++ RDR_SPBGIK
*****

3. Перенести копию этого файла в надежное место (где вы храните файлы меню, форматы и т.п. скорректированные с учетом особенностей/потребностей библиотеки), например в директории ...\АДАПТАЦИЯ ИРБИС64 СПбГИК\DATAI\

при появлении обновленного файла RDR.ws вы сможете перед его копированием в директорию RDR сравнить с имеющимся там файлом и понять, нужно Вам или нет из нового файла переносить что-либо в ваш RDR_SPBGIK.WS (ну или корректировать что-либо в вашем файле) т.к. понять это будет проще, сравнивая новый дефолтный файл RDR.ws с его предыдущей версией, которую Вы ранее уже сравнивали со своим файлом RDR_SPBGIK.ws, чем сравнивать новый файл RDR.ws с вашим же RDR.WS (из которого могли и должны были (в связи с требованиями законодательства о защите персональных данных) убрать ряд полей, например таких как домашний адрес и паспортные данные).


Файлы *.OPT меняются реже, да и восстановить работу АРМ Каталогизатор с нужным рабочим листом будет проще.

В таком случае, нам остается только надеятся, что разработчики предложат и введут в помышленную версию программы некое решение, котрое позволит нам соблюсти требование законодательства. Если просто удалить ФИО читателей, то не очень понятно как работать вообще: что делать со списками должников, как авторизоваться читателям в ЭК и т.п. и т.д. в общем, должны быть какие-то инструменты в программе для всех, раз есть такие требования закона.

В принципе, уже сейчас есть все возможности по адаптации системы с тем, чтобы выполнить требования законодательства.

К сожалению, состав мер, которые нужно принимать в отношении БД читателей и САБ ИРБИС в целом в каждом из случаев может быть отличным. Специалисты рекомендуют при реализации ИСПДн руководствоваться комплексом действующих условий в ситуации каждой конкретной библиотеки. Наверное, вполне возможно выделить типовые ситуации и меры, но целесообразно ли?

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

Например, согласно документу: Методические рекомендации по применению приказа Роскомнадзора от 5 сентября 2013 года N 996 "Об утверждении требований и методов по обезличиванию персональных данных" есть 4 метода обезличивания!

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

В тех форматах, где требуется отобразить ФИО (формат просмотра, текст письма по эл. почте и т.п.) - эти данные могут быть расформатированы из этой БД. Т.е. тот же список должников для деканата м.б. сформирован форматом, который по идентификатору читатель в требуемом месте выведет ФИО из другой БД.

При этом авторизация вполне может проводиться по паре полей - логин/пароль, в качестве которых могут использоваться любые известные читателю данные, например - фамилия в латинской транслитерации и номер читательского билета или логин/пароль, выданные в библиотеке/вузе.

но в принципе, мое мнение - пора переходить к аутентификации по OpenLDAP в ИРБИС64 с тем, чтобы не испытывать больше лишних проблем с безопасностью информации.

Если есть возражения/замечания/предложения - Welcome!



Редактировано 1 раз. Последний раз 12.06.2017 20:42 пользователем А. Роман.