[sukhanchik]

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

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

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

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