Сразу скажу, что, возможно, это боян и все об этом знают 1000 лет и используют, но я не нашел на Инфостарте упоминаний о подобном решении. Так же опережу тех, кто будет говорить о регламентах и автотестировании, все это не дает 100% гарантии отсутствия ошибок, а лишь уменьшает их вероятность и шанс, что вас затронет эта ошибка, все равно есть.
Теперь к описанию проблемы: Рассмотрим типичную ситуацию: разработчик поместил в хранилище новый объект из своей базы, а дать права нужным пользователям на этот объект забыл. В итоге мы можем получить ошибки, связанные с тем, что пользователям в рабочей базе после обновления, даже тем, для кого этот функционал и не предназначался, будут сыпаться ошибки о то, что у них не хватает прав.
Обычно такую проблему решают следующими способами:
- Повторным обновлением. Дали по шапке автору проблемы, уведомили бизнес и обновили. Есть проблема: на некоторых предприятиях автомобили загружаются и разгружаются раз 5-10 мин и остановка базы для обновления вне регламентного периода — это ЧП, простои, очереди, штрафы и прочие прелести. К тому же, на некоторых предприятиях установлены SLA и их нормативы не позволят вам остановить базу.
- Динамическое обновление. Мы можем обновить базу динамически, т.к. реструктуризации нам не требуется, меняется только роль. Но у динамического обновления есть и свои минусы: возможные проблемы с доступностью и целостностью базы, проблемы с пользовательских и серверным кешем, возможные проблемы обменов РИБ, в связи с различием версий конфигурации.
- Временное присвоение пользователям административных прав. Решение рабочее, но все мы понимаем, чем выстлана дорога в одном крайне неприятном направлении, где пахнет серой и довольно жарко. Скажем прямо, решение очень не однозначное. Применять его можно только для доверенных и ответственных пользователей.
Есть и другое решение. Оно довольно очевидно, но его довольно редко применяют. Или может просто мне так не повезло. Если это так, то уберу публикацию в архив и посыплю голову пеплом 🙂
Суть метода в том, что мы просто добавляем новую роль, в которой отключаем все права, которые в ней будут при создании, при этом устанавливаем флаги «Устанавливать права для новых объектов» и «Устанавливать права для реквизитов и табличных частей по умолчанию». Что нам это даст. У этой роли будут максимальные права, но только на вновь созданные объекты конфигурации и мы в случае проблем с недоступностью объектов сможем без опасений дать пользователям эту роль на период, пока ошибка не будет исправлена. За пределы новых объектов они все равно выйти не смогут. Роль будет автоматически собирать в себя максимальные права для новых объектов, нам нужно только периодически ее очищать от них. Вот такая хитрость.
Если боян, извините, пепел уже заготовлен и ждет своего часа. 🙂
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Нормальное решение. Взял на заметку. Спасибо.
… и обнаружить после очистки, что горе-программист так и не настроил права для новых объектов, которые уже не такие уж и новые (а что — пользователи-то нормально работали, проблем не было, никто не жаловался. Пока не очистили спецроль)
Посему предлагаю модификацию метода:
— Создаем роли Спецроль1 и Спецроль2.
— Спецроль1 назначаем пользователям, в нее регистрируем все новые объекты.
— В момент времени «Т»:
— Очищаем Спецроль2.
— Отключаем пользователям Спецроль1, включаем Спецроль2.
— Отключаем регистрацию новых для Спецроль1, включаем для Спецроль2.
— В случае проблем включаем пользователям Спецроль1, а к разработчику применяем Ипатиевский метод.
Взял на заметку тоже. Спасибо.
Во, нормально. Запомню на будущее. Сам бы не догадался.
Главное у данной роли не забывать снимать флаг «Интерактивное удаление» у добавляемых объектов.
Отлично! Сам бы не сообразил. Постоянно натыкаюсь на эту проблему.
Зачет
решение на поверхности… ведь каждый знает про эти галочки… но вот не догадался о таком применении) спасибо за идею.
и про интерактивное удаление — мне кажется не большой это «косяк». новые объекты же — чего там удалять? невелика вероятность что серьезно порушат ссылочную целостность, имхо.
Интересное решение. Сам обычно взял за правило: создал новые объекты — протестируй под пользователями с ограниченными правами.
Прикольно, положу в копилочку
А потом выгрузка данных оказывается у конкурентов.
Или при ошибке/злонамеренно будет переименован справочник и потом все бегают не могут понять, что случилось.
Лучше внеочередное обновление, чем дыра в безопасности, о которой узнают не скоро, и достанется всем.
Особенно интересно, как потом СБ доказать, что это сделано случайно, потому что лень ставить галки в новых объектах, а не был преступный сговор.
А еще лучше не допускать таких ошибок.
Хороший прием. Возможно, когда-нить пригодится. Но сейчас не нужно.
Во-первых, железный регламент вбитый на подкорку: добавил новый объект в метаданные — тут же назначаешь подсистему, определяешь отображение в интерфейсе, добавляешь роли для него, если есть планы обмена — включаешь в них. И только после этого приступаешь к разработке. Так как ролей, объединяющих несколько прав, нет (все рулится через профиля БСП) и фактически все роли используют RLS, то забыть про права сложно. В крайних случаях динамическое обновление может выручить.
(11) Все зависит от того, что за объект новый, кто с ним работает, сколько и каких сотрудников… из двух зол выбирают меньшее. и как вариант обхода проблемы — решение хорошее. просто для примера использования: молочный завод. работа 24/7, окно для обновлений — вечер субботы (поздний вечер), 2 часа времени. добавлена обработка, но права дать забыли кому надо. что плохого в том, чтобы дать эту роль вместо демонического обновления? выгонять всех никто не даст. твои проблемы — это твои проблемы.
если такая строгая СБ, как вы пишите — то эта роль будет очень тщательно контролироваться прежде всего самим разработчиком. очищаться по мере выдачи прав в первую очередь и т.д.
ну а конечно лучше всего не ошибаться, все верно. вопрос в том что делать если все таки ошибся.
Автор, не бойся забаянить, боян на вороту не виснет 🙂
(0) тестировать доработки перед обновлением не пробовали?
(2) Зачем такие сложности, можно перед очисткой сначала на день два неделю, отключить спецроль у пользователей
Автору, спасибо взял на заметку.
(2) Нашли косяк, стали проверять тщательнее и предметно (как детектор взаимоблокировок в MS SQL). Вероятность повторной ошибки при этом уже около нулевая. Тут главное не переборщить с бюрократией, любую даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний 🙂
(5) Да понятно, что это выбор из двух вариантов: плохой и очень плохой. Только вот альтернативы какие?
(11) Как я уже писал, что это решение между плохим и очень плохим.
Между делом: работая более 10 лет на крупных предприятиях, неоднократно видел подобные выгрузки из баз конкурентов. Приоткрою вам завесу тайны, большинство из них делается под правами пользователей (не ИТ) имеющих очень высокий уровень доступа к базе, я даже один раз принимал расследование в таком инциденте, когда выяснилось, что информация была слита на уровне директората расследование закрыли и выяснять конкретное лицо не стали 🙂 Хотя ситуации бывают разные конечно…
(15) Если кратко, то обычно тесты покрывают не весь функционал, а только бизнес-критичный. 100% гарантии от ошибок не бывает, стандартный треугольник время — деньги — качество.
kolya_tlt прав, тестировать надо перед добавление в раб. базу, зачем усложнять систему, добавляя новые роли, при этом ещё и выполнять ненужные действия по очистке?
Интересный подход, и я думаю это действительно меньшее зло по сравнению с динамическим обновлением. Конечно лучше не совершать ошибок, но не погрешимых не бывает, особенно программистов.
(2) Взял на заметку Ипатиевский метод
Так, а как это решение поможет в ситуации, когда эта проблема возникла? Вот у меня возникла проблема, как мне теперь создать эту роль не прибегаю к первому способу решения?
(24)Это как с бекапами, лучше озадачиться этим заранее.
Ты гений!
С одной стороны хорошо, но как только начнутся чистки спецроли и забывание перенести в другие роли права, проблема вернется.Универсальное решение это тесты, тесты кодера,авто тесты,тесты бизнесом.
Оригинально. Может пригодиться.
Не все это знают и используют, оставляй)
Да, любопытное решение, за идею плюс.
1 раз столкнулся с проблемой подобной, и сразу же принял такое же решение. потому что зачастую новые объекты типовых не особо связаны с текущими задачами по ограничению доступа и если у пользователя появятся права на новые объекты — ничего страшного, зато ошибок не будет. Результат был отменный, клиент отказался от другой обслуживающей конторы, потому что после их обновлений постоянно была проблема с правами. а после моих ни разу 🙂
(8) ну кто как. я сразу же смекнул.
Вполне приемлемое решение. «+»
боян боянистый
Как решение +, но по себе знаю что буду забывать эту хитрость: » нам нужно только периодически ее очищать от них. » В результате тестирование и еще раз тестирование.
Зачетное решение. Спасибо огромное за лайфхак. Сам то я при добавлении новых объектов первым делом иду на закладку Права.
Бояном даже не пахнет. Спасибо, автор!
А, собственно, как добавление новой роли поможет там, где обновлять сейчас нельзя?
Что новую добавлять, что доработать и нормально обновить — надо остановить базу на 5 минут.
(38) Спец-роль добавляется заблаговременно. Соль в том, что права на новые объекты в нее будут насыпаться автоматически.
(39) то есть, если есть нормальный разработчик, который всё проверил и есть у него объект, на который прав НЕ ДОЛЖНО быть — то эта роль собственно даст читать что угодно.
Тоже не вариант.
По опыту — надо тестировать хорошо.
Хорошее решение. Спасибо.
Вроде все так просто и лежит на поверхности, но сам бы не додумался! Плюсую.
(40) Не что угодно, а новые объекты с момента предыдущей «очистки» роли. И только тем, кому ее временно назначат с полным пониманием последствий. По-опыту — несмотря на многие «надо», случиться может всякое. Ну а кому не вариант — тому не вариант.
ЗЫ. Мне не вариант, т.к. настройка ролей на новые объекты — это отче наш и делается чуть ли не до разработки объекта. А в случае форс-мажора не имею религиозных предубеждений против демонического обновления. Благо оно уже не настолько демоническое как было и нечасто возникающие проблемы лечатся относительно безболезненно. Хотя на заре сталкивался и с крашами и с тяжело вылечиваемыми последствиями. Но если выстроенный техпроцесс подразумевает четкий регламент обновлений, исключающих демонические — то вполне себе разумная и остроумная подстраховка.
спасибо сегодня же и применили — так совпало
(42) Для динамических обновлений тоже есть хинт 🙂
Спасибо автору! Это отнюдь не баян, а очень даже полезная идея.
Начиная с 8.3.9 роль можно добавить расширением
Спасибо! Реализую 🙂
Есть еще 1 способ:
У полных прав отключить автоправа на новые. тогда разраб сам столкнется с проблемой и практически наверняка добавит нужную роль
(48)Больше напоминает принцип «Назло бабушке уши отморожу». Тогда все сервисы и обмены нужно либо в привилегированном режиме выполнять, либо отдельную роль заводить (то есть еще одну). На мой вкус это слишком, я сторонник бритвы Окама.
(46) Интересный вариант!
(49) Не понял про сервисы? какая связь?
Смысл в том, что разработчик должен сам посавить галки в полных правах руками
Интересная метода, спасибо, буду использовать
Спасибо.
Гораздо проще работать с правами при активной разработке решения, когда некая базовая роль имеет флаг для новых объектов и всегда устанавливается для всех пользователей как базовая. Все остальные роли расширяют права базовой. Т.е. при необходимости ограничения доступа у базовой забираем и даем дополнительной.
Вуаля. И вы никогда… НИКОГДА не имеете проблем с памятью и забывчивостью.
Все гениальное — просто. Спасибо за идею!