Приветствие!
Как Вы относитесь к расширению "Инструменты разработчика" (их несколько подобных) в боевой базе.

Заранее спасибо!

(0) А в чем проблема?
Безопасность?
Сам пользуюсь периодически ИнфостартТулкит и https://github.com/cpr1c/tools_ui_1c
PS:
В основном это Консоль запросов, Консоль кода, Редактор объекта, консоль СКД ежедневно и не по разу.
Остальным очень редко

А почему нет?

маст хэв

(2) Безопасность, тормоза, потенциальные ошибки... придумать можно много причин

(5) Ты какие для себя придумал?

нужное

(6) Не я. У руководства сомнения.

есть ирПортативный, открывается внешней обработкой

(8) ну ты всем то их не давай

(9) Это само собой
(10) Ну если только втихую... :) Хотят всё знать и контролировать

(8) Ну бесплатными не пользуйся. Пользуйся платной с поддержкой и какими то гарантиями

(11) Беги оттуда (с)

Нужно ли давать разработчику полные права на разрабатываемую базу?

Ведь:

Не лучше ли выдать разработчикам блокноты и карандаши, а изменения в базу будет вносить всесторонне проверенный, прикованный к батарее и доверенный человек?

В рабочей нет. В копиях - да. Последняя практика такая. В прод не ставим ничего лишнего без особой надобности.

Когда-то, меня попросили убрать это расширение. Потом пользовался ирПортативный. Сейчас чаше Инфостарт Tools или чем-то другим, т.к. лень запускать обычное приложение.

мне портативной версии хватает

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

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

Правда мы никогда им не следовали.

(19) С базами ЗУПа такое частенько бывает.

даже не расширение, а встроено в конфигурацию ( https://devtool1c.ucoz.ru/  )

(19)у нас доступа даже не было к боевой. Но контора полумонополист.

(0) Отношусь плохо
Там и так обычно левых расширений хватает

Свежие актуальные копии прода надо иметь
Средствами СУБД + постобработка
В т.ч. можно скриптами нужные расширения накатить и прочее
Ну типа нумерацию сбросить

то которое от TormozIt - рулит!
неистово плюсую, дай бог человеку многие лета

для него, чтоб у "эффективных" с полными правами не было вопросов, нужно рядом поставить еще одно расширение, не позволяющее БСП перехватывать роли

а нимфосратовский тулкит - баблосишен-думен-корумпирен сборная солянка от обработок, из которых половина была на руках еще до его появления

Удобно. Почему нет? Чему это мешает? Права полные руководству не выдавать: вот это важнее.

(18) >> Использовать такие мощные системные инструменты как инструменты разработчика в проде - дурной тон.

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

Использование таких инструментов в проде - это не какой-то там тон (дурной или недурной). Это необходимость.
И если Вы скажете, что никогда-никогда ничем подобным в проде не пользовались, извините, но я не поверю. С вероятностью примерно 146% пользовались. Просто это были не встроенные, а внешние обработки. А в чём принципиальная разница?...
Да работать с продом при помощи ИР - это плохо и "ай-ай-ай". Но это в идеальном мире, где все все участники процесса (и пользователи, и админы, и разрабы, включая разрабов самого вендора) - это розовые единороги, пукающие исключительно бабочками, а не рукожёпые кожаные зомби, старающиеся обосраться на каждом шагу вполне реальной неприятной субстанцией, где это только возможно. И за ними надо и проблему найти (фиг с ним - это в 99% случаев можно сделать в копии), и потом исправить её в проде, не перепроводя базу за последние пять лет. А потом ещё проверить корректность исправления.

>> Это как оставлять полную отладочную информацию в исполняемых файлах, которые уходят в продажу.

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

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

А про администратора базы данных Вы никогда не слышали?
Существует ещё такой пользователь.

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

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

(0) пришлось встраивать в конфу после того как один чел из саппорта на проде нажал кнопочку "Выключить все регламенты" и бездумно Да или Нет в следующем вопросе (короче не сохранил список активных).

Встроил и тупо заблокировал кнопку ) если б каждый открывал свою портативную версию наехувертили б там такого...

Если право их использования не раздавать всем подряд, то риски небольшие, а вот возможности огромные. Например CTRL+ё для вызова глобального контекстного меню в любом форме нажимать с ИР - наслаждение. Попробуешь пару раз и подсядешь.

