Вопрос в заголовке. 1С 8.3, УТ 11.4.
Есть документ на центральном узле РИБ. Для нужд предприятия в конфигураторе у него сменили доступы по ролям. Т.е. определённая роль потеряла возможность его проводить. И на центральном узле всё работает как надо, но...
Как перенести это дело на подчинённые узлы?
Оно возможно должно работать автоматически, но не работает.
Сразу предупреждаю, не программист, занимаюсь этим по воле случая, поэтому мне что попроще, ну либо поподробнее))

С учетом последнего предложения я бы вообще не советовал заниматься чем-то серьезным, не будучи специалистом. Но вообще, если конфигурация не "перепрыгивает" в подчиненный узел, значит наблюдаются какие-то проблемы. Их может быть десяток и даже наиболее распространенные требуют длинных портянок с текстом и скриншотами (чтобы прояснить вещи неспециалисту). Но обычно программисты делают так:
1. Снимают подчиненный узел с РИБ (есть для этого обработки, но можно и запустить 1С с ключом запуска /ResetMasterNode
2. Загружают туда конфигурацию из центрального узла (предварительно выгрузив ее в конфигураторе ЦБ)
3. Возвращают подчиненный узел обратно в РИБ. Вот тут я не знаю, как это сделать с помощью ключа запуска, т.к. пользуюсь простенькой обработкой

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

(1) Ну, этот метод я оставил прям на самый крайний случай.

Может ещё какие-то варианты есть... залезть где-нибудь настройки синхрона проверить..
Или где-нибудь хотя бы посмотреть в чём причина того что оно не переносится.
И возможен ли вариант что если внести изменения поглобальнее в конфиг (например новый справочник создать) то оно таки заообновится...

(2) а обмены то ходят?

хотя может на РИБе у пользователя включена другая роль, которой можно перепроводить...

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

(3) Синхронизация в 1С регулярная настроена, каждые пару часов. Данные по товарам, ценам, документы и т.д. всё как надо.

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

(5) нет, пользователи в каждом узле свои, и не вижу смысла их таскать взад-назад)

(6) "Данные по товарам, ценам, документы и т.д. всё как надо."
Значит оно не РИБ и права в дочках нужно прописывать на месте.

(6) "Редактирование идёт именно со стороны документа, не со стороны ролей."
Можно для бестолковых растолковать этот поток?

(8) Оно РИБ. В Конфигураторе всё залочено, так и написано что заблокированно средствами управления РИБ.
Конечно было бы в разы проще если бы на месте можно было это всё прописать. Но это только отвязкой базы открывается. Я дома на левой копии так и делал.

(9) как он его растолкует, если отрицает свою принадлежность к программистам

(11) ну я там же написал сразу растолкование "Т.е. я в конфигураторе зашел конкретно в настройки документа и убрал галочки на права проведения у всех ролей кроме одной."

(10) Если оно было бы РИБ, а у тебя в центральном узле произошло изменение конфигурации, то обмен между узлами в плане обмена РИБ просто отвалился бы и не работал.

Можно сделать альтернативные версии, когда на РИБ созданы периферийные узлы и базы выгружены, но затем заводится еще один план обмена, который уже не РИБ и весь обмен рабочими данными происходит уже по второму плану, что бывает удобно, если разработка продолжается в интересах центрального узла в части функционала, который не пересекается в периферией.

(12) Нах ты это делал, если ты не программист?!

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

(14) Всмысле нах?))
Мне надо сделать так чтобы определённые роли не могла проводить вышеобозначенные документы. Как на центральном узле, так и на подчинённом.
Можете подсказать другой способ как это сделать? Буду благодарен.

(15) "Всмысле нах?" Тебе прозрачно намекнули, что для начала нужно попытаться разобраться.
Почему есть сомнения? Потому что :
1. "занимаюсь этим по воле случая".
2. Утверждая что сломался обмен, говоришь "Данные по товарам, ценам, документы и т.д. всё как надо." А это невозможно в условиях РИБ и сломанного обмена.

