|
24.11.2008, 10:52 | #1 |
Участник
|
Права доступа к закладке "Пакет"
Вопрос такой - можно-ли настройками прав доступа ограничить видимость закладки "Пакет" ? Или допиливать функционал придется?
В настройках прав есть такой параметр - "Пакет", но он действует только на КНОПКУ "Пакет". Больше ничего не нашел. |
|
24.11.2008, 11:07 | #2 |
Member
|
А смысл такого ограничения в чем? У вас 3.0?
Можно ограничить список пакетных групп RLS-ом, если речь идет о загрузке серверов. Если штатными средствами.
__________________
С уважением, glibs® |
|
24.11.2008, 11:21 | #3 |
Участник
|
Смысл в том, что простые операторы по ошибке часто нажимают пакет, а потом криков - что ничего не работает, не обрабатывается. Хочется по максимуму уменьшить влияние человеческого фактора на рабочий процесс.
|
|
24.11.2008, 12:03 | #4 |
Участник
|
Может тогда проще добавить проверку ключа доступа в RunBaseBatch.canGoBatch() и RunBaseBatch.canGoBatchJournal()
|
|
24.11.2008, 12:24 | #5 |
Member
|
Вообще. Пакетную обработку можно сравнить с интерфейсной возможностью. Такой, как копирование, вставка, перетаскивание колонок в гриде. Т.е. это полезная для пользователей возможность, которую вы хотите зарезать.
В частности. Если решать вашу задачу в лоб, то придется программировать. Если бы я столкнулся с такой проблемой, то я бы сделал все возможное, чтобы решить ее цивилизованно. Например, запрос подтверждения отправки на пакетную обработку. Предположим, в виде окна с длинным текстом на несколько абзацев о том, что такое пакетная обработка и каковы будут последствия.
__________________
С уважением, glibs® |
|
24.11.2008, 13:01 | #6 |
Участник
|
Однако, не нужно забывать, что модернизация системы делается совсем не для для того, чтобы принести максимум "пользы" пользователям.
|
|
24.11.2008, 12:46 | #7 |
Участник
|
Пользователь - пользователю рознь. Есть нормальные, а есть те, которым чем меньше возможностей, тем лучше для работы.
В общем понятно - придется где-то напильником поработать! |
|
24.11.2008, 13:28 | #8 |
Member
|
egorych, в общем случае мое мнение по данной проблеме такое. За ERP системы не целесообразно сажать пользователей... у которых безответственное отношение к учету или отсутствует интеллект. Это должно решаться на уровне дизайна. Не сажают же обезьян управлять авиалайнерами, атомными реакторами или операции делать в больнице. С частными случаями я сталкивался, конечно. Стремлюсь сводить их к общему.
coolibin, а для чего делается модификация системы?
__________________
С уважением, glibs® |
|
24.11.2008, 14:36 | #9 |
Участник
|
Это идеальный случай. К сожалению реальность такова, что оператор с высшем образованием (читай думающий и понимающий) или не встречается или быстро передвигается по службе. А делать для одних один интерфейс ввода, а для других - другой ИМХО не самое лучшее решение.
|
|
24.11.2008, 17:51 | #10 |
Участник
|
Цитата:
Вы знаете, западные корпорации получили неплохие доходы, когда догодались согнать с множества деревень и поставить за свои станки "безграмотных" (не в обиду им) китайских крестьян, которые даже среднюю школу не заканчивали, научили их элементарным операциям и при этом выпускают неплохую продукцию, которой мы с вами пользуемся. Я думаю, когда они научатся эксплуатировать обезьян или, например, попугаев, это будет большой прорыв в технологии (если только зеленые им эту лавочку не прикроют). Странный вопрос. В смысле от Вас. Не, ну конечно разные допущения бывают, и Вы об этом, должно быть, знаете, но я так думал, что в общем случае, деньги на систему тратятся (ведь тратить их нужно не только на покупку, но и на перманентную модификацию), чтобы владелец предприятия получил еще больше денег. Пользователи сюда укладываются ооочень косвенно. Теперь хотелось бы услышать Ваш вариант. ))) |
|
24.11.2008, 16:43 | #11 |
Участник
|
Я бы лично сделал ключ на вкладку "Пакет". Согласен, что пользователи бывают очень разные.
И если уж есть способы ограничить другие "интерфейсные возможности" (например, расширенная настройка форм по конфиг. ключу, кнопка "Переименовать" в паспорте записи по security key и т.п.), то это аналогично стандартному подходу DAX.
__________________
Ivanhoe as is.. |
|