В продуктиве разработчику вообще делать нечего. Три контура - разработка, тестовый, продуктивный. В первые два - пожалуйста.

(29) Не надо придумывать небылицы
Не существует никаких отдельных "тестовых" контуров
Каждый контур из разработка, препрод|предрелиз, прод|релиз - является тестовым

(30)+ Количество контуров может быть как больше
Так и меньше, вплоть до схлопывания в один прод, где на лету и тестят и правят-кодят

Кто несет ответственность за принятие подобного решения? То, что большинство ИТ-директоров не хотят связываться с разработкой, если это поддерживающее подразделение, прекрасно известно. Но, как говорится, «назвался груздем — полезай в кузов». Что, ИТ-директор не может сказать, как работать? Нет верных или неверных решений. Есть решения, за которые несут ответственность, и те, которые перекладывают на подчиненных и ответственность не несут.

(29) >> В продуктиве разработчику вообще делать нечего

Да.
Только при чём тут разработчики и тема ветки?...

То, что "Р" в названии "ИР" обозначает "разработчика", совершенно не означает, что пользуются этими инструментами исключительно разработчики. Всех прям как будто заклинило на этом слове. Ну дал автор название своему творению такое. А мог бы назвать "Инструменты администратора", или "инструмента администрирования" или "Инструменты работы с базой данных 1С", или ещё как-то без использования слова "разработчик".
В таком случае чтобы Вы говорили о контурах?

(33) К любым лишним инструментам плохо отношусь
Не требующимся каждый день в проде

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

Если ИР в проде - значит все плохо с организацией
Подозреваю даже проблема с бэкапами, их восстановление кто проверяет?

(33) Ну расскажите, что Пользователи смогут взять себе для работы из расширения "Инструменты разработчика"? Даже интересно.

(24) +100500

(35) Так не пользователи обычные, а например ТП.
Часто используется редактор объекта.

(0) Я не использую, но я не показатель. Мне вот недавно подсунули обработку нормального программиста поправить. Я почитал его код и мне стало стыдно за свой собственный. Числил всё себя программистом я. Оказалось это необоснованная мания величия. Я не программист с нормальным инженерным бекграундом, а так себе... кодер

(35) >> Ну расскажите, что Пользователи смогут...


Ничего.
Я вроде как вполне русским языком написал в (26): "никаких прав у обычных пользователей на инструменты быть не должно".

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

(34) >> для тестирования и разбора инцидентов ... есть механизм ежедневных/еженощных/ежечасных и т.д. копий прода

Ага-ага.
Держать по три сервера для копий ERP-шки весом в 100Гб?
В теории конечно возможно. И в идеале может быть даже верно. Но на практике, в жизни, во-первых, редко, кто даст выделит такие ресурсы. А, во-вторых, целесообразность сомнительна.

Тестирование и разработка - да. Очевидно должны быть строго отдельно. Но для разбора каждого инцидента держать горячую копию.... ? Зачем?... Когда можно зайти в прод и воспользовавшись ИР посмотреть...

(40) У меня домашний комп диск только SSD ~4Tb (там все сложно ибо 3 ssd nvme в raid0 и гибридка ssd+hdd)
И примерно 12Tb hdd
Вы там с базой 100Гб не можете купить пару нормальных дисков на сервер?

(40)
Конечно можно!
А еще можно не выгоняя юзеров закрывающих месяц начать там прямо в проде кодить...
И отлаживать и конфу применять с реструктуризацией или просто динамически

(0) это все устарело. если работаешь с кодексом, вот это вот все нахер не надо...

(42) >> А еще можно...

Не передёргивайте.
Вы прекрасно поняли что я имел ввиду. Я нигде не предлагал на проде кодить, включать отладку или делать динамические обновления с реструктуризацией и без. Держите свои бурные фантазии при себе, пожалуйста.

(41) >> Вы там с базой 100Гб не можете купить...

Во-первых, я не занимаюсь закупками. Это в другой отдел.
Во-вторых, проблема тут отнюдь не только в дисковом пространстве. Вопрос, например, в целесообразности. Тратиться на настройку всего этого добра только ради того, чтоб специалист техподдержки мог открыть, например, обработку сравнения объектов из комплекта ИР, что разобраться - чем отличаются два одинаковых с виду документа, которые при проведении дают разные результаты.
И это не считая того, что любая репликация - это дополнительный расход ресурсов рабочего сервера, который и без того не отличается высокой скоростью работы с ERP.