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

[Varmen]

удаляю группы пользователей, многие без проблем удалились.
А некоторые как оказалось таки остались в системе висеть.
Т.е при удалении - без проблем удаляются (визуально), после повторного вызова формы группы, опять воскресают, как будто ничего не делалось.
Что тут не так ?

[Varmen]

бьюсь пока безрезультатно.

Группа не содержит пользователей
Группа больше не содержит прав.
Группа удаляется стандартной кнопкой удалить запись в форме "Группы пользователей".
Группа пропадает из формы.
Группа появляется если, включить сортировку.

[Varmen]

обнаружил интересный феномен:
если изменить запись средствами Аксапты, нпаример изменить описание группы, то не обновляются системные поля:
Дата Модификации,Время Модификации, Автор Модификации !

Если вручную завести новую группу. То она удаляема и и изменения находят отклик в выше указанных полях.

[Varmen]

экспортировал и импортирвал UserGroupInfo. Теперь системные поля обновляются.
Но проблема с удалением осталась.

[mazzy]

Цитата:

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

Но проблема с удалением осталась.

Может кто-нибудь триггера непосредственно в SQL к этой таблице прицепил?

[Михаил Андреев]

Цитата:

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

Может кто-нибудь триггера непосредственно в SQL к этой таблице прицепил?

ИМХО, где-то закомментировали super() при правке метода delete(). Но наверняка в доработке дело. Если часть удаляется, а часть нет.

[2tim]

Цитата:

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

экспортировал и импортирвал UserGroupInfo. Теперь системные поля обновляются.
Но проблема с удалением осталась.

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

[Михаил Андреев]

Цитата:

Сообщение от 2tim

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

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

[Varmen]

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

[Varmen]

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

[Dron AKA andy]

Потому что они в "System Documentation \ Tables".

[Varmen]

Спасибо, за наводку.

обнаружил, что в злополучной таблице SysSRTablePermissions неудаляемые группы имеют море записей.
Хотя у них нет прав.
Аналогичаная группа созданная руками. В етой таблице не имеет записей.
Удалил "левые" записи из этой таблицы (т.е записи приндлежащие этим группам и несществующим более доменам, странно как это могло произойти). После этого группы начали, удалятся

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