Не сохраняет значения в пользовательских полях SysAdminUnit
Здравствуйте.
Добавили новые поля BusinessSegment типа Справочник и BusinessSegmentString типа Строка в SysAdminUnit, VwSysAdminUnit, модифицировали скрипт для последнего, вывели новое поле в интерфейс на страницу SysAdminUnitPageV2. Система дает выбирать значение из справочника или вносить значения в текстовое кастом поле. Нажимаем кнопку сохранить, система говорит, что все ОК, только актуализируйте роли Но по факту значения внесенные в кастомные поля не сохраняются.
В клиентском модуле объект changedColumns содержит наше поле и внесенное значение в виде, который представлен на скриншоте. Далее вызывается веб-сервис AdministrationService. В нем меня смутило вот это место
/// Возвращает значение преобразованное в соотвествтии с типом колонки
///
/// Колонка схемы значение для которой необходимо получить.
/// Преобразуемое значение.
///
private static object GetColumnValue(EntitySchemaColumn column, object value) {
if (column.DataValueType is DateTimeDataValueType) {
return DataTypeUtilities.ValueAsTypeDateTime>(value);
}
if (column.DataValueType is LookupDataValueType){
return String.IsNullOrEmpty((string)value) ? null : value;
}
return value;
}
Думал может проблема с несовпадением по типу или формату (string с Guid), поэтому и добавил текстовое поле еще, но нет - текстовое поле точно также не сохраняет.
Подскажите в чем может быть причина? Можно ли вообще добавлять в SysAdminUnit пользовательские поля?
Нравится
Здравствуйте, Андрей
Недавно этот вопрос был подробно рассмотрен в этой теме
http://www.community.terrasoft.ru/forum/topic/21828
Здравствуйте, Андрей
Недавно этот вопрос был подробно рассмотрен в этой теме
http://www.community.terrasoft.ru/forum/topic/21828
Здравствуйте, Роман.
Спасибо за ответ. Я ознакомился с темой, которую вы предложили и не смог найти ответа на свой вопрос. Из темы также неясно решил ли автор все свои проблемы. Но те проблемы, которые он изначально поднял, я прошел. У меня поля добавлены в объекты SysAdminUnit и VwSysAdminUnt. Для View выполнен скрипт
[sql]
USE [BPMonline770]
GO
/****** Object: View [dbo].[VwSysAdminUnit] Script Date: 11.10.2016 21:01:55 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER VIEW [dbo].[VwSysAdminUnit]
AS
SELECT [SysAdminUnit].[Id]
,[SysAdminUnit].[CreatedOn]
,[SysAdminUnit].[CreatedById]
,[SysAdminUnit].[ModifiedOn]
,[SysAdminUnit].[ModifiedById]
,[SysAdminUnit].[Name]
,[SysAdminUnit].[Description]
,[SysAdminUnit].[ParentRoleId]
,[SysAdminUnit].[ContactId]
,[SysAdminUnit].[IsDirectoryEntry]
,[TimeZone].[Id] AS [TimeZoneId]
,[SysAdminUnit].[UserPassword]
,[SysAdminUnitType].[Id] AS [SysAdminUnitTypeId]
,[SysAdminUnit].[AccountId]
,[SysAdminUnit].[Active]
,[SysAdminUnit].[LoggedIn]
,[SysAdminUnit].[SynchronizeWithLDAP]
,[LDAPElement].[Name] as [LDAPEntry]
,[LDAPElement].[LDAPEntryId]
,[LDAPElement].[LDAPEntryDN]
,[SysAdminUnit].[SysCultureId]
,[SysAdminUnit].[ProcessListeners]
,[SysAdminUnit].[PasswordExpireDate]
,[SysAdminUnit].[HomePageId]
,[SysAdminUnit].[ConnectionType]
,[SysAdminUnit].[ForceChangePassword]
,[SysAdminUnit].[LDAPElementId]
,[SysAdminUnit].[BusinessSegmentId]
,[SysAdminUnit].[BusinessSegmentString]
FROM [SysAdminUnit]
INNER JOIN [SysAdminUnitType] ON [SysAdminUnitType].[Value] = [SysAdminUnit].[SysAdminUnitTypeValue]
LEFT JOIN [TimeZone] ON [TimeZone].[Code] = [SysAdminUnit].[TimeZoneId]
LEFT JOIN [LDAPElement] ON [LDAPElement].[Id] = [SysAdminUnit].[LDAPElementId]
GO
[/sql]
На уровне БД я вижу что нужные колонки (с требуемым именем и типом) появились и в таблице, и в представлении. В интерфейсе я вижу эти поля, вношу в них требуемую информацию. Жму сохранить, система говорит, что все ОК. Но когда я возвращаюсь к измененной мной записи, обнаруживаю, что поля пусты. В таблице SysAdminUnit в соответствующих полях также пусто. Механизм сохранения записей из раздела Орг структура использует конфигурационный веб-сервис AdministrationService, который задебажить у меня нет возможности. Единственно, что вижу, что в конфигурационный объект, передаваемый этому сервису, попадают изменения внесенные мной в эти кастомные поля на странице. Я, конечно, понимаю, что можно придумать обходной путь с updatequery прямо из клиентского модуля, но как-то это будет выглядеть как костыль.
Что касается вопроса наследования, поднятого Вами в предложенной теме, то пока не совсем понял что именно мне стоит проверить. Но вот, что могу сказать.
Объект VwSysAdminUnit в моем пакете замещает схему Пользователи/роли (представление) ( Base ). По этому заголовку в системе имеется ряд объектов, но все они находятся в разных пакетах (как я понял проблема именно, когда в одном пакете есть схемы с одинаковым заголовком??) То же относится и к SysAdminUNit (замещает Объект администрирования ( Base )) с SysAdminUnitPageV2 (замещает Схема страницы редактирования раздела "Организационные роли" ( UIv2 )) К сообщению прикрепляю скриншоты с найденными по заголовкам схемами, а также скриншот с прописанными зависимостями моего пакета.
Здравствуйте, Роман.
Спасибо за ответ. Я ознакомился с темой, которую вы предложили и не смог найти ответа на свой вопрос. Из темы также неясно решил ли автор все свои проблемы. Но те проблемы, которые он изначально поднял, я прошел. У меня поля добавлены в объекты SysAdminUnit и VwSysAdminUnt. Для View выполнен скрипт
[sql]
USE [BPMonline770]
GO
/****** Object: View [dbo].[VwSysAdminUnit] Script Date: 11.10.2016 21:01:55 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER VIEW [dbo].[VwSysAdminUnit]
AS
SELECT [SysAdminUnit].[Id]
,[SysAdminUnit].[CreatedOn]
,[SysAdminUnit].[CreatedById]
,[SysAdminUnit].[ModifiedOn]
,[SysAdminUnit].[ModifiedById]
,[SysAdminUnit].[Name]
,[SysAdminUnit].[Description]
,[SysAdminUnit].[ParentRoleId]
,[SysAdminUnit].[ContactId]
,[SysAdminUnit].[IsDirectoryEntry]
,[TimeZone].[Id] AS [TimeZoneId]
,[SysAdminUnit].[UserPassword]
,[SysAdminUnitType].[Id] AS [SysAdminUnitTypeId]
,[SysAdminUnit].[AccountId]
,[SysAdminUnit].[Active]
,[SysAdminUnit].[LoggedIn]
,[SysAdminUnit].[SynchronizeWithLDAP]
,[LDAPElement].[Name] as [LDAPEntry]
,[LDAPElement].[LDAPEntryId]
,[LDAPElement].[LDAPEntryDN]
,[SysAdminUnit].[SysCultureId]
,[SysAdminUnit].[ProcessListeners]
,[SysAdminUnit].[PasswordExpireDate]
,[SysAdminUnit].[HomePageId]
,[SysAdminUnit].[ConnectionType]
,[SysAdminUnit].[ForceChangePassword]
,[SysAdminUnit].[LDAPElementId]
,[SysAdminUnit].[BusinessSegmentId]
,[SysAdminUnit].[BusinessSegmentString]
FROM [SysAdminUnit]
INNER JOIN [SysAdminUnitType] ON [SysAdminUnitType].[Value] = [SysAdminUnit].[SysAdminUnitTypeValue]
LEFT JOIN [TimeZone] ON [TimeZone].[Code] = [SysAdminUnit].[TimeZoneId]
LEFT JOIN [LDAPElement] ON [LDAPElement].[Id] = [SysAdminUnit].[LDAPElementId]
GO
[/sql]
На уровне БД я вижу что нужные колонки (с требуемым именем и типом) появились и в таблице, и в представлении. В интерфейсе я вижу эти поля, вношу в них требуемую информацию. Жму сохранить, система говорит, что все ОК. Но когда я возвращаюсь к измененной мной записи, обнаруживаю, что поля пусты. В таблице SysAdminUnit в соответствующих полях также пусто. Механизм сохранения записей из раздела Орг структура использует конфигурационный веб-сервис AdministrationService, который задебажить у меня нет возможности. Единственно, что вижу, что в конфигурационный объект, передаваемый этому сервису, попадают изменения внесенные мной в эти кастомные поля на странице. Я, конечно, понимаю, что можно придумать обходной путь с updatequery прямо из клиентского модуля, но как-то это будет выглядеть как костыль.
Что касается вопроса наследования, поднятого Вами в предложенной теме, то пока не совсем понял что именно мне стоит проверить. Но вот, что могу сказать.
Объект VwSysAdminUnit в моем пакете замещает схему Пользователи/роли (представление) ( Base ). По этому заголовку в системе имеется ряд объектов, но все они находятся в разных пакетах (как я понял проблема именно, когда в одном пакете есть схемы с одинаковым заголовком??) То же относится и к SysAdminUNit (замещает Объект администрирования ( Base )) с SysAdminUnitPageV2 (замещает Схема страницы редактирования раздела "Организационные роли" ( UIv2 )) К сообщению прикрепляю скриншоты с найденными по заголовкам схемами, а также скриншот с прописанными зависимостями моего пакета.
"Орленко Андрей Николаевич" написал:AdministrationService
Вы можете почитать исходные коды AdministrationService, т.к. это схемы на уровне конфигурации. Более того, в случае необходимости Вы можете разблокировать и переписать под свои нужны.
Кстати, костыль с updatequery тоже не заработал. Возвращало ошибку, что пользователь не имеет права на объект SysAdminUnit. Пользователь был в роли Системные администраторы. Администрируемость объекта SysAdminUnit в системе выключена и на уровне объекта и в разделе администрирование
Коллеги, кому-нибудь удалось справиться с данной проблемой?
Добрый вечер, Сергей.
Предыдущие комментаторы не учли одну важную вещь - триггеры. Для корректной работы замещенной SysAdminUnitPageV2 нужно:
1) Заместить объект SysAdminUnit и добавить нужные поля.
2) Изменить в бд VwSysAdminUnit
3) Заместить объект VwSysAdminUnit и добавить поля (типы и имена должны совпадать).
4) Заместить SysAdminUnitPageV2
5) Изменить на уровне бд триггеры TRVwSysAdminUnitIU (апдейт VwSysAdminUnit) и VwSysAdminUnitI (инсерт).
Да, Илья, действительно изменение указанных тригеров помогло решить проблему. Жаль, что этой информации еще не было в октябре:smile: