права на MorphX

[_AxDevel_]

Dynamics AX 4.0
Вопрос такой, возможно ли настроить права так, чтобы у пользователя был доступ к объектам AOT только на чтение, доступ к коду через MorphX только на просмотр? Посмотрел настройки прав: либо нет доступа, либо полный доступ.

[raz]

В DAX3 можно было, в следующих версиях поломали, как и многое другое.

[pitersky]

А в чём бизнес-логика ограниченных прав на АОТ?

[raz]

Бизнес логики никакой, но для "разбора полетов", то бишь отладки на рабочем приложении автором модификации, без возможности внесения изменений в код, самое оно.

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

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

[_AxDevel_]

Цитата:

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

Бизнес логики никакой, но для "разбора полетов", то бишь отладки на рабочем приложении автором модификации, без возможности внесения изменений в код, самое оно.

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

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

Абсолютно так я и думаю. С этой целью и спрашиваю. Восстанавливать из бэкапа базку, то будет очень долго. Значит, никак в 4-ке?

[raz]

Цитата:

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

Абсолютно так я и думаю. С этой целью и спрашиваю. Восстанавливать из бэкапа базку, то будет очень долго. Значит, никак в 4-ке?

Ну только давать полный доступ к приложению.

[pitersky]

Цитата:

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

Бизнес логики никакой, но для "разбора полетов", то бишь отладки на рабочем приложении автором модификации, без возможности внесения изменений в код, самое оно.

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

я не совсем понял, какую роль в этом играет запрет на редактирование объекта АОТ. Что меняет наличие у разработчика полного доступа? или вы боитесь, что исправление будет сделано только на рабочем приложении?

[raz]

Дело не в страхе, а в политике компании, когда приезжает внутренний аудит из-за бугра и придирается ко всему. Последний раз говорили, что в SAP есть какой то триггер, который запрещает изменение приложения и есть целая процедура что бы разрешить изменения, почему в Axapta не так. Короче хлопот много.

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

[Wamr]

есть 2 лицензии
Среда разработки
Исходный код

если одну из них убрать, то код будет доступен, а вот его изменения не сохранятся
(не помню только какую)


а для 5ки можно контроль кода включить и всем запретить его менять

[AlGol]

Цитата:

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

есть 2 лицензии
Исходный код

если ...убрать, то код будет доступен, а вот его изменения не сохранятся

PHP код:

Функции, которыми позволяет пользоваться ключ доступа разработки X++
-------------
Затрагиваемые области    
Контроль доступа ко всем классам в Axapta и код разработки для уровня CUS. Доступ к уровню CUS означает, что объекты на уровнях CUS и USR могут быть изменены. Ключ также управляет инструментом профилировщика кодов и доступом к системе управления версиями. 


Он будет действовать только на классы.

[oip]

Цитата:

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

Он будет действовать только на классы.

И только на непосредственное изменение кода в системе. Импортом проекта поменять можно будет что угодно.

В общем, административные проблемы в данном случае лучше решать не техническими, а административными средствами средствами.