Это решается не привязкой данных, а SQL-скриптом.



Посмотрите, какие Id и SysSchemaId у вас на среде разработки и их вставьте в подобный запрос. А перед эти проверьте, нет ли у вас уже property 'Enabled' для данного процесса (схемы) на среде, куда будете переносить



INSERT INTO "SysSchemaUserProperty"

("Id","Name","Value","SysSchemaId")

VALUES 

('0a16d853-9e01-4544-8a6f-3ebde5d3bbed','Enabled',false,'4944ebb5-1881-46a9-85df-b93d092424ad')

ON CONFLICT DO NOTHING

Специального механизма массовой актуализации данных в интерфейсе нет.

Как вариант, можно использовать разработку в файловой системе. Если выгрузить привязки в ФС, то с помощью любого продвинутого текстового редактора и регулярных выражений можно произвести массовые изменения по файлам привязок, а потом загрузить полученные файлы обратно в БД (ну или залить в SVN). Аналогичные манипуляции можно провести напрямую в БД (таблица SysPackageSchemaData), только в таком случае процесс будет еще более сложным.

Вроде бы это сообщение о том, что присутствует колонка, в которой лежит файл. А вывести эти данные в реестр невозможно

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

Добрый вечер.

Подобные темы уже обсуждались на Community. То, что не привязывается к данным, переносят SQL скриптами, которые также привязываются к пакету.

Алла Савельева,

Есть даже пример таких скриптов для переноса этих настроек?

Или, может, Terrasoft сделает возможным перенос стандартными средствами? 

Владимир, пока этой функциональности нет в базовой версии, рекомендуем выполнять перенос скриптами. 

Реализовать перенос настроек организационной структуры и прав доступа из одного стенда на другой можно с помощью SQL-скриптов. Для этого на эталонной среде необходимо сформировать insert-запросы на основании записей со следующих таблиц:

• SysAdminUnit (Объект администрирования: пользователи и роли)
• SysUserInRole (Непосредственные вхождения пользователей в роли)
• SysFuncRoleInOrgRole (Вхождение функциональной роли в организационную)
• SysAdminOperation (Системные операции, если необходимо)
• SysAdminOperationGrantee (Доступ к системным операциям, если необходимо)
• SysEntitySchemaOperationRight (Доступ к объектам)
• SysEntitySchemaRecordDefRight (Доступ к записям по умолчанию)
• SysEntitySchemaColumnRight (Доступ к колонкам объекта)
• SysAdminUnitGrantedRight (Делегирование)

Для формирования запросов можно воспользоваться Microsoft SQL Server Database Publishing Wizard и подобными инструментами. Полученный SQL-скрипт необходимо прикрепить к пакету (вкладка - «SQL-сценарии»).

Если перенос происходит на продуктивную среду, то мы рекомендуем предварительно сделать резервное копирование данных, и, в первую очередь, заливать пакет на тестовую среду, чтобы проверить результат выполнения скрипта. Эти работы необходимо выполнять не в бизнес-время.

Ещё очень интересное поведение заметили.



Записи SysEntitySchemaColumnRight были перенесены полностью идентично на рабочую среду (проверили после переноса). А через некоторое время на рабочей среде оказались те же записи, но с совершенно другими Id. 



Какие процессы могут полностью сменить Id в этой таблице? И на что это может повлиять?

Может, компилировали объект? Актуализацию прав запускали?

Зверев Александр пишет:

Может, компилировали объект? Актуализацию прав запускали?

Да, компиляция же происходит после каждой установки новых пакетов (с того же Marketplace), насколько я понимаю.



И актуализация прав запускается после изменений в пользователях/ролях.

1. Но как это влияет на настройки доступа по колонкам?



2. И как переносить последующие изменения в настройках доступа по колонкам, если по Id уже не понять, это те же настройки или уже другие?

Владимир, логика перераздачи прав не предусматривает сохранения Id записей. Вы можете предусмотреть в своих скриптах привязку не к Id, а к SysAdminUnitId, SubjectColumnUId и SubjectSchemaUId, они должны быть стабильными.

Говорят, в будущих версиях планируется новый механизм прав, там будет возможна привязка их к пакету.

 

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

Если первое, то нужно, чтобы на базе, куда переностите, уже была такая схема и создавшаяся по ней после публикации таблица в БД. Или же схема создавалась или дополнялась в том же пакете, что и данные в неё. А наполнение справочника затем переносить при помощи привязки данных к пакету.

Если второе, то нужно не создавать объект или замещающий объект вручную, а переносить с сайта-источника готовую схему (или путём выгрузки в md-файл, или через SVN, или пакетами).

Объект Tax — стандартный, у Вас в нём есть какие-то доработки?

У нас был похожий опыт переноса дополнительных страниц редактирования для стандартных разделов году в 2018. На сколько я помню, все кастомные разделы с несколькими страницами редактирования переносятся нормально, а для стандартных разделов нужно выполнить это не привязкой данных, а SQL скриптом на целевой среде после переноса. Я попробую поискать вариант скрипта в архивах. Если найду - вышлю вам.

