Снять с поддержки только один объект конфигурации
Платформа (8.3.13.1865), Бухгалтерия 3.0. Для того, чтобы для одного выборочного объекта конфигурации включить "возможность редактирования с сохранением поддержки", нужно сначала конфигурацию (корень конфы) поставить, как "Объект поставщика не редактируется" (см. вложения). Сохранить. А после появляется уже появляется опция для определенного объекта (например, документа) применить "возможность редактирования с сохранением поддержки".
Вопрос: Подскажите, пожалуйста, зачем там было сделано?
Вопрос: Подскажите, пожалуйста, зачем там было сделано?
Прикрепленные файлы:

По теме из базы знаний
- Выгрузка-загрузка любых данных из 1С (и измененных) в XML между похожими конфигурациями (ФАЙЛ, HTTP, COM) ЛЮБЫХ баз 1С 8.1-8.3 с обработкой и поиском данных по произвольным полям поиска
- Обновление изменённой типовой конфигурации 1С 8.2/8.3
- Эволюция расширения конфигурации
- Отдай корень! Библиотека OneScript для получения информации о захваченных объектах в хранилище
- Расширения конфигурации: добавляем функционал без нервов
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Нет, я конфу не трогал. Это типовая конфа, ее никто не редачил.
Раньше было так: зашел в поддержку, выбрал объект, установил для него правило "возможность редактирования с сохранением поддержки" и дорабатываешь его под нужды заказчика.
Сейчас же: нужно сначала конфигурацию (корень конфы) поставить, как "Объект поставщика не редактируется", потом, после сохранения, появляется возможность для выбранного объекта установить режим "возможность редактирования с сохранением поддержки"
Вот мне и интересно, зачем так было сделано
Раньше было так: зашел в поддержку, выбрал объект, установил для него правило "возможность редактирования с сохранением поддержки" и дорабатываешь его под нужды заказчика.
Сейчас же: нужно сначала конфигурацию (корень конфы) поставить, как "Объект поставщика не редактируется", потом, после сохранения, появляется возможность для выбранного объекта установить режим "возможность редактирования с сохранением поддержки"
Вот мне и интересно, зачем так было сделано
(2)Не путайте. Снятие конфигурации с поддержки - полный отказ от обновления типовыми конфигурациями поставщика. Возможность изменения конфигурации - это не снятие с поддержки.
2ТС: Это повышенная гибкость для возможности внесения изменений в типовые объекты конфигурации.
Если объект не редактируется вообще, то на него можно не отвлекаться при обновлении типовой конфигурации.
2ТС: Это повышенная гибкость для возможности внесения изменений в типовые объекты конфигурации.
Если объект не редактируется вообще, то на него можно не отвлекаться при обновлении типовой конфигурации.
(7)Хозяин-барин. Говорю за себя. У меня была на поддержке бух3, пару реквизитов, один рег. сведений, парочку правок типовой логики. Всё вроде бы по мизерному, но каждое обновление - это головная боль. Болело до тех пор пока не пришло критическое обновление, с очень важными правками, которые я сводил во едино два дня и в конце второго дня меня всё достало и все изменения в конфигурация я вынес в расширение, вернул её к конфигурации поставщика и обновился штатным методом. Работает это уже больше года, после меня два кодера уже там копались, и проблем с этим нет.
А по поводу удалить-слетит, ну я не знаю даже. У меня был серверный вариант и при переносе рег. сведений в расширение я думал, что мне его придётся заново перезаполнять, ан нет, на удивление все данные подтянулись самостоятельно, 1с увидила таблицу в скуле и новую создавать не стала.
И зачем расширение-то удалять? Я так же могу и реквизит удалить из основной базы и получить по логике тот же эффект. Конечно сейчас доступ к работе с расширениями вывели в предприятие, но зачем доступ туда давать пользователям? Не вижу тут проблемы.
А по поводу удалить-слетит, ну я не знаю даже. У меня был серверный вариант и при переносе рег. сведений в расширение я думал, что мне его придётся заново перезаполнять, ан нет, на удивление все данные подтянулись самостоятельно, 1с увидила таблицу в скуле и новую создавать не стала.
И зачем расширение-то удалять? Я так же могу и реквизит удалить из основной базы и получить по логике тот же эффект. Конечно сейчас доступ к работе с расширениями вывели в предприятие, но зачем доступ туда давать пользователям? Не вижу тут проблемы.
(18) Это был 2019, мы обновляли как могли. За давностью я уже и не вспомню точно, но проблемы были в том, что обновление накатывалось не полностью, не все модули обновлялись, точной причины не помню. Нынче сталкивался, что обновление через хранилище не охватило все обновленные модули, но тут причина в другом, тогда я хранилище в той фирме не использовал.
Когда изменения не документируются, то приходится перепроверять всё.
Я год назад сменил работу и встретил новую кухню, куча изменений в основной конфе и куча расширений разной направленности, которые изменяют типовую логику. Ух первые обновления, что я накатывал, были адом, одно обновление - неделя перепроверки каждого модуля, формы, реквизитов и не обошлось без эксцессов. В планах вида характеристик был добавлен новый тип и при обновлении я, не зная об этом изменении, в пылу лютой спешки перед сдачей отчетности за полгода, вместо необходимой недели, накинул два обновления за рабочий день, что по итогу затёрло этот тип и занулило проводки. Обнаружилось это через месяц, когда по этому счёту с этим субконто началась инвентаризация, пришлось разворачивать бэкап и рисовать обмен между базами, чтобы перекачать данные по затертым проводкам. Плюс от этой ошибки тоже был, оказалось, что до меня по крайней мере дважды прогеры так же удачно обновляли, что я по итогу с помощью старых бэкапов восстановил почти полностью.
Вот так вот, добавленные пару реквизитов могут вызвать проблемы там, где по идее не должно.
Сейчас я всё по максимуму выправил, где можно, вывел в расширения, а где нельзя - задокументировал. И теперь всё упирается в скорость сравнения при накатывании обновления, что может занимать целый рабочий день. Сама же правка/корректировка заимствованных модулей в расширениях и изменений в основной занимает считанные минуты, а далее это тестируется, и по итогу, если всё ок, то выкладывается на обновление.
Когда изменения не документируются, то приходится перепроверять всё.
Я год назад сменил работу и встретил новую кухню, куча изменений в основной конфе и куча расширений разной направленности, которые изменяют типовую логику. Ух первые обновления, что я накатывал, были адом, одно обновление - неделя перепроверки каждого модуля, формы, реквизитов и не обошлось без эксцессов. В планах вида характеристик был добавлен новый тип и при обновлении я, не зная об этом изменении, в пылу лютой спешки перед сдачей отчетности за полгода, вместо необходимой недели, накинул два обновления за рабочий день, что по итогу затёрло этот тип и занулило проводки. Обнаружилось это через месяц, когда по этому счёту с этим субконто началась инвентаризация, пришлось разворачивать бэкап и рисовать обмен между базами, чтобы перекачать данные по затертым проводкам. Плюс от этой ошибки тоже был, оказалось, что до меня по крайней мере дважды прогеры так же удачно обновляли, что я по итогу с помощью старых бэкапов восстановил почти полностью.
Вот так вот, добавленные пару реквизитов могут вызвать проблемы там, где по идее не должно.
Сейчас я всё по максимуму выправил, где можно, вывел в расширения, а где нельзя - задокументировал. И теперь всё упирается в скорость сравнения при накатывании обновления, что может занимать целый рабочий день. Сама же правка/корректировка заимствованных модулей в расширениях и изменений в основной занимает считанные минуты, а далее это тестируется, и по итогу, если всё ок, то выкладывается на обновление.
(19) тема просто всплыла внезапно, я написал потом дату глянул) Про добавленный тип это да, тоже об это сталкивался (только в регистре накопления), мб действительно его лучше в расширении делать. Но если добавлять новые реквизиты или документы то они остаются на месте всегда( по крайней мере у меня всегда оставались)
(20) Я стараюсь вносить новые объекты в основную базу, если же новый объект затрагивает типовой механизм, то его я добавляю уже в расширении. В таком случае я буду спокоен, что изменённые мною типовые объекты останутся и не затрутся обновлением, а изменённая типовая логика, вылезет обязательно в ошибку, если она стала несовместима с текущим обновлением, но при этом работать пользователь сможет без проблем.
При обновлении, если и удаляются объекты метаданных, то только те, что указаны как удалённые в самом обновлении (речь о накатывании типового обновления само собой). Но, когда вы добавляете новый реквизит в типовой справочник, то этот реквизит надо как-то отобразить пользователю, а значит лезть и редактировать форму, что лучше сделать уже в расширении, и как показала практика, лучше это сделать кодом, а не в самой форме. Ехал на лыжах, когда платформа падала, когда типовая форма изменилась, а в расширении это не подтянули. И так же сталкивался, когда количество изменений было настолько велико, что отследить их становится большой проблемой. Один программист добавил один реквизит на форму, второй убрал, третий изменил видимость, четвёртый доступность и ты пятый, которому просто надо накатить обновление и сидишь и не понимаешь, а это всё наши правки или 1С в старых версиях их имела, так себе такие расширения поддерживать после этого, поэтому приходилось переписывать.
По поводу вот новых документов, например, в основной базе ли их вносить или в расширении, то тут я уже начинаю сомневаться. На заре расширений считалось, что быстрее 1С будет работать с основной конфигурацией, мол кэш там строится, да и типы данных не все можно добавить, создаёшь документ, например, а реквизитом не может поставить опеределяемый. Теперь же расширения уже весьма так недурно основную конфигурацию подстраховывают, я уже сейчас начал грешить создавать новые регистры сведений в расширении, но всё же есть ещё вопросы по отладке такого решения. Да и на инфостарте уже куча разных рода доработок с новыми объектами на расширениях. У меня самого есть парочку доработок с новыми объектами, которые бы выложить, но у меня часть в основной базе, часть в расширении, надо переписывать в отдельное расширение для этого - лень, а вот если бы всё было в расширении первоначально, то было бы проще.
При обновлении, если и удаляются объекты метаданных, то только те, что указаны как удалённые в самом обновлении (речь о накатывании типового обновления само собой). Но, когда вы добавляете новый реквизит в типовой справочник, то этот реквизит надо как-то отобразить пользователю, а значит лезть и редактировать форму, что лучше сделать уже в расширении, и как показала практика, лучше это сделать кодом, а не в самой форме. Ехал на лыжах, когда платформа падала, когда типовая форма изменилась, а в расширении это не подтянули. И так же сталкивался, когда количество изменений было настолько велико, что отследить их становится большой проблемой. Один программист добавил один реквизит на форму, второй убрал, третий изменил видимость, четвёртый доступность и ты пятый, которому просто надо накатить обновление и сидишь и не понимаешь, а это всё наши правки или 1С в старых версиях их имела, так себе такие расширения поддерживать после этого, поэтому приходилось переписывать.
По поводу вот новых документов, например, в основной базе ли их вносить или в расширении, то тут я уже начинаю сомневаться. На заре расширений считалось, что быстрее 1С будет работать с основной конфигурацией, мол кэш там строится, да и типы данных не все можно добавить, создаёшь документ, например, а реквизитом не может поставить опеределяемый. Теперь же расширения уже весьма так недурно основную конфигурацию подстраховывают, я уже сейчас начал грешить создавать новые регистры сведений в расширении, но всё же есть ещё вопросы по отладке такого решения. Да и на инфостарте уже куча разных рода доработок с новыми объектами на расширениях. У меня самого есть парочку доработок с новыми объектами, которые бы выложить, но у меня часть в основной базе, часть в расширении, надо переписывать в отдельное расширение для этого - лень, а вот если бы всё было в расширении первоначально, то было бы проще.
(12) Если вы не мучались, то ещё не значит, что расширения безобидны. Вот, например:
В любом случае, расширение тоже надо обновлять, если оно касается каких-то изменений, которые внёс поставщик.
А если не касается, то и в самой непосредственно конфигурации он не вызовет никаких сложностей. При обновлении снимаете галочку где надо и всё.

