удаление групп пользователей

[Varmen]

к сожалению нет доступа к базе данных.
А возможные виновники не смогли обяснить, кроме как убить некоторые из записей эскуелем.
Таблица SysSRTablePermissions, она за что отвечает? Похоже орлы только из UserGroupInfo удалили (группы не имеют юзеров, не имеют прав).

[Varmen]

А почему этих "горе таблиц" (UserGroupInfo) нет в дата dictionary?

[Kabardian]

Нагуглил решение проблемы, т. к. и сам с ней столкнулся.

Выкладываю вольный перевод статьи Certain User groups cannot be deleted in Dynamics AX:

Цитата:

Иногда, когда я пытаюсь удалить определенные группы пользователей в Dynamics AX 4.0 или Dynamics AX 2009 я замечаю, что группы пользователей удаляются из грида, но на самом деле не удаляются.

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

Причина, по которой определенные группы пользователей не могут быть удалены -- это некорректные записи в таблице SysSRSTablePermissions. В этой таблице хранится одна запись для каждого домена, группы пользователей и AX Secure View. Если таблица, на которой основана SSRS Secure View, была удалена из AOT, то может так случиться, что соответствующая ей запись все еще находится в этой системной таблице.

Во время удаления группы пользователей SSRS Secure Views тоже обновляются. Если во время этой синхронизации SSRS Secure Views, окажется, что таблица не найдена в AOT, то процесс синхронизации прерывается. Прерывание сопровождается командой ttsabort и транзакция целиком откатывается. Поэтому группа пользователей не удаляется.

Для того, чтобы все-таки удалить такую "проблемную" группу пользователей, необходимо удалить некорректные записи в таблице SysSRSTablePermissions.
Следуя указанным ниже шагам, все записи в таблице SysSRSTablePermissions обновляются для выбранной группы пользователей:

1. Откройте форму Администрирование / Настройка / Группы пользователей
2. Выберите группу пользователей, которую необходимо удалить
3. Нажмите кнопку Права доступа
4. Выполните следующие шаги для всех существующих доменов:
   1. Выберите домен в списке Домены
   2. Перейдите на закладку Права доступа
   3. Выберите любой ключ безопасности и выполните любое изменение уровня доступа (например, измените его с Нет доступа на Просмотр)
   4. Отмените изменения, которые вы сделали на предыдущем шаге ( например, верните уровень доступа с Просмотр на Нет доступа)
   5. Сохраните изменения и вернитесь на закладку Обзор
5. После перебора всех доменов закройте форму Права групп пользователей
6. Теперь в форме Группы пользователей можно продолжить удаление выбранной группы пользователей

Чтобы определить, существуют ли некорректные записи в таблице SysSRSTablePermissions вы можете запустить следующий джоб:

static void CheckSRSTablePermissions(Args _args)
{
    SysGroup groupName;
    SysSRSTablePermissions srsp;
    DictTable dictTable;
    int validTables = 0;
    int invalidTables = 0;
    ;
 
    //////////////////////////////////////////////
    //This is the name of the group to check for//
    groupName = 'Group1';
    //////////////////////////////////////////////
 
    info(strFmt('CheckSRSTablePermissions: Checking SRS Tables for Group \'%1\'!', groupName));
 
    while select srsp where srsp.GroupId == groupName
    {
        dictTable = new DictTable(srsp.TabId);
 
        dictTable)
        {
            invalidTables++;
            warning(strFmt('Tha Table with the ID 0x%1 does not exit!', int2hex(srsp.TabId,4)));
        }
        else
            validTables++;
    }
 
    if(validTables + invalidTables > 0)
        info(strFmt('CheckSRSTablePermissions: %1 Tables are valid, %2 Tables are invalid', validTables, invalidTables));
    else
        warning('CheckSRSTablePermissions: No Tables were found!');
}

Джоб чуть-чуть видоизменил, чтобы он вообще по всем группам пользователей бегал и выводил:

• tableid в десятичной системе счисления, а не в шестнадцатеричной
• название проблемной группы пользователей

static void CheckSRSTablePermissions(Args _args)
{
    SysGroup groupName;
    SysSRSTablePermissions srsp;
    DictTable dictTable;
    int validTables = 0;
    int invalidTables = 0;
    ;

    while select srsp
    {
        dictTable = new DictTable(srsp.TabId);

        if (!dictTable)
        {
            invalidTables++;
            warning(strFmt('Таблица с ID %1 не существует для группы %2!', srsp.TabId, srsp.GroupId));
        }
        else
            validTables++;
    }

    if(validTables + invalidTables > 0)
        info(strFmt('CheckSRSTablePermissions: %1 Tables are valid, %2 Tables are invalid', validTables, invalidTables));
    else
        warning('CheckSRSTablePermissions: No Tables were found!');
}

Хотя запуск джоба в моем случае показал, что он не все проблемные группы ловит.

Цитата:

Сообщение от Varmen

Таблица SysSRTablePermissions, она за что отвечает?

В таблице SysSRSTablePermissions хранятся права доступа к таблицам для проверки прав доступа пользователя, когда он строит отчеты с помощью Report Builder в SSRS. И соответсвенно, для каждой группы пользователей эти права определяются именно в таблице SysSRSTablePermissions.

Очевидно, никто не ломал целостность данных нарочно, а произошло это случайно, как описано в указанной выше статье "it can happen"