Поле с сущностью на основе запроса Тип данных на основе сущности из другого приложения

Question

Цель

Я хочу централизовать личную информацию в одном приложении 2sxc и повторно использовать «Персоны» в других приложениях. Как человек в роли автора в приложении для новостей и человек в качестве члена в приложении для команды и т. Д.

Что я сделал

Создание приложения для управления персоналом (NPi_Person):

• Определите Персона Тип содержимого с полями, такими как «FullName», «Телефон» и т. Д.

В другом приложении, например, приложении для новостей (NPi_News):

• Определение в Новости Тип содержимого поля Person_Entity с типом данных Entity и типом ввода Запрос на основе объекта / средства выбора элементов .
• Создание запроса с источником данных Приложение на основе NPi_Person с получением типа контента Person (query_Person_from_NPi_Person).
• В объект-запрос определение поля Person_Entity относится к query_Person_from_NPi_Person и к потоку (например, По умолчанию ).

Задача

Раскрывающееся поле Person_Entity приложения NPi_News, как и ожидалось, содержит Person Сущностей из приложения NPi_Person. Проблема в том, что Персона не сохраняется. Значит после сохранения и повторного открытия формы поле Person_Entity по-прежнему пустое.

Означает ли это, что источник поля с типом данных Entity и типом ввода Объект на основе запроса / средство выбора элементов может не быть производным от другого приложения?

Answer 1

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

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

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

Answer 2

Просто несколько мыслей относительно альтернативного варианта использования информации о человеке в приложениях. Цель моего первоначального вопроса может быть достигнута, если рассматривать учетные записи пользователей DNN в качестве таких лиц.Для этого случая вы можете использовать DnnUserProfile Источник данных. dropdown-query Тип ввода поля мог бы получить DisplayName пользователя в качестве значения для поля значения.Его содержание определяется в DNN (Безопасность .. Учетные записи участников .. Настройки регистрации).Я бы установил его как [FIRSTNAME] [LASTNAME] [[USERID]] .Этот контент имеет смысл в форме редактирования, и в то же время USERID служит для поиска информации о пользователе из запроса приложения во время выполнения.Недостатком является то, что вы должны редактировать содержимое с помощью DNN UI (ссылки URL [ваш домен] / ctl / profile / userid / [ID]).