Галактика в вопросах и ответах

После февральской докомпиляции появились 139 новых таблиц

Запросы в старой базе и в новой В старой базе 2816, в новой 2955

Если в протекте я удаляю все таблицы у пользователя (2399), а потом добавлю (2540), то разница будет 141 таблица

Мне бы хотелось автоматом дать права на новые таблицы к каждому пользователю

Здравствуйте.
Тоже интересует этот вопрос.
Кажется летом 2018 у пользователей, работающих в Управлении персоналом и/ или в з/п после установки очередных патчей стало выдаваться сообщение (ошибка или предупреждение — не помню). И нельзя было ввести б/л. Хорошо, что периодически читаю тхт к патчам и видела доработки по б/л. Оказалось, что после очередной докомпиляции появилась пара новых таблиц, связанных с расчетом б/л. А в доступных таблицах пользователей указанных модулей этих таблиц не было. Как только добавила вручную, сообщение перестало выдаваться.
Т.о. хорошо, если конкретные пользователи при работе не затрагивают новые таблицы, появившиеся после докомпиляции. Иначе придется отлавливать нужные новые таблицы и добавлять права на них.
Думаю, что это вопрос к разработчикам по добавлению прав на новые таблицы. Но, если кто-то знает как это сделать, то это будет полезно и для всех ))).

Ну хотя бы можно мониторить при установке патчей новая ли версия Alter_Cumulative_exe_9XXXX.acd у Вас будет.
Если архив распаковать , то там есть Alter_Cumulative.chm, в котором есть подраздел "Что нового". Внутри него по датам обычно
расписано какие таблицы будут поменяны этим обновлением, а какие добавлены в БД.

Начинающий путь писал(а):После февральской докомпиляции появились 139 новых таблиц

...

Мне бы хотелось автоматом дать права на новые таблицы к каждому пользователю

хм ... а нужен ли вам тогда протект ?

но, если все-таки протект нужен и если это все на ORACLE происходит, то очень рекомендую параметр UseSQLRole ставить в ON и пользовать роли для групп.

Тогда достаточно создать некую убер-пупер-группу типа "можно для всех", включить в её состав всех юзеров и давать в эту группу права на те таблицы, которые Вы хотели бы раздать всем пользователям.

Ну и при изменении перечня таблиц или прав, добавлять их ТОЛЬКО в эту группу и производить пересчет ТОЛЬКО для данной группы, не пересчитывая ни остальных групп ни пользователей.
Т.е. права, данные в эту группу будут назначены в отдельную роль (ибо UseSQLRole=ON), а сама эта роль УЖЕ назначена всем пользователям, следовательно они получат соответствующие права моментально и без долгих пересчетов.

группа считается минуты или секунды.
Профит очевиден !!!

Irina_ писал(а):Здравствуйте.
Тоже интересует этот вопрос.
... Иначе придется отлавливать нужные новые таблицы и добавлять права на них.
...

Ирина!
Если алтеркамулятив запустить и присмотреться к интерфейсу, то там можно обнаружить кнопочку HELP, нажав на которую Вы получите в удобном виде всю интересующую Вас информацию и об изменениях о модулях и о связанных с ними новых таблицах.

AlexMK писал(а):
хм ... а нужен ли вам тогда протект ?

AlexMK, разумеется , никто не ставит под сомнение нужность Protect-а.
А вот в плане таблиц идеология его то, что умолчанию все "запрещено", сомнительна.
Что же тогда не закрывают его средствами(даже с возможностью выставлять фильтры на таблицы по условиям) возможность , скажем, редактирования накладной, а придумывают прикладные настройки на эту тему и все что этому сопутствует. Конечно, бывают случаи , когда можно и прикрыть доступ к той или иной табле. Но они не так часты.
Так что когда добавляется куча новых прикладных таблиц с очередным alter (как писали в начале топика больше сотни), то логичнее чтобы они сразу были всем разрешены.

