Никак не могу определиться с подходом, нужен свежий взгляд.
Не посоветуете, какой подход лучше?

Есть список объектов, организованных в иерархическую структуру (как каталоги и файлы).
Структура, например, выглядит так:
Все объекты можно условно поделить на три вида: публичные, категорийные и приватные.

Также есть группы пользователей и список пользователей, каждый из которых принадлежит определенной группе.
Группы пользователей также бывают трех видов: публичные, категорийные и приватные. Например такие:
ГруппаВидПользовательПубличнаяпубличная-Категория Низкийкатегорийнаяcat-lowКатегория Дубкатегорийнаяcat-oakКатегория Рябинакатегорийнаяcat-rowГруппа 1приватнаяusr1Группа 2приватнаяusr2

У каждой группы пользователей задается список объектов, к которым предоставляется доступ пользователям группы.
К публичным объектам доступ есть у всех групп пользователей.
Категорийные объекты находятся в /Круглый/Красный и /Круглый/Синий; к категорийным объектам доступ есть только у групп соответствующей категории.
Приватные объекты находятся в /Треугольный; к приватным объектам доступ есть только у приватных групп соответствующей категории.
Для работы с объектами и пользователями и задания прав доступа системы есть соответствующее конфигурационное ПО. Однако оно плохо подходит для массовых операций, а у меня ожидается, что количество объектов будет измеряться сотнями, а количество групп пользователей тысячами, поэтому использование этого ПО в таких условиях затруднено. Однако у системы есть API и мною разработан некий скрипт, который осуществляет периодическую синхронизацию доступа к объектам.

С категорийными и приватными объектами я представляю, что нужно делать — для cat-low предоставляю доступ к объектам /Круглый/Красный/Низкий, для usr1 предоставляю доступ к объектам /Треугольный/Группа1 и так далее.
Но вот с публичными объектами вышла некоторая сложность.
Пока что я не могу однозначно определить формальные признаки, по которым объект можно классифицировать, как публичный. Поэтому я рассматриваю два подхода:
1. В скрипте вручную задаю список всех каталогов, объекты которых считаются публичными. Если перечень публичных объектов изменяется, значит я обновляю этот список в скрипте.
2. С помощью конфигурационного ПО я вручную настраиваю список доступа для группы Публичная. И в дальнейшем скрипт использует этот список, как шаблон. Если перечень публичных объектов изменяется, я с помощью конфигурационного ПО обновляю список доступных объектов для группы Публичная, а скрипт при очередном запуске подхватит эти изменения.

Я больше склоняюсь ко второму варианту, но все же окончательно определиться не могу.

Да, верное замечание.
Я как-то упустил, что конфигурированием ПО могут заниматься другие люди.
Спасибо, действительно взгляд со стороны помог.

Есть информационная система ИС1, которая и имелась ввиду в первом сообщении.
Есть информационная система ИС2.
В ИС1 есть объекты, которые создаются с помощью готового инструментария ИС1.
В ИС1 также есть инструментарий для работы с группами и пользователями, но он не подходит под задачу.
Группы и пользователи создаются в ИС2.
Скрипт осуществляет синхронизацию пользователей и групп из ИС2 в ИС1, а также назначает права доступа в соответствии с определенными шаблонами (указанными выше).

Вопрос был в том, как организовать назначение прав доступа к публичным объектам — задавать его в коде скрипта или использовать в качестве шаблона назначенные права в ИС1.
Но после замечания 21616342 мне стало ясно, что нужно использовать именно второй вариант.

alex55555Стандартный для сисадмина подход - нужно слепить нечто из скриптов и существующих систем.
Мне кажется, что это вполне разумный и рациональный подход для интеграции гетерогенных систем.
Информационные системы ИС1 и ИС2 друг о друге даже не подозревают, они работают сами по себе.
Но у них есть API — как раз случай интеграции с внешними системами.
Альтернативой было бы изменение программного кода ИС1 или ИС2 с целью взаимодействия, но это недальновидная альтернатива. Во-первых такая модификация будет дорогой и разовой, а программный код обоих информационных систем постоянно дорабатывается. А во-вторых, подобный подход себя прекрасно зарекомендовал во многих системах, в то время, как монолитный продукт эффективен далеко не везде.

alex55555Альтернатива с точки зрения программиста - что-то вроде шины.
Видимо я не понимаю, о чем идет речь.
По всей видимости имеется ввиду, что API — это не шина.
А что тогда шина? Третья информационная система (сервер), которая будет загружать информацию с ИС1 и ИС2, держать в памяти текущие состояние и при изменениях состояний вносить изменения в ИС2 (через то же API)? То есть функционально вся разница будет в том, что синхронизация будет выполняться не по расписанию, а по событию?
Или речь о другом?

alex55555Третья ИС (хотя это громко, в вашем случае - небольшая программа) обеспечивает ту гибкость и функциональность, которых нет в скрипте.
Ну тогда осталась только мелочь — дать определение и различие между понятиями "программа" и "скрипт".
Для описанной задачи мой скрипт запускается периодически, не храня состояние между запусками.
Видимо отличие в том, что программа будет запущена постоянно, либо будет сохранять состояние между запусками.
И если честно, я не вижу ни малейшего смысла в этом — так или иначе это будет сравнение данных между двумя ИС и однонаправленная синхронизация. Хранение состояний не дает какого-либо практически полезного эффекта.
Какой-то смысл был бы в доработке ИС2 — чтобы вносимые в нее изменения (пользователи и группы) автоматически применялись к ИС1 через соответствующее API. Технически это возможно и вот тогда это была бы настоящая синхронизация данных по событию, а не эмуляция событий. Но такое решение экономически нецелесообразно, изменение ИС2 дорогое и не окупится.

alex55555Отличие в том, что вы руками будет вбивать сотни меняющихся записей каждый раз самостоятельно отслеживая их изменения.
Правда? И откуда же такой вывод?
Регулярно меняющиеся сотни записей меняются автоматически, в соответствии с формальными критериями, это категорийные и приватные объекты.
Вручную задаётся список публичных объектов (либо в скрипте, либо в конфигурационном ПО). Но этот список меняется редко и он в любом случае задаётся вручную.