Нужно сделать общих пользователей в системе с УРИБ. Возникает вопрос - как?
Суть проблемы такова, что в бюджетировании требуется согласование заявок на расход денег. Согласование происходит в центре одним-двумя (непринципиально) пользователями для разных периферийных баз (УРИБ минимум трёхуровневая с разными организациями в периферийных узлах). Соответственно, в общей центральной базе имеются согласователи как пользователи ИБ и в справочнике Пользователи. Так же эти согласователи имеются и в периферийных базах, а, соответственно, имеются там и как пользователи ИБ, и в справочнике Пользователи. Естественно, что в центральной базе в справочнике Пользователи количество элементов, соответствующих каждому согласователю, равно числу баз (периферийных узлов). Маршруты согласования не привязаны к организации - они общие. Возникает проблема, как сделать так, чтобы во всех базах было по одному элементу на каждого согласователя в справочнике Пользователи?
...
Каждый элемент привязан к пользователю ИБ, а они, что очевидно, в разных узлах - разные.
...
Что я придумал. Так как базы у нас SQL'ные, то я выяснил, что вот такое:
ПользователиИнформационнойБазы.ТекущийПользователь().УникальныйИдентификатор
...возвращает просто значение колонки ID из таблицы dbo.v8users. Я думаю взять и принудительно во всех базах всем пользователям, реально являющимся одним и тем же лицом принудительно через скрипт SQL заменить этот ID на одинаковый.
Насколько это реально, опасно или безопасно?

Заявки выгружайте в центральную базу, а там уже согласуйте.

Это опасно. База может рухнуть.
Можешь просто в таблицу соответствия объектов привязать их друг к другу.Тогда при загрузке, он тебе будет каких надо пользователей подставлять...

(1) Я же вроде бы ясно написал, что там - другой пользователь является глТекущийПользователь (ПараметрыСеанса.ТекущийПользователь). Соответственно, прога лезет в маршруты, не находит там текущего глТекущийПользователь и заявляет, что ему нечего согласовывать.
(2) Так это всё равно - конфу курочить. Не хотелось бы лезть в этот типовой механизм.
И по поводу "рухнуть"... Сомнительно, ибо я же могу этого пользователя в Конфигураторе удалить - а базе ничего от этого не будет. Имхо, я прав...-_о
PS
А, блин, забыл упомянуть, что конфа - УПП. Пардон!

я хз как у вас, а у нас в квартире газ...

Справочник Пользователи должен быть един на все базы. Пользователи ИБ - каждый в своей, согласование по Пользователи (сиречь ответсвенный), т.к. он един - то и проблем быть не должно

>>Насколько это реально, опасно или безопасно?
угу... а в документах у тебя будет "объект не найден <>"?

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

(4) Так справочник и так един, но в его свойствах есть такое - ИдентификаторПользователяИБ. То есть тут указывается GUID пользователя, каков он в Конфигураторе!!! А очевидно, что в разных узлах он разный, ибо "пользователи ИБ" не передаются между базами.
(5) С какого это "не найден"?
(6) Это ясно, но это - после того, как сделается один общий пользователь на одно реальное лицо. А до этого - см. ответ на (4).

(4) Забыл добавить, что УПП (по крайней мере она) по этому свойству (ИдентификаторПользователяИБ) при запуске сеанса ищет элемент справочника в справочнике Пользователи.

(8) помоему вы просто сами насоздавали "пользователей", ИдентификаторПользователяИБ может быть один на все базы, посомтри код процедуры "ОпределитьТекущегоПользователя", там дополнительно поиск по Коду, если не найдено по идентификатору... короче пройдись. Не должно быть "задвоений" юзеров в справочнике

(9) Вот мне заняться больше нечем, только юзерей создавать.:))
ИдентификаторПользователяИБ может быть и один, но такой пользователь ИБ (т.е. тот, что в Конфигураторе) имеется только в одной базе. Соответственно, если в базе (в центральной) войти под аналогичным (но не таким же) пользователем, то там ИдентификаторПользователяИБ будет иной и 1С'ка не найдёт юзера по данному идентификатору - и тогда откроет "поиск по коду". Но это будет уже не тот пользователь (из справочника Пользователи), что был в другой базе.
...
Опять же сделать одного с совершенно левым (или вообще без) ИдентификаторПользователяИБ и распространить по базам, конечно, можно. Но первая же попытка записи такого элемента в режиме Предприятия создаст пользователя ИБ в конфигураторе. Причем в одной базе ему присвоится один ГУИД, а в другой - другой. И опять всё запутается.

(10) короче понятно, в 1.3 поменяли алгоритмы, незнаю правда какую цеоль преследовали. у нас изначально 1.2 была, там тупо по коду, такой проблемы не возникает. справочник Пользователи един в рамках всей РИБ... странно вобще

(11) Ну, 1.2 уже давно не поддерживается. Да, поменяли алгоритм. И теперь такая фигня, что непонятно как сделать общего по РИБ пользователя (-ей).

(12) почему не понятно? убрать нафиг этот поиск по ИдентификаторПользователяИБ :) оставить по коду. Нормально это, если нет юзеров с одинаковым ФИО в разных базах (действительно разных физ лиц)

(13) Так вот, может, для того 1С и сделали этот новый поиск? Для исключения таких коллизий?

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

>> там - другой пользователь является глТекущийПользователь (ПараметрыСеанса.ТекущийПользователь).

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

>> Но первая же попытка записи такого элемента в режиме Предприятия создаст пользователя ИБ в конфигураторе
Чо эта? Она тебя спросит, создавать пользователя? И если согласиться, то создаст.

(10)>> странно вобще
Более чем

(16) Как раз я - не путаю. А вот объяснил, возможно, путано - ну, уж как получилось.

Это если я не соглашусь. А если кто другой залезет туда? Конечно, правами можно ограничить, но хз как оно в жизни-то...

Что - "более чем"?