Как не дать экспортировать разработку из Аксапта 2.5?

[Pavlo AKA Panok]

Добрый день!

Ситуация: необходимо дать доступ к разработке в системе, но каким то образом ОТКЛЮЧИТЬ ВОЗМОЖНОСТЬ ИМПОРТИРОВАНИЯ приложения из системы. Плюс возник еще один косвенный вопрос - как закрыть доступ программиста к списку функциональных ключей?

Большое спасибо!

[AY]

1. Открываешь AOT\Data Dictionary\Feature Keys и создаешь новый ф.к., например, AOT_Export с измененными свойствами:

Label - например, @SYS14973 (Экспорт)
ANDParents - Yes

2. Добавляешь в этом ФК Parent Feature Key AOT_Development

3. При сохранении запустится синхронизация!!!

4. Открываешь форму AOT\Forms\SysExportDialog и, допустим, на кнопку Button:Export вешаешь ФК AOT_Export

5. Настраиваешь права доступа для группы таких разработчиков, отключая прямой и косвенный доступ к:
функциям :
Администрирование\Контроль доступа
Разработка\Разблокировка элементов AOT
Разработка\Экспорт
пунктам меню:
Администрирование\Функциональные ключи\Настройка ФК

(если ветка Разработка\Экспорт не видна, обновляешь сессию)

6. Блокируешь форму SysExportDialog под админом, чтобы новых кнопок не понаделали (насколько я помню, родительское меню - в системных элементах, поэтому подменить вызов формы они не смогут без хакерства). Правда, в этом случае они не смогут снимать блокировку элементов вовсе, но это иногда и к лучшему, например, при программировании на скорость)))

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

8. Разработчики перегружают сессию и теперь они не смогут менять в элементах фк, настраивать фк и настраивать себе доступ.

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

Но самое главное, Вы уверены, что они не могут просто скопировать папку Appl?))))

С уважением,
AY

[mazzy]

Если у пользователя есть права на средства разработки, то в практических случаях он может утащить из АОТа практически все что угодно.

Да, можно делать защиту от дурака, как написал AY.
Да, можно давать разные права на разные объекты разным разработчикам. (Одному - редактировать только отчеты, другому только формы). Посмотрите к контроль доступа, раздел разработка.

Но я не представляю разработчика, который не имеет доступа к браузеру таблиц и к Enterprise Manager'у. А там можно править все что угодно.

Да, вы можете ограничить доступ к ключевым таблицам и для браузера и поиграться правами в EM... Но все это очень геморно. И скорее всего, дыры останутся. Скорее всего, вы получите только иллюзию безопасности. Кроме того, скорее всего, ваши разработчики будут саботировать работы и обосновывать все свои промахи тем, что у них "не было доступа".

Стоит ли ваш проект ТАКИХ затрат на безопасность? На мой вглял, дешевле и эффективнее работать с людьми.

[Garic]

Абсолютно согласен с mazzy.
При желании разработчик всё равно сможет утащить всё что нужно - достаточно обнулить пароль Admin-a и зайти под ним. Запретить использование отдельных функций вы не сможете.

[AY]

Я тоже согласен с mazzy,
"И построили ему Барма и Постник храм зело великий, и приказал он ослепить их")))

[Pavel]

Цитата:

Изначально опубликовано Pavlo AKA Panok
Ситуация: необходимо дать доступ к разработке в системе, но каким то образом ОТКЛЮЧИТЬ ВОЗМОЖНОСТЬ ИМПОРТИРОВАНИЯ приложения из системы. Плюс возник еще один косвенный вопрос - как закрыть доступ программиста к списку функциональных ключей?

Пойдите "обратным" путем. Пускай пользователь трудится в своей локальной версии (без ограничения прав) и затем выгружает и передает свои разработки. Ответственный будет собирать все доработки в рабочий прототип системы, тестировать версию и принимать решение о начале эксплуатации новой функциональности.