Есть доработанная большая конфигурация, подключенная к хранилищу. Несколько лет назад погромист включил возможность изменения и благополучно соскочил. Надо поставить все объекты, какие только возможно на замки.

Через "Конфигурация \ Поддержка \ Настройка поддержки \ Сравнить, объединить" это работа недели на три в поте лица. Объектов порядка 13000 штук - считайте сами надо в каждом правило поддержки заменить на "Не редактируется".

Как поставить неизмененные объекты "на замок" ничего не поломав?

(0)

Зачем ?

Вариант А
Няшно и приятно сердцу

Вариант Б
Вы собираетесь отдать базу на аутсорс и запустить туда кучу погроммистов ?
Так их ничего не остановит, даже замочки.

Вариант В
У меня кончились идеи

(0) Выгрузите конфигурацию в файлы, внесите изменения в нужные объекты и загрузите обратно.

(0) самое время и вам соскочить )))

(3) так я ещё и не наскакивал)

(0) Все доработки вынести в расширение. Загрузить конфигурацию поставщика.

(5) бедные добавленные ранее объекты и реквизиты... :(

(0) 1. создать пустую базу и в нее загрузить конфигурацию поставщика
2. снять с поддержки необходимые объекты
3. перенести доработки в эти объекты
4. в результате получаем cf, которую загружаем в рабочую

(0) 13000 / 3 рабочие недели / 8 часов = ~108 объектов час. Т.е. грубо за минуту проставить 2 галочки. Имхо, не такой уж и "пот лица".

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

Но вообще интересно было бы посмотреть на конфу, в которой 13000 объектов метаданых.

(6) Предварительно сохранить всё измененное где-то снаружи базы. Потом подгрузить уже в расширения.

(8)[Но вообще интересно было бы посмотреть на конфу, в которой 13000 объектов метаданых.]
ERP

(0) Надо поставить все объекты, какие только возможно на замки.
сравнить с базой поставщика и поставить под замки неизменённые?
"это работа недели на три в поте лица" сомнительно, но окэй.
не бесплатно же.

(7) а вот тут как повезёт.
3 недели могут превратиться в 3 месяца при неудачном раскладе.

(12) день максимум: 1. во второй базе открываем сравнение с  конфигурацией поставщика, а в чистой начинаем снимать с поддержки. 2. потом просто переносим все изменения

(13) "потом ПРОСТО переносим все изменения"
вы либо шутите, либо не понимаете, что там может быть.

(13)

>>потом просто переносим все изменения

Надо добавить "и стараемся нигде не ошибиться".
Я бы другое слово добавил, но увы.

(14) (13) Побочки от (7) такие:

1. Хранилище конфигурации, где работает отдел разработки, придется пересоздавать после такого.

2. Если поставщик (1С) удалил/добавил объекты с тем же именем, то они при обновлении конфигурации пересоздадутся и таблицы в БД перетрутся - надо будет из архивной копии переливать.

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

https://capitally.ru/wp-content/uploads/2016/10/Nastrojka-pravil-podderzhki.jpg

(16) Запишите макрос мышки, добавьте сдвиг клавиатурой на 1 строчку вниз.
3 дня работы превратится в пару часов.

(17) бывает справочная информация отличается и не всегда такое поможет

Я прошу прощения, а вариант

1) полностью снать с поддержки
2) сравнить/объединить с оригинальной типовой
3) на вопрос "поставить на поддержку" выбрать "да"
4) настройку постановки на поддерку выбрать как в (17)

отменили?
или я не понял вопрос?

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

(18) подобное делалось через AutoIT

(20) Желтые квадратики так возвращаются, но замки нет. Почему - не понятно. Короче, если считать, что на объект 5 секунд то 13000 * 5 / (3600 * 8) где-то дня 3 обезьянить.

(22) За такую работу надо брать тройную расценку (как минимум). Тогда даже тупое проставление галочек принесет удовлетворение.

(22)
>> Желтые квадратики так возвращаются, но замки нет

Я - возвращал.

Не возвращаются тогда, когда 1С не считает их идентичными. Но  это другой случай. Если отличие зависит от html кода в справочнной информации и т.п. - я дал рецепт.


----- ПРОШУ ПРОЩЕНИЯ.
решил сейчас перепроверить. Замочек не встает.
Хотя в памяти есть воспоминание, что это работало..
Может, перестало с какого-то релиза..

Поставить на поддержку текущую конфигурацию всю можно через сравнение/объединение с копией этой же самой конфигурации. Если сделать из текущей файлы для обновления. И мучиться с расстановкой галочек не придется.

(25) хм. а можно "обновить копию", а из обновленной копии - "сделать файлы для обновления" рабочей?

(26) Зачем так сложно? Хотя можно и через копию.

(24) Вы молодец, что так оформили изменение своего мнения. Очень корректно!

При обновлении базы, всё  что можно раньше возвращал к типовой. Доработки в отдельные модули. Часть дописанного разбросано, но основные алгоритмы в одном месте. 95% типовой, главное поставить режим изменения запрещены для объектов взятых из типовой.

