Gena написал(а):
-------------------------------------------------------
> Александр Иосифович, три просьбы, касающиеся
> TCP/IP-сервера и АРМа Администратор.
>
>
> 1. Из опыта создания пользователей САБ ИРБИС64
>
> При сопровождении Ирбиса в библиотеке одной из
> первых задач, с которой сталкивается любой
> администратор, это создание пользовалетей. Вроде
> бы ничего сложного в этом нет, но есть подводные
> камни, которые явно не оговариваются, и это
> приводит к последующим проблемам.
> В частности, очень не многие администраторы при
> создании новых пользователей назначают им
> индивидуальные ини-файлы. В связи с этим очень
> большая просьба: автоматически дописывать к именам
> стандартных ини-файлов имя пользователя, которого
> сейчас создают.
>
Сделано.

Gena написал(а):
-------------------------------------------------------
> Александр Иосифович, три просьбы, касающиеся
> TCP/IP-сервера и АРМа Администратор.
>
>

> 2. При работе с очень большим количеством
> пользователей удобно складывать их ини-файлы не в
> корневую директориюю сервера, а создавать для
> этого отдельную папку. Чаще всего в корневой папке
> сервера создаем папку INI и в нее уже помещаем
> сами ини-файлы. При этом в полях указания
> ини-файлов в списке пользователей указывается не
> только ини-файл, но и название директории.
> Выглядит это следующим образом
> "/INI/IRBISC_ИвановИИ.INI". На стороне сервера я
> могу внести изменения в ини-файл TCP/IP-сервера и
> в файл client_ini.mnu, что бы в поле ввода
> ини-файла уже автоматически прописывался префикс.
О каких изменениях ини-файла TCP/IP-сервера идет речь?


> Но это не работает для списка пользователей из
> АРМа Администратор. Можно ли это исправить?
>

А. Роман написал(а):
-------------------------------------------------------
> Для тех пользователей, которые не имеют
> возможности работы на сервере ИРБИС (последнее
> время встречаются все чаще) крайне желательно
> создать пункт меню и режим работы клиентского АРМ
> Администратор - Создать словарь полностью (только
> ЭК).
>
> Многие из тех, кому приходится с этим сталкиваться
> были бы очень признательны, если бы режим появился
> и в версии 2018.1
Казалось бы, ничего не стоит это сделать, но...
Выясняется, что это связано с очень объемными изменениями в серверной части, на которые мы не можем сейчас пойти.
Предлагается следующий паллиатив.
В INI-файл АРМа Администратор (irbisa.ini) вводится параметр, который определяет, как воспринимать команду клиентского Администратора СОЗДАТЬ СЛОВАРЬ ЗАНОВО:
0 (по умолчанию) - выполнять СОЗДАТЬ СЛОВАРЬ ЗАНОВО ПОЛНОСТЬЮ ТОЛЬКО ЭК
1 - выполнять СОЗДАТЬ СЛОВАРЬ ЗАНОВО ПОЛНОСТЬЮ

Если такое решение устраивает, сделаем...

Gena написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > Gena написал(а):
> >
> --------------------------------------------------
>
> > -----
> > > Александр Иосифович, большая просьба - в АРМе
> > > Администратор снять ограничение на длину
> > названия
> > > (латинского) базы.
> > А в чем проблема?
>
>
> Проблема в том, что при большом количестве баз им
> пытаются давать осмысленные названия. Доступной в
> АРМе Администратор длинны названия базы часто не
> хватает для этого, а делать каждый раз базу через
> пакетное задание - утомительно.
>
> Эта ситуация присуща в ЦБС и Областных
> библиотеках, где кроме электронного каталога могут
> формироваться технологические базы под какие-то
> конкретны задачи: исследования, формирование
> сборников, работа над биобиблиографическими
> выпусками, анализ данных и т.д.
Снять ограничение на длину нельзя. Увеличил до 16. Думаю, хватит.

Gena написал(а):
-------------------------------------------------------
> Александр Иосифович, добрый день! Есть три
> предложения по работе ИрбисНавигатора (который
> встраивается в АРМы)
>
> 1. Хотелось бы предложить заменить используемый
> вебкомпонент. Судя по поведению модуля,
> используется TWebBrowser, у которого есть проблема
> с работой JavaScrip.
>
На что заменить?