Нашел.

Необходимо добавить связь в таблицу SysModuleEdit. Детальнее можно почитать здесь. Нам помогло.

 https://community.terrasoft.ru/questions/rucnaa-registracia-razdela

Сидоров Александр Валерьевич,

Спасибо, как раз привязку делал через эту таблицу, но не могу найти колонку что отвечает за справочник (таблицу в которой значения на основе которых разные страницы прописываются)

Александр Тыра,

1. Уточните, пожалуйста, версию bpm'online, в которой Вы выполняете настройки?

2. Я правильно понимаю, что при создании нескольких страниц редактирования, через мастер разделов, не выполняется автоматическая привязка данных об этих страницах в таблицу SysModuleEdit?

Если Вы используете последнюю версию и там не работает такая привязка данных, то это является недоработкой мастера раздела.

Александр Тыра пишет:

не могу найти колонку что отвечает за справочник (таблицу в которой значения на основе которых разные страницы прописываются)

В таблице SysModuleEntity колонка TypeColumnUId.

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

Алла Савельева,

Версия 7.15.2. Привязка для страниц происходит, но именно привязка названия справочника откуда берутся значения привязки для каждой страницы не привязывается, потому при установке пакета привязка по страницам не может отработать так как нет привязка справочника (на втором скрине выделено поле со справочником)

Алла Савельева,

Колонка TypeColumnUId заполнена у страниц, проверил на корректность. Но справочник (выделенное поле) не заполнен, и потому думаю не происходит установка значений из пакета (связка видимо не дает)

Алла Савельева,

Думаю это оно и есть, просто уже перенес данные и думаю потому не вижу разницы, но вот думаю это оно. Спасибо большое

Александр Тыра,

Интересно, исправлено ли это в последней актуальной на текущий момент версии 7.15.4?

Алла, с версии 7.14.3 заведена проблема «Перенос пакетов. При переносе пакетами раздела с несколькими страницами редактирования настройка типизированных страниц не переносится - используемые значения справочников не переносятся пока для колонки  TypeColumnValue не установить признак Force Update», она ещё не решена.

Зверев Александр,

Решил попробовать то что Вы процетировали, и после того как указал принудительное обновление колонок все перенеслось.

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

На втором скрине данные которые уже привязаны к пакету и находятся в свн, а на первом 5 записей, которые уже давно привязаны к пакету и находятся в свн + 2 записи, которые вы привязали но еще не залили в свн

Миннекаев Айдар,

В данном случае вообще не работаю с SVN.

Все 7 записей ранее не были привязаны к пакету.

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

Есть ещё какие-то варианты?

Была подобная проблема связанная с локализацией. Попробуйте привязать по ИД. А еще после установки приложения https://marketplace.terrasoft.ru/app/data-binding-tool процесс привязки данных стал в разры проще.

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

Алексей Следь пишет:

Была подобная проблема связанная с локализацией. Попробуйте привязать по ИД.

Какая именно проблема - можете подробнее написать? С привязкой по Id работает аналогично.

Зверев Александр пишет:

Может, что-то не так с локализацией этих значений, когда строковые значения на разных языках хранятся в разных таблицах

С локализацией вроде все в порядке. Все справочники создавались под одной локализацией и не переводились на другие языки.

Какие ещё могут быть варианты?

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

Алла, добрый день.

На вашем первом изображении отображается 7 записей - это кол-во записей в вашем приложении, которые подходят по фильтру.

На втором изображении 5 записей - это те записи, которые уже привязаны и находятся в вашей привязке. 

Т.е. Если вы хотите чтобы в вашей привязке были все 7 записей, которые на данный момент находятся в вашем приложении, вам необходимо перепривязать (пересохранить) вашу привязку.

P.Shvedun пишет:

вам необходимо перепривязать (пересохранить) вашу привязку.

 А каким образом это сделать?

Алла, причина и способ устранения могут быть аналогичными этой теме.

Зверев Александр,

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

О переносе речь не идет, так как данные не привязываются.

Значит, нужно смотреть, в чём разница между теми записями, что привязались, и что нет.

Зверев Александр,

Уже смотрела, но разницы не нашла. Можешь конкретнее написать, что следует проверить?

Но если внешне одинаковые записи в одном и том же справочнике ведут себя различно, значит они не совсем одинаковые, разница либо в полях, либо в наличии/отсутствии ссылок из других таблиц. Есть скрипты по поиску Guid по всей базе, может, по Id этих справочников будет что-то интересное?

Алла Савельева,

Всё что вам нужно, это открыть вашу привязку и сохранить её. Все данные, которые подходят по условию, привяжутся к данной привязке.

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

Черным же по белому написано Название таблицы и Название Констрента. Смотрим Констрент и поля что входят в данный Констрейнт. Делаем выборки по 2 таблицам и ищем недостающие ID, что есть в Пакете но нет в этих 2 таблицах в Полях что Описаны в Констрейнте. Заливаем новые ID через данные и выполняем новое обновление и все взлетит.