[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"