levr написал(а):
-------------------------------------------------------
> хотелось получить возможность перевода на
> украинский язык "шапки" выходной формы которая
> отвечает за рассылку в режиме ИРИ из АРМ
> "Книговыдача"
Увы, приходится отказываться от своего обещания. Изменения, которые необходимо для этого сделать в подсистеме ИРИ, являются неоправданными...


> Графика современного азербайджанского языка на
> латинице
???

>
> А.И. обещал решить задачу в вер. 2019.1 (есть в
> записи вэбинара по АРМ "Книговыдача")

Просьба добавить большей гибкости "настроек" в книговыдаче:

1) Ввести параметр в irbisb.ini который позволит задавать библиотекарю kv.mnu отличный по умолчанию, чтобы библиотекарь мог выбирать из ограниченного списка кафедр выдачи, а не из общего.
2] [опционально] и остальные справочники в настройках
3) Ввести параметр в irbisb.ini который запрещает произвольный ввод в поля настроек, но оставляет возможность выбора из справочника.
4] [опционально], возможность предыдущий параметр для каждого поля выбирать.

levaleva написал(а):
-------------------------------------------------------
> Просьба добавить большей гибкости "настроек" в
> книговыдаче:
> [sntnarciss.ru]
> .png
> 1) Ввести параметр в irbisb.ini который позволит
> задавать библиотекарю kv.mnu отличный по
> умолчанию, чтобы библиотекарь мог выбирать из
> ограниченного списка кафедр выдачи, а не из
> общего.
Однако... А для чего тогда существуют профили пользователя???

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

Кейс в том что, что есть, условно, две библиотеки. Библиотекарь в библиотеке Б1 может работать на своих абонементе, детском зале и читальном зале, Библиотекарь в библиотеке Б2 может работать на своих абонементе, детском зале и читальном зале. Как сделать, чтобы библиотекарь один мог работать с Б1-аб, Б1-чит, Б1-дет, но не мог с Б2-аб, Б2-чит, Б2-дет?

levaleva написал(а):
-------------------------------------------------------
> >Однако... А для чего тогда существуют профили
> пользователя???
> Подскажите в таком случае, как в профиле
> пользователя дать возможность выбрать одну из трех
> кафедр выдачи?
>
> Кейс в том что, что есть, условно, две библиотеки.
> Библиотекарь в библиотеке Б1 может работать на
> своих абонементе, детском зале и читальном зале,
> Библиотекарь в библиотеке Б2 может работать на
> своих абонементе, детском зале и читальном зале.
> Как сделать, чтобы библиотекарь один мог работать
> с Б1-аб, Б1-чит, Б1-дет, но не мог с Б2-аб,
> Б2-чит, Б2-дет?
Перенесите свой вопрос в раздел АРМ Книговыдача.

> 17. Давно назревает вопрос пересмотра расположения
> всех файлов системы на сервере. Есть хороший
> подход MVC. Почему бы не начать его использовать?
> Отдельно хочу сказать, что при постоянных
> обновлениях и доработках системы следить за
> десятками тысяч файлов просто нериально. Хочу
> вынести на обсуждение следующую идеологию
> расположения файлов на сервере Ирбиса:
>
>
> IRBIS64_SERVER/ - корневая папка сервера Ирбиса
> DATAI/ - папка ДАТАИ, в которой храняться
> неизменные форматы и ресурсные файлы из
> дистрибутива (эталонные!)
> DEPOSIT/
> ALL_DB_FILE(mst,xrf...)/ - одна папка для
> всех без исключения файлов баз данных. В случае
> чего ее и копировать проще
> DB1_RESURCE/ - для каждой отдельной базы
> содержать папку только под ее уникальные ресурсы
> (эталонные!)
> ...
> DBN_RESURCE/
> DATAI_USER/ - папка с измененными,
> пользовательскими настройками
> DEPOSIT_USER/ - общие для всех баз
> измененные пользователем файлы
> DB1_RESURCE/ - измененные пользователем
> файлы для отдельной базы
> ...
> DBN_RESURCE/
> FULLTEXT/ - отдельная папка для полных текстов.
> При желание, в ней можно прописывать разделения
> какие-то, но при установке все 11 параметры
> пар-файлов должны ссылаться на одно файловое
> харилище.
>
>
>
> Очередность поиска ресурсов сервером на диске:
> 1. ищу ресурс в DATAI_USER/DB1_RESURCE
> 2. ищу ресурс в DATAI_USER/DEPOSIT_USER
> 3. ищу ресурс в DATAI/DB1_RESURCE
> 4. ищу ресурс в DATAI/DEPOSIT
>
> При таком расположении файлов любые переустановки
> и переходы на новые версии будут максимально
> упрощены. Более того, при таком подходе уже
> появляется возможность построить систему
> автоматического обновления с удаленного сервера -
> мы ничего не испортим в настройках клиента!
Замечательно. А как быть с соблюдением преемственности версий?

