Конфигуратор: сохраняет также то, что наконфигурил программи

[vo]

Конфигуратор не делает различий, изменена ли конфигурация прикладным кодом или пользователем при ручном конфигурировании. Из-за этого очень часто возникают всякие неприятные ситуации: такие как:
- потеря функциональности,
- снятие протекта с полей, которые нельзя редактировать, что чревато случайной порчей данных.

Пример 1.
Статус-строка для дерева L_KATORG::IBANKS.TRKATB определяется с учетом настройки "Настройки Галактики \ Общие настройки системы \ Доступ к таблицам \ Запретить модификацию \\ Каталога банков":
- если настройка установлена в "нет", то статус-строка не изменяется, остается такой, как была задана для данного дерева при его описании.
- если настройка установлена в "да", то статус-строка меняется программно на другую.

Если отконфигурировать дерево L_KATORG::IBANKS.TRKATB со значением указанной настройки "нет", то получится конфигурационный файл, который не содержит информации об изменившейся статус-строке. Впоследствии при использовании данного конфигурационного файла все будет работать, как и задумывал программист, т.к. статус-строки для разных вариантов значений данной настройки будут разными.

Если отконфигурировать дерево L_KATORG::IBANKS.TRKATB со значением указанной настройки "да", то получится конфигурационный файл, в котором отражено, что пользователь изменил конфигуратором статус-строку для данного дерева (но я это не конфигурил!). Впоследствии функциональность программы будет работать неверно: в режиме для значения настройки "нет" изначальная конфигурация окна будет перекрываться конфигуратором, и не будет видна изначальная статус-строка. В режиме "да" статус строка будет такой, как планировал программист.

Пример 2.
Список M_TRANSP::KAR_WPS.BRTRANSP - после конфигурирования поле "Гос.номер" становится доступно на редактирование,
хотя никто этого не делал при ручном конфигурировании!

object 'c_BRTRANSP_TRANSP.NOMER_Гос._номер' : Column {
Protect = False;
} // c_BRTRANSP_TRANSP.NOMER_Гос._номер : Column
В данном случае возникает опасность случайной порчи данных!

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

НЕОБХОДИМО грамотное решение данной ситуации. Возможно, нужно делать отличия, какие свойства изменены пользователем, а какие программистом, причем в конфигурацию сохранять только пользовательские изменения. Возможны другие варианты решения проблемы...

У кого какие предложения? Кто еще сталкивался? Как боретесь? Что предложить Атлантистам?

[cruger]

Это известная особенность. Есть ещё одна, на которую часто жалуются: прикладные манипуляции с API конфигуратора перебивают пользовательские.
Теоретически это можно обходить, вручную редактируя скрипт, выкидывая оттуда то, что не менялось. Или же комбинируя конфигурирование и докомпилирование.
Практически же вряд ли кто-то так делает.

[vo]

Т.е. Вы предлагаете решать данную проблему путем набивания шишек, поскольку, как я уже пояснил, пользователь не знает, какие именно интерфейсы конфигурируются программистом. А узнает он об этом, когда столкнется с одной из указанных в первом посте проблем. И тогда уже придется каждый раз следить за скриптами cnf и методично вырезать нежелательные изменения конфигурируемых интерфейсов. Не очень продуктивный путь.

Как насчет того, чтобы отличать конфигурацию сделанную пользователем и программистом, и сохранять в crf, cnf только пользовательские изменения.
Также было бы полезно разобраться с приоритетами пользовательской конфигурации и конфигурации, сделанной программистом.

[vo]

Любопытно что данная проблема была выявлена самим разработчиком еще в 21/05/2001 19:05 в ПИР 101.13645 и за столько времени ничего не делалось по этому вопросу. Неужели больше никто не сталкивался с этой проблемой и всех устраивает "как есть"?

[cruger]

Не каждый раз, а один раз на скрипт.
"Почему бы не" - хороший вопрос. Таких только в ПиРе 900 штук висит.
Да и не каждая проблема - проблема. Конкретно это я бы назвал особенностью.

[vo]

Это очевидно проблема, и я описал, почему это проблема, причем даже критичная, т.к. есть вероятность случайной порчи данных.
Править скрипт по всей видимости нужно каждый раз после нового его сохранения, а это делается каждый раз при установке патчей, т.к. за это время могли что-то доконфигурить. А установка патчей - не такая уж редкость.

Но далее, видимо, нет смысла обсуждать, как ее классифицировать: как проблему или как особенность, т.к. решать ее никто пока не собирается.