НАЧАЛО >> Подсистема безопасности >> Служебное поле 113📄 Скачать в DOCX
Поле 113 используется ИРБИС 128 как служебное поле совместимости, идентификации объектов, прав доступа и некоторых доменных связей. Это не универсальное поле ИРБИС 64, которое должно автоматически появляться в каждой записи.
Обычные операции чтения и сохранения записи через Database, DP_Irbis64Native и другие провайдеры не создают поле 113 автоматически. Если поле уже есть в записи, оно сохраняется как часть физической записи и участвует в форматировании, индексировании и экспорте так же, как остальные поля.
Security является владельцем модели прав и служебных повторов 113, которые описывают доступ к записи:
| Повтор | Назначение |
|---|---|
^ASID |
Системный идентификатор записи, владелец и флаг наследования прав. |
^ASEC |
Право доступа для группы, пользователя, IP, сайта или другой группы безопасности. |
^ALINK |
Служебная связь записи с другим объектом по SID. |
^AAUTH |
Данные авторизации пользователя, если конфигурация авторизации использует поле 113. |
^AROLES |
Роли пользователя. |
^AMVIDS |
Разрешенные места выдачи пользователя для интерфейсов WIrbis/Bookland. |
^ASIDTHREAD |
Служебная цепочка подчиненных объектов. |
Доменные модули могут иметь собственные совместимые повторы. Например, FT использует 113^AFT для связи библиографической записи с полнотекстовым объектом. Такой повтор создается кодом модуля FT, а не общим слоем Database.
Создавать или изменять служебные повторы 113 нужно только явным вызовом API соответствующего модуля:
| Операция | API |
|---|---|
| Создать физический SID | Security::EnsurePhysicalSid() |
| Добавить права по умолчанию управляемого объекта | Security::EnsureDefaultRights() |
| Выполнить совместимую legacy-материализацию прав и SID | Security::MaterializeRecordSecurity() |
| Добавить или обновить право | Security::MaterializeRight() |
| Удалить локальное право | Security::DeleteLocalRights() |
| Сделать унаследованное право локальным | Security::MakeRightsLocal() |
| Изменить наследование прав | Security::SetRightsParenting() |
| Изменить владельца SID | Security::SetOwnerSid() |
Создать или удалить LINK |
Security::MaterializeLink(), Security::DeleteLink() |
| Записать данные авторизации | Security::MaterializeAuth() или Security::MaterializeAuthField() |
| Записать роли пользователя | Security::SetRoles(), Security::EnsureRole() |
| Записать места выдачи пользователя | Security::SetMvids() |
Код, который только читает или сохраняет запись, не должен вызывать эти методы без явного пользовательского или доменного действия. Низкоуровневый Record::SetSid() остается внутренним механизмом физической записи 113^A=SID, но прикладные модули должны обращаться к нему через Security::EnsurePhysicalSid(). Legacy-обертки Record::EnsureSid() и Record::SidSave() допускаются только как совместимость: материализация SID в них проходит через Security.
Форматы, списки записей, деревья, preview-панели и другие операции отображения не должны создавать SID и не должны сохранять запись только ради появления поля 113. Если для кеша отображения нужен устойчивый ключ, нужно использовать уже существующий SID или внешний cache-key, не изменяющий запись.
Инвариант проверяется self-test tools/Record113BoundarySelfTest.php: обычные операции Database не должны материализовать 113, включая повторное сохранение после конфликта версии, lookup по SID не должен вызывать низкоуровневый SetSid(), а явное создание SID и прав выполняется через Security. Тот же тест покрывает legacy helper старого WS-редактора WS/JS/GetRLList: если helper должен передать SID в URL и Ajax-параметры, он сначала явно вызывает Security::EnsurePhysicalSid(), а затем использует уже материализованный SID.
Если запись уже содержит поле 113, ИРБИС 128 должен сохранить его без потерь. Это важно для совместимости с существующими базами, форматами, индексированием и проверками соответствия irbistool.
Провайдеры данных отвечают за физическое чтение и запись полей. Они не принимают решение о том, что записи нужен SID, право, роль или связь. Такое решение принимает Security или доменный модуль, который выполняет конкретную пользовательскую операцию.
Операции миграции и слияния записей могут переносить уже существующее физическое поле 113 из одной записи в другую. Это не считается автоматической генерацией. Такие операции должны сохранять структуру поля как данные источника и не добавлять новые служебные повторы без явной цели миграции.
Очистка старых некорректных повторов, например пустых LINK, допускается как миграционная или доменная нормализация данных. Она должна быть локализована в соответствующем модуле и не должна превращаться в общее правило сохранения записи.