Alio написал(а):

> Перенесите свой вопрос в раздел АРМ Книговыдача.
Перенес и нашел там упоминание параметра KVMNU, спасибо. Поскольку нигде более не нашел его упоминания, предлагаю внести его в "Общее описание системы" (в 2017 точно нет).

Alio написал(а):
-------------------------------------------------------
> > 17. Давно назревает вопрос пересмотра
> расположения
> > всех файлов системы на сервере. Есть хороший
> > подход MVC. Почему бы не начать его
> использовать?
> > Отдельно хочу сказать, что при постоянных
> > обновлениях и доработках системы следить за
> > десятками тысяч файлов просто нериально. Хочу
> > вынести на обсуждение следующую идеологию
> > расположения файлов на сервере Ирбиса:
> >
> >
> > IRBIS64_SERVER/ - корневая папка сервера Ирбиса
> > DATAI/ - папка ДАТАИ, в которой храняться
> > неизменные форматы и ресурсные файлы из
> > дистрибутива (эталонные!)
> > DEPOSIT/
> > ALL_DB_FILE(mst,xrf...)/ - одна папка для
> > всех без исключения файлов баз данных. В случае
> > чего ее и копировать проще
> > DB1_RESURCE/ - для каждой отдельной базы
> > содержать папку только под ее уникальные
> ресурсы
> > (эталонные!)
> > ...
> > DBN_RESURCE/
> > DATAI_USER/ - папка с измененными,
> > пользовательскими настройками
> > DEPOSIT_USER/ - общие для всех баз
> > измененные пользователем файлы
> > DB1_RESURCE/ - измененные пользователем
> > файлы для отдельной базы
> > ...
> > DBN_RESURCE/
> > FULLTEXT/ - отдельная папка для полных текстов.
> > При желание, в ней можно прописывать разделения
> > какие-то, но при установке все 11 параметры
> > пар-файлов должны ссылаться на одно файловое
> > харилище.
> >
> >
> >
> > Очередность поиска ресурсов сервером на диске:
> > 1. ищу ресурс в DATAI_USER/DB1_RESURCE
> > 2. ищу ресурс в DATAI_USER/DEPOSIT_USER
> > 3. ищу ресурс в DATAI/DB1_RESURCE
> > 4. ищу ресурс в DATAI/DEPOSIT
> >
> > При таком расположении файлов любые
> переустановки
> > и переходы на новые версии будут максимально
> > упрощены. Более того, при таком подходе уже
> > появляется возможность построить систему
> > автоматического обновления с удаленного сервера
> -
> > мы ничего не испортим в настройках клиента!
> Замечательно. А как быть с соблюдением
> преемственности версий?


Александр Иосифович, наверное я не правильно понимаю значение приемственности, но как по мне, это возможность модулей более старых и более новых работать с одной ресурсной базой. АРМы у нас изолированы от ресурсов - с ними работает сервер. Если мы на сервере перераспределеляем файлы в другие места и правильно серверу все объясняем, то он отдает эти файлы АРМам в полном соответствии с их потребностями.

Если тезисно, то вот что я описал в этом предложении:
1. отделить хранимую информацию (файлы базы) от ресурсов (форматы, РЛ, справочники...)
2. сделать дубляж директории DATAI, в котором будут храниться все изменяемые пользователем форматы. Это даст:
а) полностью чистый дистрибутив на всех серверах пользователей, который будет обновляться автоматически без каких-либо поломок и несоответсвий версий файлов
б) легкий перенос данных на новую версию/новый сервер, так как отдельно храниться эталонная часть Ирбиса, отдельно хранится все, что было изменено пользователем

2.

