Анастасия, если правильно Вас поняла, то речь идет о переносе доработок через SVN, а не полная подмена БД? Если да, то права и так не должны перезатиреться. Ну а в принципе, как на счет того, чтоб не переносить таблицы с правами? Или сделать бекап таблицы в базе данных и в случае чего просто через update вернуть как было.

Приветствую!

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

Способ 2. Прописать представляется возможным и в облаке. Для этого используйте создание sql запроса, который вы можете сотворить на закладке "SQL-скрипты" Вашего пользовательского пакета в настройках конфигурации. Вот только сам текст запроса попросите у коллег из поддержки. Я не уверен, что мой подойдет.

"Милова Марина Федоровна" написал:Решение облачное - 7.8.

Т.е прописать через базу данных не представляется возможным

По моему скромному мнению обработка прав доступа на уже проимпортированные данные это только написание курсоров для выполнения на sql сервере. И проблемы в том что это облако никакой нет.

Второй вопрос я бы честно говоря тоже решил написанием хранимой процедуры по особой раздаче прав, которую вызывал бы по событию сохранения записи объекта контрагент. Плюс справочник-развязку, который дает возможность связать группы пользователей и справочник регионов.

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

"Дмитрий Степанов" написал:Способ 1. Решали подобный кейс так, что сделали процесс с сигналом при записи нового контрагента и в нем манипулировали правами при импорте записей.

"Александр Кудряшов" написал:По моему скромному мнению обработка прав доступа на уже проимпортированные данные это только написание курсоров для выполнения на sql сервере. И проблемы в том что это облако никакой нет.

Коллеги, я правильно понимаю, что Пользовательским интерфейсом это никак не решить?

"Милова Марина Федоровна" написал:Коллеги, я правильно понимаю, что Пользовательским интерфейсом это никак не решить?

Кстати, я подобное решал - мы писали хранимку для правильной умной раздачи прав, а дальше просто вызываем ее курсором например - получаем первичную обработку, и добавляем вызов в код бп на сигнал сохранения записи. Так что решение второй задачи практически включает решение первой))

"Александр Кудряшов" написал:Для разработчика это задача на 3-6 часов - с подстраховкой на неполную постановку и неизвестные субд и объемы данных, не больше.

Саш, спасибо

Марина, в БП есть элемент для управления доступом (правами). Ну берем ответственного из файла импорта, смотрим, куда он относится в bpmonline и выставляем права. Но скажем так - если эта операция разовая (редкая), я бы запрос пускал.

"Дмитрий Степанов" написал:Ну берем ответственного из файла импорта, смотрим, куда он относится в bpmonline и выставляем права.

Есть единственное поле "Какому региону принадлежит клиент"
Только на него можно опираться пока

Коллеги, зачем нужен портал, если там невозможно получить ответ.
Что делать с клиентом?
Сказать, что помочь ему никто не может, даже техническая поддержка Террасофт.
Потому что
Цитата из технической поддержки Террасофта:

В данном инциденте решение предоставлятся не будет, так как вопрос и так уже рассматривается на нашем форуме. Ссылка на тему дана в предыдущем комментарии. Если у Вас остались какие-то не закрытые вопросы - Вы можете задать их в той же теме.

Марина, есть два пути - первый (системный) Вам рассказал коллега (с курсором), второй (процессный) расскащал Вам я. По нему еще раз. В дизайнере процессов есть элемент, управляюший правами. Как вы говорите, в исходном файле есть только регион. Добавьте параметр "Регион" или в группу пользователей или самому пользователю и настройте процесс так, чтобы при сохранении контрагента в доступ добавлялись все, которые к этому региону относятся.

"Дмитрий Степанов" написал:Добавьте параметр "Регион" или в группу пользователей или самому пользователю

Согласен пожалуй

Здравствуйте, Дмитрий!

Ниже замечания по реализованной Вами функции.

1. Вам не нужен датасет ds_Cashflow. Вы же в функцию уже передаете ID записи, откуда хотите копировать права (RecordID), и ID записи, куда хотите копировать (NewRecordID).
2. Перед открытием датасета ds_CashflowRight для установки фильтра используйте переменную RecordID:
ApplyDatasetFilter(CashflowRightDataset, 'RecordID', RecordID, true);
3. Вам нужен ещё один экземпляр датасета ds_CashflowRight, куда Вы будете добавлять нужные записи. Например, назовем его NewCashflowRightDataset.
var NewCashflowRightDataset = Services.GetNewItemByUSI('ds_CashflowRight');
4. Удалять записи из CashflowRightsDataset, действительно, не нужно.
5. В цикле while нужно реализовать такой код:
NewCashflowRightDataset.Append();
NewCashflowRightDataset('ID') = Connector.GenGUID();
NewCashflowRightDataset('RecordID') = NewRecordID;
NewCashflowRightDataset('CanRead') = DocumentRightsDataset('CanRead');
NewCashflowRightDataset('CanWrite') = DocumentRightsDataset('CanWrite');
NewCashflowRightDataset('CanDelete') = DocumentRightsDataset('CanDelete');
NewCashflowRightDataset('CanChangeAccess') = DocumentRightsDataset('CanChangeAccess');
NewCashflowRightDataset.Post();
DocumentRightsDataset.GotoNext();
6. То, что ниже while не нужно. После цикла нужно закрыть оба датасета.

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