Туту два варианта.
1. Либо у тебя не РИБ и обмены ходят другими средствами.
2. Либо нет никакого "слома" обменов и ты "не шмогла" угадать что и где нужно править.

В любом случае твоей компетенции судя по всему недостаточно. Потому и "нах?".

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

хочется уже спросить, а здесь есть кто-то кто реально может помочь, или здесь только те кто претензии предъявляет?))

Ситуация описана, если кто-то реально может помочь, пишите, отвечу на необходимые вопросы. Если кто-то может подсказать как закрыть проведение (только его) документа для пользователей на подчинённом узле, велком.
Если кто-то просто с вопросом "нах?", то лучше не пишите.

(17) если конфа не переносится в ПБ, то это обмен не по рибу.
Открой уже планы обмена и посмотри, сколько их и какие..и какие галки на них в пофигураторе выставлены.

И по какому плану обмена идёт обмен и как и по каким правилам, если это не риб

(18) а где это посмотреть?

(17) что-бы тебе реально помочь нужно _смотреть_ именно в твою конфигурацию и _видеть_ и _понимать_ как оно устроено в _конкретной_ базе.

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

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

(20)
в предприятии
меню-операции-планы обмена
меню-все функции-планы обмена
меню-хрень для разработчика- планы обмена

в пофигураторе - планы обмена и свойства

(22) По поводу предприятия, я там такого не нахожу.
А в конфигураторе, речь идёт о дереве конфигурации? Там где дерево идёт Управление Торговлей - общие - планы обмена?
Там куча планов обмена.

(23) Меню -пареметры-галка отображать панель все функции.. далее по списку.

(24) У нас нет ни "меню" ни "параметров".
У нас есть раздел НСИ и Администрирование для всяких настроек)

(0) А ты когда галки снял с конфигураторе с ролей, как базу обновлял?
Динамически?
Если да, то такие обновления запросто могут не полететь в РИБ-узел.
Тогда тебе их переносить через CF-ник.
Или ещё раз попробовать обновить базу только уже всех выгнав из центрального узла.
2 раза обновишь (1 раз галки верни обратно, 2 раз сними их).
И тогда ,возможно, обновления полетят в РИБ.

Никогда не обновляй базу динамически!

(25) правый верхний угол или правый левый угол (зависит от платформы) ..и там на кружок 1с

(26) фигня. Демоническое обновление никак не затронет риб, и новый конфиг полетит в пб как миленький.

(26) Чисто интуитивно, но да, не обновляю динамически, само слово не нравится)) Там 1 пользователь, сначала выходил им, менял в конфигураторе доступы на документ и делал обновление базы.

CF есть, сравниваю с периферийным, различия есть, как раз таки по нужным документам. Давала бы подчинённая  CF объединить с текущим, но я так понял что без отвязки не даст. Отвязать то я отвяжу, а вот обратно...

(28) не фигня.
Ещё на рознице 1.0. демоническое обновление ломало все обмены.
На 2.3 я с таким тоже сталкивался. Конфигурация не полетела, а обмены продолжали работать.
Это конечно может быть был баг платформы, но такое точно было.

(29) 1. Отвязываешь базу.
2. Сравниваешь с CF. Обновляешь базу.
3. Заходишь в базу, она спрашивает, подключить базу к РИБ. Соглашаешься. Проверяешь обмен. И всё ок.
4. На всякий случай сделать бэкап РИБ. Лишним не будет. если сомневаешься.

(29) одна строчка кода

ПланыОбмена.УстановитьГлавныйУзел(?(ЗначениеЗаполнено(ТвойУзелНаФорме),ТвойУзелНаФорме,Неопределено));

(30) да-да да..когда-то, когда г..о мамонта еще было тёплым

(27) Нашёл!)) Нашёл!)) Под обоями нашёл проход в Нарнию))
Там планов обмена куча.
Но из них какие-то данные есть только в одном. Я на него до этого когда-то настраивал автосинхронизацию.