Gena написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > > 17. Давно назревает вопрос пересмотра
> > расположения
> > > всех файлов системы на сервере. Есть хороший
> > > подход MVC. Почему бы не начать его
> > использовать?
> > > Отдельно хочу сказать, что при постоянных
> > > обновлениях и доработках системы следить за
> > > десятками тысяч файлов просто нериально. Хочу
> > > вынести на обсуждение следующую идеологию
> > > расположения файлов на сервере Ирбиса:
> > >
> > >
> > > IRBIS64_SERVER/ - корневая папка сервера
> Ирбиса
> > > DATAI/ - папка ДАТАИ, в которой храняться
> > > неизменные форматы и ресурсные файлы из
> > > дистрибутива (эталонные!)
> > > DEPOSIT/
> > > ALL_DB_FILE(mst,xrf...)/ - одна папка
> для
> > > всех без исключения файлов баз данных. В
> случае
> > > чего ее и копировать проще
> > > DB1_RESURCE/ - для каждой отдельной
> базы
> > > содержать папку только под ее уникальные
> > ресурсы
> > > (эталонные!)
> > > ...
> > > DBN_RESURCE/
> > > DATAI_USER/ - папка с измененными,
> > > пользовательскими настройками
> > > DEPOSIT_USER/ - общие для всех баз
> > > измененные пользователем файлы
> > > DB1_RESURCE/ - измененные пользователем
> > > файлы для отдельной базы
> > > ...
> > > DBN_RESURCE/
> > > FULLTEXT/ - отдельная папка для полных
> текстов.
> > > При желание, в ней можно прописывать
> разделения
> > > какие-то, но при установке все 11 параметры
> > > пар-файлов должны ссылаться на одно файловое
> > > харилище.
> > >
> > >
> > >
> > > Очередность поиска ресурсов сервером на
> диске:
> > > 1. ищу ресурс в DATAI_USER/DB1_RESURCE
> > > 2. ищу ресурс в DATAI_USER/DEPOSIT_USER
> > > 3. ищу ресурс в DATAI/DB1_RESURCE
> > > 4. ищу ресурс в DATAI/DEPOSIT
> > >
> > > При таком расположении файлов любые
> > переустановки
> > > и переходы на новые версии будут максимально
> > > упрощены. Более того, при таком подходе уже
> > > появляется возможность построить систему
> > > автоматического обновления с удаленного
> сервера
> > -
> > > мы ничего не испортим в настройках клиента!
> > Замечательно. А как быть с соблюдением
> > преемственности версий?
>
>
> Александр Иосифович, наверное я не правильно
> понимаю значение приемственности, но как по мне,
> это возможность модулей более старых и более новых
> работать с одной ресурсной базой. АРМы у нас
> изолированы от ресурсов - с ними работает сервер.
> Если мы на сервере перераспределеляем файлы в
> другие места и правильно серверу все объясняем, то
> он отдает эти файлы АРМам в полном соответствии с
> их потребностями.
>
> Если тезисно, то вот что я описал в этом
> предложении:
> 1. отделить хранимую информацию (файлы базы) от
> ресурсов (форматы, РЛ, справочники...)
> 2. сделать дубляж директории DATAI, в котором
> будут храниться все изменяемые пользователем
> форматы. Это даст:
> а) полностью чистый дистрибутив на всех серверах
> пользователей, который будет обновляться
> автоматически без каких-либо поломок и
> несоответсвий версий файлов
> б) легкий перенос данных на новую версию/новый
> сервер, так как отдельно храниться эталонная часть
> Ирбиса, отдельно хранится все, что было изменено
> пользователем
>
Все понимаю и тем не менее не могу ничего обещать.

Alio написал(а):
-------------------------------------------------------

> Все понимаю и тем не менее не могу ничего обещать.


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

Добрый день!
Сейчас при работе с авторитетными файлами надо самому делать очень сложные настройки системы.
Насколько понимаю, веб-модуль вообще не учитывает АФ при поиске.
Предлагаю ввести параметр для дополнения поиска по ключевым словам и автору данными из АФ.

Gena написал(а):
-------------------------------------------------------

> 1. отделить хранимую информацию (файлы базы) от
> ресурсов (форматы, РЛ, справочники...)
> 2. сделать дубляж директории DATAI, в котором
> будут храниться все изменяемые пользователем
> форматы. Это даст:
> а) полностью чистый дистрибутив на всех серверах
> пользователей, который будет обновляться
> автоматически без каких-либо поломок и
> несоответсвий версий файлов
> б) легкий перенос данных на новую версию/новый
> сервер, так как отдельно храниться эталонная часть
> Ирбиса, отдельно хранится все, что было изменено
> пользователем
>

Это просто мечта! Особенно второй пункт. Если это реализуется, то это будет фантастика.

Мечтать - это хорошо... Ответьте мне, что при этой системе будет делать пользователь, если в очередном обновлении разработчик изменит базовый формат (не имеющий никаких вложений), который до этого был изменен самим пользователем?

