Вопрос по правам.

[axalex]

Приветствую! Пользуюсь MS DAX 5.0.1500.3761 Rollup6, SQL Server 2008 R2.

Прошу помочь разобраться с вопросами.
Первый.
Например, по адресу /Расчеты с клиентами/Расчеты с клиентами/Сведения о клиенте - я добавил кнопку на форму, которую не желательно видеть пользователям.
И параллельно есть огромное количество групп пользователей, в которых в большинстве нужно её скрыть(кнопку). Вручную - довольно длительный процесс..
Можно ли массово убрать доступ к данной кнопке/объекту (таблицы системные)?
(Через SQL смотрел, но хочется через DAX)

Второй.
На сколько я знаю в АХ помимо админов-разработчиков-консультантов, есть супер-администратор (далее Admin), который просто так нельзя убрать даже просто админом. Как присваивается данный статус? Возможно ли его изменить на другого пользователя?

Заранее спасибо.

[_scorp_]

Первый вопрос. Можно массово. В контейнере groups перечислите группы, для которых нужно закрыть доступ на menuItem. Предполагается что кнопка это menuItem. Вот Job:

static void setRights(Args _args)
{
    SecurityKeySet      secSet;
    UserGroupInfo       userGroup;
    DomainInfo          domain;
    AccessType          currentAccessType;
    MenuItemName        name = menuItemDisplayStr(InventTable);
    AccessRecordType    type = AccessRecordType::MenuItemDisplay;
    container           groups = ['group1, group2', 'group3'];
    ;
    while select userGroup
        where userGroup.Id != 'Admin'
    {
        if (confind(groups, userGroup.Id) != 0)
        {
            while select domain
            {
                secSet = SysSecurity::constructSecurityKeySet();
                secSet.loadGroupRights(userGroup.id, domain.Id);
                currentAccessType = secSet.menuItemAccess(name, type);
                if (currentAccessType != AccessType::NoAccess)
                {
                    secSet.menuItemAccess(name, type, currentAccessType);
                    xAccessRightsList::saveSecurityRights(secSet.pack(), userGroup.Id, domain.Id);
                }
            }
        }
    }
}

Второй вопрос не понял.

[axalex]

Цитата:

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

Первый вопрос. Можно массово. В контейнере groups перечислите группы, для которых нужно закрыть доступ на menuItem. Предполагается что кнопка это menuItem.

Да, menuitem. Оказалось не так сложно. Спасибо - буду пробовать!

Цитата:

Второй вопрос не понял.

В списке пользователей у меня висит некий user с кодом пользователя Admin. Его невозможно отключить. Якобы, тот кто первый получает данный код пользователя, становится главным администратором в DAX.
При попытке удалить\отключить - вываливается ошибка "Невозможно произвести замену Admin". Вскрываем ошибку - вылетает код (для понятности):