Спасибо Вам большое! Сейчас буду пробовать. По умолчанию не подойдет, поскольку в разных операциях разные пользователи с разными правами

Копирование прав работает, но есть маленький нюанс:

Не подскажете как исправить? :)

Нужно в код, где Вы копируете права добавить ещё такую строчку:

NewCashflowRightDataset('AdminUnitID') = DocumentRightsDataset('AdminUnitID');

Cпасибо! Все работает.

А не подскажете еще каким способом можно удалить пользователей по умолчанию. Поскольку они добавляются после копирования.

Можно написать запрос на удаление, который будет удалять не нужные записи

Реализовал след. образом:

function CopyRight(RecordID, NewRecordID) {
 
//debugger;
 
 
	var CashflowRightDataset = Services.GetNewItemByUSI('ds_CashflowRight');
	ApplyDatasetFilter(CashflowRightDataset, 'RecordID', RecordID, true);
	var NewCashflowRightDataset = Services.GetNewItemByUSI('ds_CashflowRight');
	ApplyDatasetFilter(NewCashflowRightDataset, 'RecordID', NewRecordID, true);           
	NewCashflowRightDataset.Open();
	NewCashflowRightDataset.GotoFirst();
	//Чистим датасет от прав по умолчанию
                while(!NewCashflowRightDataset.IsEOF)
                {
                        NewCashflowRightDataset.Delete();
                }
    NewCashflowRightDataset.Close();
    NewCashflowRightDataset.Open();
	CashflowRightDataset.Open();
	CashflowRightDataset.GotoFirst();
	while(!CashflowRightDataset.IsEOF)
	{
		NewCashflowRightDataset.Append();
		NewCashflowRightDataset('ID') = Connector.GenGUID();
		NewCashflowRightDataset('RecordID') = NewRecordID;
		NewCashflowRightDataset('CanRead') = CashflowRightDataset('CanRead');
		NewCashflowRightDataset('CanWrite') = CashflowRightDataset('CanWrite');
		NewCashflowRightDataset('CanDelete') = CashflowRightDataset('CanDelete');
		NewCashflowRightDataset('CanChangeAccess') = CashflowRightDataset('CanChangeAccess');
		NewCashflowRightDataset('AdminUnitID') = CashflowRightDataset('AdminUnitID');
		NewCashflowRightDataset.Post();
		CashflowRightDataset.GotoNext();
	}
	CashflowRightDataset.Close();
	NewCashflowRightDataset.Close();
}

Здравствуйте, Дмитрий!

В Вашем коде есть ошибка.

Чтобы удалить все записи нужно после NewCashflowRightDataset.Delete(); выполнить NewCashflowRightDataset.GotoNext().

И ещё после цикла, где идет удаление закрывать не нужно. Эта строка лишняя:
NewCashflowRightDataset.Close();

Спасибо, сейчас подправлю :)

Здравствуйте,

поля ID, CreatedOn, CreatedByID заполняются автоматически в момент создания записи, а поля ModifiedOn, ModifiedByID заполняются в момент изменения записи.

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

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

Пример:

function wnd_AccountsGridAreaOnPrepare(Window) {
	wnd_BaseGridAreaOnPrepare(Window);
	Initialize(Window);
 
	var IsVisibleGV = false;
	if (Ваше условие) {
		IsVisibleGV = true;
	}
	gvMyAccounts.IsVisibel = IsVisibleGV;
	gvAll.IsVisibel = !IsVisibleGV;
}

Спасибо, Павел.
Что-то я проглядел, что у представлений есть свойство видимости.

_