Alio написал(а):
-------------------------------------------------------
> Мечтать - это хорошо... Ответьте мне, что при этой
> системе будет делать пользователь, если в
> очередном обновлении разработчик изменит базовый
> формат (не имеющий никаких вложений), который до
> этого был изменен самим пользователем?


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

НО! Самое главное тут в том, что у самого пользователя (точнее, администратора) будет возможность увидеть два файла: эталонный в своей части, и пользовательский в своей, сравнить их любым ПО для сравнения текстовых файлов и принять решение о ручном обновлении

Gena написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > Мечтать - это хорошо... Ответьте мне, что при
> этой
> > системе будет делать пользователь, если в
> > очередном обновлении разработчик изменит
> базовый
> > формат (не имеющий никаких вложений), который
> до
> > этого был изменен самим пользователем?
>
>
> Александр Иосифович, такой формат должен будет
> оказаться в эталонной части Ирбиса. Если при этом
> есть пользовательский вариант этого файла, то
> формат от разработчика просто останется
> неиспользуемым.
>
> НО! Самое главное тут в том, что у самого
> пользователя (точнее, администратора) будет
> возможность увидеть два файла: эталонный в своей
> части, и пользовательский в своей, сравнить их
> любым ПО для сравнения текстовых файлов и принять
> решение о ручном обновлении
Еще вопрос. Чем плоха простейшая система ведения собственных изменений, которая предлагалась с самого начала: изменил какой-то ресурс - сбрось его в свой внешний депозит, установил новую версию - верни свои изменения на прежнее место (если надо, после предварительного сравнения)

Такой вариант сейчас чаще всего и используется. Но он требует повышенного внимания со стороны администраторов. А с учетом того, что в небольших библиотеках достаточно большая текучка с ит-специалистами, освоение регламентов работы и обновлений для них бывает сложным.

Gena написал(а):
-------------------------------------------------------
> Такой вариант сейчас чаще всего и используется. Но
> он требует повышенного внимания со стороны
> администраторов. А с учетом того, что в небольших
> библиотеках достаточно большая текучка с
> ит-специалистами, освоение регламентов работы и
> обновлений для них бывает сложным.
Однако... А ведение структуры папок, которую ты предлагаешь, не требует повышенного внимания и участия IT-специалиста?

Давайте не путать данные и пользовательские формы, отчеты, форматы.

Для каталога каждой базы данных (mst) желательно указать отдельный путь, а не DATAI и далее по имени базы данных. Чтобы можно было обеспечить отдельное хранилище для файлов баз данных.

Т. е. разнести библиографическую информацию, полнотекстовые ресурсы и файлы ирбиса (pft,srw)

Для файликов ирбиса лучше была бы такая схема

DB_user -> DB_dir -> Deposit_user -> Deposit

+

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

Например, при работе в linux ни разу не потребовалось ставить окружение рабочего стола...

woodyfon написал(а):
-------------------------------------------------------
> Давайте не путать данные и пользовательские формы,
> отчеты, форматы.
>
> Для каталога каждой базы данных (mst) желательно
> указать отдельный путь, а не DATAI и далее по
> имени базы данных. Чтобы можно было обеспечить
> отдельное хранилище для файлов баз данных.
>
> Т. е. разнести библиографическую информацию,
> полнотекстовые ресурсы и файлы ирбиса (pft,srw)
>
> Для файликов ирбиса лучше была бы такая схема
>
> DB_user -> DB_dir -> Deposit_user -> Deposit
>
> +
>
> Пожелание развития: выпустить консольный
> АРМ-Каталогизатор.
Это как?

В связи с началом разработки
> Linux - это должно быть.
>
> Например, при работе в linux ни разу не
> потребовалось ставить окружение рабочего стола...

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

Конечно, консольный АРМ-Администратор. Сорри, оговорился.

Эти пожелания перенесите в тему ИРБИС и LINUX

По результатам этой темы
[irbis.elnit.org]

возник вопрос-предложение:

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

levaleva написал(а):
-------------------------------------------------------
> По результатам этой темы
> [irbis.elnit.org]
>
> возник вопрос-предложение:
>
> Нельзя ли реализовать полноценную поддержку
> относительных путей?
Что это значит?

Чтобы это работало во всех
> подсистемах ИРБИСА. Или это будет чрезвычайно
> трудоемким?

Пожелания развития Web-IRBIS+:

Если появилась единая строка поиска, то сделать настраиваемые релевантность и ранжирование результатов поиска.