(31) Ну примерно такое я видел когда дома над черновиком изгалялся.
Просто там выше писал кто-то что на моменте возврата в РИБ могут десятки ошибок возникнуть... Вот собсна и сижу боюсь такое делать

(34) ну и открывай их все.. найдешь в тот, в котором узлы есть.. Смотришь, че за план обмена, топаешь в пофигуратор, смотришь, что в ходит в состав и есть ли галка риб в нём

(35) про 10 - это писали про причины....

(36) галка есть, тыкаю Состав, там галочки везде. Авторегистрация стоит запретить.

(38) (38) в самом предприятии, узлы есть в этом плане обмена ?

(39) Да, да. Узлы есть. Собсна два узла, центральный и подчинённый. Выгрузка взад-назад работает. остатки, цены, документы, всё корректно доходит туда-сюда.
Не знаю, это так должно быть, или нет, но на всякий случай расскажу что обмен у нас чтобы полный сделать между двумя базами надо синхрон делать 3 раза. Сначала один узел, потом второй, потом снова первый. При чём не важно какой узел первый или второй)

(40) За количество обменов - так и должно быть. Вернее не совсем так.
1. Выгрузка из узла 1.
2. Загрузка на узле 2 и выгрузка на нем же.
3. Загрузка на узле 1.
Но для простоты всегда загрузка совмещается с выгрузкой. Можно сказать в одной транзакции. И называется оно обменом. Потому и "надо синхрон делать 3 раза".

(41) Да, так и думал) Спасибо что подтвердили)

Ну вот, походу дальше уже никто не поможет))

см (21)

это реально так

(43) чем помочь то ?
если что, можешь отвязать базу в ПБ, загрузить cf от центра, далее назначить главный узел.
Поделка в (32). ТвойУзелНаФорме будет с типом планыОбмена.ТвойПланОбмена с рибом.

Вопрос решился. Несколько другим способом. Может будет кому-то полезно.
Чтобы решить пришлось зайти несколько с другой стороны.
Опишу проблему и решение.

Проблема: Нужно сделать так чтобы в подчинённом узле РИБ конкретные 2 профиля не могли проводить списание, оприходование и пересорт товара.
На главном узле это легко получилось сделать редактированием этих документов в конфигураторе. Т.е. просто зашёл в конфигуратор, зашёл в свойства трёх документов (оприходование, списание, пересорт) и в разделе Права у нужных ролей снял галочку Проведение. И обновил конфигурацию.
Но в подчинённые узлы эта конфигурация упорно не хотела перелетать. Способ с отвязкой подчинённого узла и привязкой заново посчитал слишком рискованным и пошёл другим путём.

Решение: На основном узле была создана новая Роль. Каждый нужный документ (оприходование, списание, пересорт) был отредактирован по правам. У этой новой Роли были выставлены галочки кроме Проведения. Конфигурация была обновлена. После этого сделан синхрон с подчинённым узлом. И чудо - теперь конфиг пошёл в узел. Когда там сделали синхрон, пришло обновление, конфиг обновили и получили на подчинённом узле эту самую Роль без права проведения тех самых трёх документов.

З.Ы. Была одна запара, связанная просто с невнимательностью (галочку не убрал в правах на одном из документов). И пришлось чутка менять права с документов снова и снова делать синхрон. Были подозрения что не получится, т.к. до этого когда меняли права у документов на стандартные роли (без добавления новой Роли) обновление конфига не уходило в подчинённые узлы. Однако на сей раз всё пошло как надо.
В общем, в итоге, когда изменение касалось Ролей доступных системе по стандарту, конфиг не уходил на подчинённые узлы. Если изменение касается Ролей созданных пользователем, то конфиг нормально обновляет подчинённые узлы.

З.Ы.Ы. Конечно, у нужных профилей на подчинённом узле пришлось убирать ту стандартную Роль которая давала им проводить нужные документы. (сразу нельзя было так сделать потому что эта роль давала их не только проводить но и создавать, а эту возможность нужно было этим профилям оставить.)