Den писал(а): ...
А вот в плане таблиц идеология его то, что умолчанию все "запрещено", сомнительна.
...

Ну по поводу построения защиты в функциональной части я не скажу - не являюсь ни архитектором ни конструктором ,
а вот на уровне СУБД в целом и конкретно в ORACLE изначально все именно так и обстоит - всё, что не разрешено, запрещено.

В xNIX-ах всяческих с раздачей прав гибче - можно сделать All Deny (все запретить) и что-то разрешить, а можно и наоборот Allow All (все разрешить) и кое-что конкретное запретить.

Ко всему сказанному хотелось бы добавить следующее - Вы разделяйте доступ и ограничения доступа функциональные и физические.
В ту же накладную информация собирается из множества таблиц.
Функциональные ограничения накладываются на прикладные объекты и методы.
А вот ограничения или наоборот права на отдельные таблицы применяются, если можно так сказать, к физическим объектам в БД.
Кроме того следует помнить, что доступ к таблицам пользователи могут получить и мимо Галактики, подключившись к БД соответствующим софтом.
Потому физические ограничения весьма актуальны.

Другое дело, что для удобства пользования и назначения прав на физические объекты в соответствии с правами на функционалы, что-то реализовать бы - это да.
Но это ж надо в каком-то метасловаре держать и на него ориентироваться да еще и на разных платформах поддержать, да еще и оперативно при изменениях вести.
Большая работа однако.

p.s. А вот использование ролей для групп - очень настоятельно рекомендую.

!!!!!! ВАЖНО !!!!!
При конвертации на MSSQL на 33 атлантис криво встают индексы у RAISE и RAISEHIST. Смотреть в студии, в сапорте все хорошо. Патч должен быть 22.02.

edward_K писал(а):!!!!!! ВАЖНО !!!!!
При конвертации на MSSQL на 33 атлантис криво встают индексы у RAISE и RAISEHIST. Смотреть в студии, в сапорте все хорошо. Патч должен быть 22.02.

на оракле такая же канитель. Причем касается не только таблиц raisehist и raise. Как минимум это еще KLPROG, EADLINK, DOCFILTERS. Докомпилятор делает во всех вновь создаваемых таблицах все индексы уникальными. Причем создает в бд и декларативные индексы (ref в support'е) чего быть вообще не должно. Проверка чекорой исправляет только недекларативные. В результате имеем в бд уникальный индекс, соответствующий ref в support'е. И если в таблице перед докомпиляцией были данные, то после докомпиляции они будут утрачены. Такая ситуация как раз с таблицами raisehist, klprog, eadlink, docfilters - при докомпиляции из них данные выгружаются, таблицы создаются заново с описанными выше последствиями.

но, если все-таки протект нужен и если это все на ORACLE происходит, то очень рекомендую параметр UseSQLRole ставить в ON и пользовать роли для групп.

Тогда достаточно создать некую убер-пупер-группу типа "можно для всех", включить в её состав всех юзеров и давать в эту группу права на те таблицы, которые Вы хотели бы раздать всем пользователям.

Ну и при изменении перечня таблиц или прав, добавлять их ТОЛЬКО в эту группу и производить пересчет ТОЛЬКО для данной группы, не пересчитывая ни остальных групп ни пользователей.
Т.е. права, данные в эту группу будут назначены в отдельную роль (ибо UseSQLRole=ON), а сама эта роль УЖЕ назначена всем пользователям, следовательно они получат соответствующие права моментально и без долгих пересчетов.

группа считается минуты или секунды.
Профит очевиден !!!

на MSSQL есть возможность использовать такой же подход?

Chernikov писал(а): на MSSQL есть возможность использовать такой же подход?

так точно.
только имена ролей более вменяемые - на оракле роли именуются по НРЕКу группы, а в MS имя группы в Галактике попадает в имя роли в СУБД.
вместо GAL##8001000000001234 на ORACLE в MS будем иметь что-то типа GR##Бухгалтеры.