Антон, попробуйте в объекте установить птичку "Администрируется по записям". После ее установки должна появиться указанная таблица ("dbo.SysPurchasingVisaRight)

Александр, Ваше решение работает, отлично. Большое спасибо!

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

Подскажите как добавить роль, которая не будет входить в "Все сотрудники компании"? И почему у меня может не быть возможности добавить роль в группу "Все пользователя портала"? Кнопки добавить организацию/подразделение не доступны (даже Supervisor'у).

Роль "Все сотрудники компании" является родительской, все остальные подчиненные. Но это не значит, что права будут применяться для всех сотрудников, если настраиваете их для определенной роли. Вы можете раздавать права нужной Вам роли, при этом это никак не отразится на роли "Все сотрудники компании". Что касается роли "Все пользователи портала", то данная роль работает только в продуктах линейки Service, так как портал есть только там.
Для большего понимания настройки прав доступа в системе рекомендую посмотреть видеоролик: https://www.youtube.com/watch?v=x5C6VcOhKj4&feature=youtu.be&list=PLDp-…

"Сафонов Олег" написал:Подскажите как добавить роль, которая не будет входить в "Все сотрудники компании"? И почему у меня может не быть возможности добавить роль в группу "Все пользователя портала"? Кнопки добавить организацию/подразделение не доступны (даже Supervisor'у).

В портальных пользователях иерархия вообще отключена, поэтому добавить туда дочернюю группу не выйдет. Насколько мне известно, включение структуры портальных пользователей произовйдёт в одном из будущих релизов bpm'online.

Настраивал права и для подчиненной роли, входящей в "Все сотрудники компании", и на одном уровне со всеми сотрудниками (инсертом). Если открыть Действия - Настроить права доступа на карточке - там нету группы, для которой были настроены права, но записи все-равно видны.
Роли актуализировал. Галочка "Администрируется по записям" стоит.

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

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

"Адасюк Валерий Викторович" написал:

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

Прикрепленный файлРазмер

skripty.zip
2.47 кб

Олег, данная ситуация требует индивидуального рассмотрения. Предлагаю перенести рассмотрение данного вопроса в рамках отдела технической поддержки, с последующим подключением к Вашему сайту. Напишите на адрес support@terrasoft.ru какие права, какой группе и на какой раздел нужно раздать, а также ссылку на сайт, о котором идет речь.

Здравствуйте! Интересует такой вопрос. Я сосдал учетную запись для Бухгалтера и в администрировании доступа к обекту выдал ему права на чтение Кто создает: Все сотрудники компании.
В итоге он начал видеть счета которые создаются после того как это правило создалось. Но мне нужно чтобы он видел и счета которые были раньше создани, а не только начиная с сегодня 16-30. Можна ли както сделать чтобы бухгалтер смог видеть счета например с 01.07.2016 не выдавая ему админские права на доступ.

Николай, добрый день.

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

https://academy.terrasoft.ru/documents/sales-enterprise/7-8-0/detal-dos…

Для того, чтобы распространить права на существующие записи, есть несколько вариантов:

1) Запрос в БД - решается при помощи написания SQL-запроса
2) БП - бизнес-процесс, в котором есть элемент "Изменение прав доступа".

Детальнее о правах доступа Вы можете узнать здесь - https://www.youtube.com/watch?v=x5C6VcOhKj4&feature=youtu.be&list=PLDp-…

Владимир, здравствуйте!

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

Здравствуйте!

Процессом не получится. Давайте рассмотрим на Вашем примере. Предположим объект "Контрагент" администрируется по записям. Вся информация о правах хранится в таблице SysAccountRights.

Для реализации Вашей задачи Вам необходимо включить администрирование по записям для объекта "Средство связи контрагента".

Далее, Вам необходимо на событие "после сохранения записи" (процесс на объекте) либо на событие "после добавления записи"/"после изменения записи" создать бизнес процесс, который:

1) Удалит данные из таблицы SysAccountCommunicationRights для записей из таблицы AccountCommunication, у которых в поле AccountId содержится Id добавленной/измененной записи
2) Скопирует права из таблицы SysAccountRights для измененной/созданной записи в таблицу SysAccountCommunicationRights.

Элементом "Изменить права доступа" решить данную задачу не получится.

"Демьяник Алексей" написал:1) Удалит данные из таблицы SysAccountCommunicationRights для записей из таблицы AccountCommunication, у которых в поле AccountId содержится Id добавленной/измененной записи
2) Скопирует права из таблицы SysAccountRights для измененной/созданной записи в таблицу SysAccountCommunicationRights.

Как я понимаю, эти таблицы в AddData и DeleteData недоступны, и необходимо писать скриптом это всё? Может, есть готовый пример? Не верю, что ни у кого не возникало такой задачи.

И еще вопрос - как отследить, что изменились права на запись Контрагента, если это сделано вручную через Actions / Set up access rights? Чтобы сразу же изменить на подчиненные детали

Добрый день!

