интексы и триггеры - нельзя

на партнерском форуме целый холивар вокруг них

Капец, как всё сложно!
Хорошо что сегодня подняли тему - не знал таких строгачей со связанными руками по модификации

Как понимаю, что если франч обнаружит несогласованную модификацию - в праве даже отозвать лицензию? (в шоке)

А я наивно думал, что снять с поддержки - это достаточно строго

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

а можете в двух словах объяснить их логику, зачем это сделано?

франч не правообладатель и не может отзывать право, которое предоставляет 1С

Я так тоже понимаю, но допускаю, что может подать представление в 1С на отзыв/аннулирование

А это уже страшно

если в 2 словах.
данное ограничение владельцы 1С не рассматривают как кнут карать и отбирать лицензии.

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

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

соответственно, изменится поведение системы.

платформа предоставляет
1) возможность создания индексов по некоторым параметрам.
2) при необходимости прямого доступа к данным сейчас есть механизм внешних источников данных. там никто не ограничивает структурой индексами и логикой.

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

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

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

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

такой подход более сложный в реализации, но более правильный с точки зрения жизнеспособности системы.
ответственный сотрудник, который помнит про все скрипты
1) может уволиться/уйти в отпуск/декрет
2) может просто забыть про него.
в итоге это в один момент может "выстрелить" а новый специалист будет не в курсе происходящего.

в целом вы правы, но в то же время искусственные ограничения тоже не есть хорошо, просто у нас мания все запрещать.

Запрет это позиция 1с.
Я её только транслирую.

это понятно.