права на кнопку

[IKA]

Добавлена кнопка(именно button), на стандартной форме . К кнопке привязан ключ LedgerMisc и к MenuItemу, вызывающему форму, тоже. Можно ли как-нибудь сделать так, чтобы по умолчанию доступа к кнопке не было у юзеров, даже если есть все права на ключ LedgerMisc. То есть чтобы кнопка была доступка если только дали явно доступ к кнопке через Настройку прав доступа.
Я пока вижу либо создание нового ключа и повесить его на эту кнопку (но мы стараемся не создавать новых ключей , тем более ради одной кнопки), либо кодить - искать по пользователю, даны ли ему права на кнопку.
Есть альтернативные варианты? Может, стоит создать отдельную группу пользователей и запихнуть ее в настройки и проверять пользователей на принадлежность ей? Чем такой вариант лучше, чем создание ключа отдельного.

[Ivanhoe]

Почему кнопка (именно button), а не menuitem?

Все зависит от подхода настройки прав доступа. Я предпочитаю всё отключать, и только нужное разрешать. Поэтому, как правило, на самих ключах доступа прав не бывает.

[IKA]

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

[sukhanchik]

Цитата:

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

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

Именно это как раз и играет роль. Сделайте MenuItemButton и будет счастье. С ключом - не заморачивайтесь - считайте - что ключи нужны исключительно для группировки объектов, на которые дается доступ. Я конечно утрирую и, безусловно, можно и нужно менять доступ на ключах у ряда пользователей. Но в данном случае (при выборе между button и menuitembutton) представьте себе - что на ключах доступ менять нельзя.

[IKA]

Цитата:

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

Именно это как раз и играет роль. Сделайте MenuItemButton и будет счастье. С ключом - не заморачивайтесь - считайте - что ключи нужны исключительно для группировки объектов, на которые дается доступ. Я конечно утрирую и, безусловно, можно и нужно менять доступ на ключах у ряда пользователей. Но в данном случае (при выборе между button и menuitembutton) представьте себе - что на ключах доступ менять нельзя.

Какую роль играет menuItemButton или это Button? Вы имеете ввиду, что права на menuitembutton непосредствеено в дереве Main menu можно настроть, а с кнопками - только через security key view? Проблема, что у нас много доменов и много групп пользователей, поэтому хотелось бы что-нить придумать, чтобы не перенастраивать права везде, а просто сделать для всех, кроме некоторых пользотетелей, эти кнопки недоступными.

[sukhanchik]

Цитата:

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

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

Так воспользуйтесь уже данным советом.

Цитата:

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

Посмотреть/изменить права для конкретного объекта возможно (с ньюансами) с помощью формы от Raven Melancholic: установка прав

Делаете MenuItemButton и для этой кнопки с помощью вышеуказанной формы настраиваете права только тем кому нужно. Сразу по доменам и группам пользователей.
Кстати - если у Вас количество групп пользователей сопоставимо с количеством пользователей или превышает их - то разумнее каждому пользователю сопоставить свою индивидуальную группу. Упростите себе работу по настройке прав.

[vallys]

Цитата:

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

Добавлена кнопка(именно button), на стандартной форме . К кнопке привязан ключ LedgerMisc и к MenuItemу, вызывающему форму, тоже. Можно ли как-нибудь сделать так, чтобы по умолчанию доступа к кнопке не было у юзеров, даже если есть все права на ключ LedgerMisc.

Сталкивались с аналогичной задачкой. Но не просто для кнопок, а для более общего случая – для таблиц, полей, пунктов меню и т.д. Ситуация была аналогичная – при создании нового элемента в репозитарии (например кнопки), к нему автоматически имели доступ (соответствующего уровня) все пользователи, которые имели доступ к ключу доступа, который был прописан для этого элемента. Происходит так, потому что в аксапте (при проверке прав) используется принцип: все что не запрещено - разрешено. Поэтому, если для пункта меню (кнопки, таблицы, ...) явно не прописать запрет доступа, то он будет доступным всем пользователям, у кого есть соответствующие права на ключ безопасности, указанный для пункта меню; если ключ безопасности не указан – всем пользователям. У себя мы решили задачу следующим образом: при импорте проектов автоматически закрывается доступ ко всем «новым» элементам репозитария (определенных типов). Также добавили пункт контекстного меню «убрать доступ» для объектов, которые создаются руками, если возникает такая необходимость.

Посмотреть/изменить права для конкретного объекта возможно (с ньюансами) с помощью формы от Raven Melancholic: установка прав

Права лежат в таблицах AccessRightsList, SysSecurityFormTable, SysSecurityFormControlTable. Работа с AccessRightsList через классы, как указано в примере тут или напрямую. С SysSecurityFormTable, SysSecurityFormControlTable - через класс SysSecurityFormSetup.

P.S. SysSecurityFormTable + SysSecurityFormControlTable - права для контролов форм. AccessRightsList - для всего остального.

[sukhanchik]

Цитата:

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

Происходит так, потому что в аксапте (при проверке прав) используется принцип: все что не запрещено - разрешено.

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

[vallys]

Цитата:

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

Не совсем так. Все разрешения наследуются от ключа, к которому относится данный элемент. Поэтому при добавлении нового пункта меню доступ на него наследуется от ключа, к которому настроен доступ. Т.е. если доступа не было - он и не появится. Если был - появится.

Да, конечно. Видимо я не совсем понятно высказался. "Не запрещено" - не только для элемента, а в целом в соответствии с политикой проверки прав Аксаптой (см. рис., источник: Microsoft TechNet - Manage security permissions for user groups and domain combinations)

Цитата:

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

Но наследование можно разорвать, изменив уровень доступа вручную. В этом случае в таблице AccessRightsList создастся запись, относящаяся к данному элементу. В этом случае изменение доступа к ключу не повлияет на уровень доступа к элементу (пункту меню, таблице).

Да. Именно потому что для новых объектов нет записей в AccessRightsList - для них используются права соответсвующего ключа доступа, если таковые имеются.

[Ivanhoe]

Эх, как часто приходится встречаться с таким подходом: сделали изначально неверно (по незнанию, ошибке или еще почему), а потому всеми силами держаться за это решение, плодя проблемы и ошибки, ставя костыли.

По прошествии времени, уже поработав в системе, думаю, знаете все свои проблемы по настройке прав доступа и указанная задача - вряд ли последняя по этой теме.

Мой совет: признайте проблему, найдите ресурсы и сделайте настройку прав доступа по-нормальному. Тем более что это намного проще, чем делать реинжиниринг процессов или перевнедрение. Разработайте правила выделения групп и их настройки, привидите доработки к стандартному виду - настройка прав доступа ТОЛЬКО через меню-айтемы. Не давайте, по возможности, права на сами ключи - только на объекты, к ним привязанные. Введите регламенты настройки - кто и на основании каких документов вносит изменения в права / назначает права пользователям, как выполняются доработки (с учетом назначения прав), в каких документах описаны правила управления доступом и т.п.