Раздавать права следует скриптом. Пример можно посмотреть в схеме RightsHelper (методы GetRecordRights, SetRecordRight).
Отследить изменение прав доступа в Account можно используя триггер в базе данных, при помощи sql запроса изменить права доступа на запись в детали.

Пример триггеров, на которых реализовали данную логику:

ALTER TRIGGER [dbo].[SysAccountRight_AI]
ON [dbo].[SysAccountRight]
AFTER INSERT
AS 
BEGIN
SET NOCOUNT ON;
DECLARE @SysAdminUnitId UNIQUEIDENTIFIER
SELECT @SysAdminUnitId = SysAdminUnitId FROM inserted
INSERT INTO [dbo].[SysAccountAddressRight]
( 
[RecordId]
,[SysAdminUnitId]
,[Operation]
,[RightLevel]
,[Position]
,[SourceId])
SELECT [det].[Id], [mast].[SysAdminUnitId], [mast].[Operation], [mast].[RightLevel], [mast].[Position], [mast].[SourceId] 
FROM [SysAccountRight] as [mast]
JOIN [AccountAddress] AS [det] ON [det].[AccountId] = [mast].[RecordId]
WHERE [mast].[SysAdminUnitId] = @SysAdminUnitId
INSERT INTO [dbo].[SysAccountBillingInfoRight]
( 
[RecordId]
,[SysAdminUnitId]
,[Operation]
,[RightLevel]
,[Position]
,[SourceId])
SELECT [det].[Id], [mast].[SysAdminUnitId], [mast].[Operation], [mast].[RightLevel], [mast].[Position], [mast].[SourceId] 
FROM [SysAccountRight] as [mast]
JOIN [AccountBillingInfo] AS [det] ON [det].[AccountId] = [mast].[RecordId]	
WHERE [mast].[SysAdminUnitId] = @SysAdminUnitId
END

ALTER TRIGGER [dbo].[SysAccountRight_FD]
ON [dbo].[SysAccountRight]
FOR DELETE
AS
BEGIN
SET NOCOUNT ON;
DECLARE @AccountID UNIQUEIDENTIFIER
DECLARE @SysAdminUnitUD UNIQUEIDENTIFIER
DECLARE @Operation INT
SELECT @AccountID = [RecordId] FROM deleted
SELECT @SysAdminUnitUD UNIQUEIDENTIFIER
SELECT @Operation = [Operation] FROM deleted
SELECT @SysAdminUnitUD = [SysAdminUnitId] FROM deleted
DELETE
FROM [dbo].[SysAccountAddressRight]
WHERE [RecordId] IN (SELECT [det].[Id]
FROM [AccountAddress] AS [det]
WHERE [det].[AccountId] = @AccountID)
AND [Operation] = @Operation AND [SysAdminUnitId] = @SysAdminUnitUD
DELETE
FROM [dbo].[SysAccountBillingInfoRight]
WHERE [RecordId] IN (SELECT [det].[Id]
FROM [AccountBillingInfo] AS [det]
WHERE [det].[AccountId] = @AccountID)
AND [Operation] = @Operation AND [SysAdminUnitId] = @SysAdminUnitUD
END

ALTER TRIGGER [dbo].[AccountAddress_AI]
ON [dbo].[AccountAddress]
AFTER INSERT
AS 
BEGIN
SET NOCOUNT ON;
DECLARE @RecordId UNIQUEIDENTIFIER
SELECT @RecordId = Id FROM inserted
DECLARE @SysAdminUnitId UNIQUEIDENTIFIER
SELECT @SysAdminUnitId = Id FROM SysAdminUnit WHERE ContactId = (select CreatedById FROM inserted)
INSERT INTO [dbo].[SysAccountAddressRight]
( 
[RecordId]
,[SysAdminUnitId]
,[Operation]
,[RightLevel]
,[Position]
,[SourceId])
SELECT [mast].[Id], [det].[SysAdminUnitId], [det].[Operation], [det].[RightLevel], [det].[Position], [det].[SourceId] 
FROM [AccountAddress] AS [mast]
JOIN [SysAccountRight] AS [det] ON [det].[RecordId] = [mast].[AccountId]
WHERE [det].[SysAdminUnitId] <> @SysAdminUnitId AND [mast].[Id] = @RecordId
END

Владимир, пользователи портала, существенно ограничены в правах, для них нельзя добавлять группы пользователь. Лично я вижу два выхода
1. Создать бизнес-процесс, которые будет добавлять права кроме создателя еще и его супервизору, но если супервизор измениться, то придется менять процесс, либо как-то организовываться в плане справочника.
2. Либо раздавать права скриптом, создать триггер, чтоб он проверял новосозданные обращения, и добавлял права супервизору, тогда при изменениях придется модифицировать триггер.