//Класс UserInfoHelp
static server boolean validateAdmin(UserInfo _userInfo)
{
    #admin
    UserGroupList   _userGroupList;
    ;
    setprefix("@SYS29011");

    if (_userInfo.Id == #AdminUser)
    {
        error(strfmt("@SYS29012", _userInfo.Id));
        return false;
    }

    select firstonly RecId from _userGroupList
        where _userGroupList.UserId == _userInfo.Id &&
              _userGroupList.GroupId == #AdminUserGroup;

    if  (_userGroupList)
    {
        select firstonly RecId from _userGroupList
            where _userGroupList.UserId != _userInfo.Id &&
                  _userGroupList.GroupId == #AdminUserGroup;

        if (!_userGroupList)
        {
            error(strfmt("@SYS29013", _userInfo.Id));
            return false;
        }
    }
    return true;
}

Можно ли пользователя удалять\заменить? Обязательно ли, если удалю, присвоить код пользователя "Admin" другому пользователю?

[mnt_dx]

По первому вопросу: можно создать SecurityKey, указать в свойствах кнопки и выдавать только нужным группам пользователей.

[_scorp_]

Не нужно удалять этого пользователя. Это системная учетная запись предоставляется пользователю, который устанавливал AX. Удалить или отключить эту учетную запись нельзя - этим гарантируется то, что всегда есть учетная запись админа. А то ведь в настройках прав можно было бы случайно доиграться так, что не осталось бы администратора в системе.
Заменить пользователя, которому принадлежит учетная запись admin можно. Поменяйте ему SID (поищите на форуме как это делать если не знаете).

[_scorp_]

Цитата:

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

По первому вопросу: можно создать SecurityKey, указать в свойствах кнопки и выдавать только нужным группам пользователей.

Не нужно так делать. Встречал такие подходы.
1. Потом черт ногу сломит в этих security-ключах.
2. Фиг знает где его в дереве искать. И только один "гуру-человек" знает где все это находится.
3. Сталкивался с тем, что SK могут работать только с глубиной иерархии не больше 2-х. Подробностей не помню, но что-то было связано с тем, что на каких-то уровнях иерархии он перестает показывать MenuItems, которые привязаны к этому Security Key.

[axalex]

Цитата:

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

3. Сталкивался с тем, что SK могут работать только с глубиной иерархии не больше 2-х. Подробностей не помню, но что-то было связано с тем, что на каких-то уровнях иерархии он перестает показывать MenuItems, которые привязаны к этому Security Key.

Если не ошибаюсь, то уже в 5.0 это было исправлено.

[mnt_dx]

Цитата:

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

Не нужно так делать. Встречал такие подходы.
1. Потом черт ногу сломит в этих security-ключах.
2. Фиг знает где его в дереве искать. И только один "гуру-человек" знает где все это находится.
3. Сталкивался с тем, что SK могут работать только с глубиной иерархии не больше 2-х. Подробностей не помню, но что-то было связано с тем, что на каких-то уровнях иерархии он перестает показывать MenuItems, которые привязаны к этому Security Key.

1. Назвать понятным образом. Для меня лично джоб написать сложнее. Джобы-то и контейнеры по-сложнее.
2. Куда добавим, там и смотреть, можно без указания родителя (может это влечет какие-то минусы, не знаю). В Самой кнопке он будет прописан - это и наглядно и всегда посмотреть можно наличие прав оперативно.
3. Вкладывать неглубоко

[_scorp_]

Цитата:

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

1. Назвать понятным образом. Для меня лично джоб написать сложнее. Джобы-то и контейнеры по-сложнее.
2. Куда добавим, там и смотреть, можно без указания родителя (может это влечет какие-то минусы, не знаю). В Самой кнопке он будет прописан - это и наглядно и всегда посмотреть можно наличие прав оперативно.
3. Вкладывать неглубоко

Не понимаю... Зачем изобретать какие-то велосипеды, если есть стандартный подход с 8-мью ключами на модуль? Все операции (за очень редким исключением) вписываются в эту структуру ключей.

[mnt_dx]

Если без джобов, какой ещё вариант с небольшим количеством действий?

[axalex]

На вкус и цвет товарищей нет ;-)

[someOne]

Цитата:

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

Например, по адресу /Расчеты с клиентами/Расчеты с клиентами/Сведения о клиенте - я добавил кнопку на форму, которую не желательно видеть пользователям.
Заранее спасибо.

Создавать кнопки на форме, в которых прописан какой то код - это не вполне хорошая идея. Лучше так не делать. Если вам нравится писать код в методах "clicked" кнопок, то стоит добавлять не кнопки а MenuItem --> MenuItem button ы.
Для них можно определить один из ключей безопасности соответствующего модуля, и настроить права требуемым группам пользователей штатными средствами без всяких извращений...

[Ivanhoe]

Я думаю, проблема в количестве групп возникает только при подходе настройки от максимальных прав к минимальным, т.е. у автора изначально даны права на securitykey, соответственно все новые объекты автоматом получают доступ.
Если же на сам ключ доступа нет, то и на новую кнопку нужно будет давать, а не убирать доступ.

[someOne]

Цитата:

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

Я думаю, проблема в количестве групп возникает только при подходе настройки от максимальных прав к минимальным, т.е. у автора изначально даны права на securitykey, соответственно все новые объекты автоматом получают доступ.
Если же на сам ключ доступа нет, то и на новую кнопку нужно будет давать, а не убирать доступ.

Да такой вариант возможен.
Из сообщения автора не совсем ясно это описано...
Если проблема в том, в группах пользователей открыты права на securitykey, то с этим, конечно, не просто при настройки прав на новые объекты.
Лучшим решением, ИХМО, было бы снять доступ с securitykey там где это возможно.
Обсуждалось уже ранее.