(0) Если не получится (25), можно накатить обновление следующее, желательно через cf. В настройках правил поддержки поставить для новых и идентичных объектов "объект не редактируется".

(0) Ну так загрузи конфигурацию с замочками

(21) Чет сложновато, подойдет
JitBit Macro Recorder

(31) Побочки в (16) - чем с ними воевать проще за три дня ручками протыкать эти 13000 объектов. Три недели это я загнул. 5 секунд на объект хватает

(25) Так надо чтобы измененные без замка были с желтым кубиком. А неизмененные на замке

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

Путь в макросы тебе светит.

(34) поставь сперва замки везде, а потом сними где надо, так обычно проще и быстрее.

ОФФ.
(0) >> ... погромист включил возможность изменения...

И правильно сделал.
Вам осталось лишь проверить, что возможность изменения с сохранением поддержки включена у всех объектов и реквизитов конфигурации (бывает, что при очередном обновлении новые объекты поставщика прилетают с включенным замком, запрещающем изменения). И в дальнейшем при обновлениях следить, чтобы новые и изменяемые объекты поставщика добавлялись/изменялись в конфигурацию с флагом "Изменения разрешены с сохранением поддержки" (соответствующая диалоговая форма с вопросом выскакивает в конце процесса сравнения/объединения при обновлении).

>> Надо поставить все объекты, какие только возможно на замки.

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

Правильная тактика в ситуации подобной Вашей (когда нет необходимости тиражирования доработок).
1. У всей конфигурации включена возможность изменения с сохранением поддержки.
2. Все Ваши новые объекты, общие модули, общие макеты, общие формы, общие команды, подписки на события, а также реквизиты (измерения, ресурсы, табличные части, формы, макеты, команды и т.п.) существующих объектов добавляете прямо в основной конфе. Ибо нет совершенно никакого смысла выносить Ваш новомодный справочник или документ куда-то в расширения.
3. Все доработки и изменения существующих объектов поставщика по максимуму стараетесь делать в расширении(ях).
4. Типовые штуки типа подключаемых отчетов, обработок, печатных форм, делать в расширении(ях) по букварю для БСП. А не по старинке - через справочник внешних отчетов и обработок.

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

Никакого разумного смысла в возвращении куда-то там замочков совершенно нет. Эта совершенно бессмысленная трата времени и ресурсов, которые можно было бы потратить на более важные, ценные и действительно полезные вещи.

(37) Ну будь я хозяином я бы для себя сделал замочки на неизмененных объектах и только на них. Бесит думать на каждом шагу изменен тот или иной объект или нет🤦. Денька три-четыре на это отвести вполне можно и нужно.

(38) >> ... замочки на неизмененных объектах и только на них.

Повторюсь.
Совершенно бессмысленное действо.
Никакого профита от него нет. Вот вообще.
Зачем?... 🤷‍♂️

>> думать на каждом шагу изменен тот или иной объект или нет

Думать бесит всех. Это нормально. )))
Но в данном конкретном случае думать не нужно.
Какую задачу ты решаешь задаваясь вопросом - изменён объект или нет?
Ведь при любой доработке типовой конфигурации под требования заказчика мы обязаны выбрать наиболее оптимальное решение. Таковым является описанный мною в (37) подход. Маниакальное старание делать все доработки исключительно через расширения ведёт только к росту ошибок, проблем совместимости расширений между собой и с основной конфигурацией, сложностям проверяемости работоспособности расширений после каждого очередного обновления (что ничего не отвалилось и всё работает как задумано). По мере роста количества доработок энтропия только растёт. Причём зачастую непропорционально количеству и сложности вносимых доработок. А как только вендор (поставщик типового решения) вдруг решит значительно поменять расширяемый объект и прикладную логику его работы, восстановить все доработки от разных задач в этой новой версии объекта становится гораздо сложнее, чем если бы это было сделано внутри конфигурации, а не в расширении.

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

(0) А в чем сложность написать обработку и поправить файлы выгрузки конфигурации?
Т.е. я бы действовал так:
1) Получаем файл измененных относительно эталона (1cv8.exe config /DumpConfigToFiles C:\xml -getChanges C:\diff.txt - где по пути "C:\xml" лежит выгрузка эталонной конфигурации)
2) По сформированному файлу поправил бы не вошедшие в изменения объекты метаданных в ParentConfigurations.bin.
см. https://infostart.ru/1c/articles/1148991/ (там снятие с поддержки, но поставить можно так же изменяя соответствующие поля)

(40) Сложность не в том, чтобы написать. Нет гарантий, что эта обработка всё правильно сделает и мы все "острые углы" учтем, которые платформа наверняка обходит.

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

Dmitrii, с чем на личном опыте, столкнулись, что пришли к такому выводу?

Еще не предлагали выгрузить конфигурацию в файлы, и в одном текстовом фале поменять 0 на 1? После этого собрать конфигурацию из файлов.

(43) см (2)

(41) Не питай иллюзий. Работай с тем, что есть. Гарантии не работают вечно © ИМХО