В любом случае, расширение тоже надо обновлять, если оно касается каких-то изменений, которые внёс поставщик.
А если не касается, то и в самой непосредственно конфигурации он не вызовет никаких сложностей. При обновлении снимаете галочку где надо и всё.
(13)Не сталкивался, либо у меня маловато на расширениях висит, либо я что-то делаю не так) Просто у платформы есть тест на совместимость, он выявит все проблемы до начала обновления. Для меня проще подправить пару модулей в расширении после теста, нежели каждый раз дрочится над всем обновлением и вспоминать, правил я тут что-то или нет. Соответвенно делаю сравнение каждого модуля и смотрю на наличие моего кода. В случае расширений у меня такой головной боли нет.
НО! Я с вами соглашусь в том, что расширения не панацея от всех бед, но если объем изменений не критичный, то лучше жить на них. В случае топикстартера, как по мне, это лучшее решение, так как ему только один модуль подправить.
1С любит любить своих клиентов, банальное изменение наименования документа или реквизита, может привести к большому геморою в случае наличия собственных изменениях. И каждый решает сам на своей кухне как ему её готовить. Так как только он знает, что он хочет и что-где лежит.
НО! Я с вами соглашусь в том, что расширения не панацея от всех бед, но если объем изменений не критичный, то лучше жить на них. В случае топикстартера, как по мне, это лучшее решение, так как ему только один модуль подправить.
1С любит любить своих клиентов, банальное изменение наименования документа или реквизита, может привести к большому геморою в случае наличия собственных изменениях. И каждый решает сам на своей кухне как ему её готовить. Так как только он знает, что он хочет и что-где лежит.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот