Дать пользователю доступ только на чтение

[IKA]

У нас много компаний(и доменов). Есть пользователь, которому нужен доступ только на чтение к любой информации во всех компаниях. Те просматривать любую(!) информацию он может, менять - нет.
Самое простое -создать для него свою группу, потом пойти в домен Admin и на всех ключах дать доступ View.
Корректно ли это ?

[sukhanchik]

Теоретически корректно. Собственно говоря - так и надо делать ... И для тех таблиц, к которым пользователь получит доступ через поля формы - так все и будет работать.
Грабли наступят там, где существуют пункты меню / кнопки на форме, которые данные меняют (как пример - периодические операции). При соблюдении Best Practice на соответствующих пунктах меню (а я надеюсь, что нет кнопок типа Button, а есть только кнопки типа MenuItemButton) необходимо свойство NeedAccessLevel устанавливать в значение, соответствующее действию периодической операции по отношению к данным. Если периодическая операция пересоздает записи - то Delete, если добавляет записи - то Add, если только правит - то Edit. Если данные не меняются (актуально для отчетов) - то можно оставить значение View по умолчанию.

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

Также хочу отметить, что еще могут возникнуть ситуации, когда доступ на ключи придется давать по-любому - т.к. в структуре самого меню они прописаны (касается подотчетных лиц, русских ОСов, CRM и т.д.)

[IKA]

Спасибо огромное, успокоили.
Вы обычно права даете на ключи или меню? У нас они обычно даны на меню, чтобы более детально контроливать доступ, но в данном случае воспользоваться правами на ключи мне показалось разумнее.

[sukhanchik]

Обычно ключи я сторонник запрещать, дабы добавление новой функциональности не давало автоматически на нее прав. Исключение составляют таблицы, которые часто просто необходимо делать доступными, чтобы корректно отрабатывал код и RLS. Поскольку согласно Best Practice каждый ключ ответственен за свой раздел меню (имеется в виду - что свой ключ на запросы, свой ключ на настройки и т.п.), плюс еще есть родительский ключ, ключ на таблицы и ключ на все остальные пункты меню - то настройка прав на типовые модули (типа Расчеты с клиентами) может быть сделана следующим образом:

На корневой ключ (Cust), ключ к корню меню (CustDaily) и ключи к остальным разделам меню (CustPeriodic, CustSetup и т.д.) доступ запретить. Также запретить доступ к ключу с дополнительными пунктами меню (CustMisc). А вот ключ на таблицы (CustTables) разрешить на просмотр и, при необходимости, отдельные таблицы разрешить на полный доступ. Права на все пункты меню настравать - индивидуально в соответствии с ролью.

Но это все зависит от количества пользователей, работающих в АХ. Чем меньше пользователей, тем больше совмещены обязанности - тем более широко пользователи могут пользоваться системой => тем более удобнее по умолчанию разрешать доступ (т.е. давать доступ на ключи), а индивидуально уже убирать. Но при этом всегда нужно помнить - что давая доступ на ключ - автоматически дается доступ на тот новый пункт меню / таблицу, который (ая) ему будет подчинен (а) в будущем.

Для целей настройки "только читающего" пользователя конечно можно включить все ключи на просмотр. Но ... обычно даже "только читающий" пользователь имеет свою роль и не желает видеть ничего лишнего в интерфейсе (а значит опять все упирается в тонкую настройку прав). Новых же пользователей, которые еще не допущены к работе в системе, но которые уже должны с ней знакомиться имеет смысл пускать в копию рабочей базы с реальными их правами (опять-таки - настроенными на кусок функционала, а не на всю АХ целиком).