Логирование изменений и открытие доступа к домену

[Logger]

Недавно обнаружил странный глюк.

Если для пользователя выключен ключ контроля доступа SysOpenDomain (Открытие доступа к домену), то для него может не работать логирование изменений (sysdatabaselog) в табличках

Рассмотрим пример.
Предположим, мы хотим контролировать изменения в какой либо табличке (напр. заказы) для всех пользователей. Для этого мы настраиваем для домена Admin логирование этой таблички.
Для пользователя N выключен ключ SysOpenDomain и даны права только в домене DOMAINX, а в домене Admin никаких прав нет (т.е. он видит только компании из домена DOMAINX а о других даже не подозревает и зайти в них не может)

В итоге для этого пользователя не логируются изменения в заказах !
чтобы они логировались, нужно либо настроить это логирование также для домена DOMAINX либо дать ему доступ на ключ SysOpenDomain. Считаю что это бага, так как настройка прав доступа не должна влиять на настройки логирования таблиц.

Полагаю что глюк возникает из-за того что отключение ключа SysOpenDomain и отсутствие прав на домен Admin приводит к тому что настройки логирования домена Admin становятся просто не доступны этому пользователю и ядро считает что никакого логирования не настроено


P.S.
Ax 3.0 KR3 application SP5

[Dron AKA andy]

На DAX 4.0 СП2 (несколько kernel builds) такой проблемы не обнаружено.

[Eldar9x]

Мы под пользователем Admin на тройке проводили тесты. С одного аоса логируется, с другого - нет. Приложение и база одна. Перезагрузили аосы, стало с обоих логироваться. Только почему-то все радостно верят, что помогла настройка прав

[Logger]

Zitat:

Zitat von Eldar9x

Мы под пользователем Admin на тройке проводили тесты. С одного аоса логируется, с другого - нет. Приложение и база одна. Перезагрузили аосы, стало с обоих логироваться. Только почему-то все радостно верят, что помогла настройка прав

Вы описали совсем другую проблему.
По идее она должна решаться стартом на каждом аосе такого кода :
\Classes\SysFlushDatabaseLogSetup\doFlush

Т.е. перестартовывать аос необязательно.

P.S. Описанная в топике проблема существует. Вы б для начала проверили, прежде чем писать.

[Eldar9x]

Zitat:

Zitat von Logger

Вы описали совсем другую проблему.
По идее она должна решаться стартом на каждом аосе такого кода :
\Classes\SysFlushDatabaseLogSetup\doFlush

Т.е. перестартовывать аос необязательно.

P.S. Описанная в топике проблема существует. Вы б для начала проверили, прежде чем писать.

Я и не утверждаю, что такой проблемы нет. Может быть и есть. А разговор о том, что текущую проблему якобы решили, настройкой, которая к ней вообще не имеет никакого отношения.
Да вобщем-то, уже все равно. Меня то мой вопрос интересует. Вот SysFlushDatabaseLogSetup\doFlush она что именно делает?

[Logger]

Он вправляет аосу мозг. Сбрасывает его внутренний кеш настроек логирование и пишет в служебный лог информацию для других аосов, чтобы они тоже кеши сбросили.

[Eldar9x]

Ясно, спасибо

[Murlin]

Zitat:

Zitat von Eldar9x

Мы под пользователем Admin на тройке проводили тесты. С одного аоса логируется, с другого - нет. Приложение и база одна. Перезагрузили аосы, стало с обоих логироваться. Только почему-то все радостно верят, что помогла настройка прав

Cамое интересное что при удалении записи в таблице доменов грохаются все записи в правах доступа, даже те которые не настроена на данный домен. Мощт это как то связано?

[Murlin]

Zitat:

Zitat von Eldar9x

Мы под пользователем Admin на тройке проводили тесты. С одного аоса логируется, с другого - нет. Приложение и база одна. Перезагрузили аосы, стало с обоих логироваться. Только почему-то все радостно верят, что помогла настройка прав

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

Кэш данных с несколькими АОСами
Причем такая же ерунда была на 4ке. Даже перезапуск клиента не помогал