Доброго времени суток!

Подскажите, пожалуйста, как при администрировании доступа к записям раздела сделать так, чтобы у пользователей определенной организационной роли не было доступа ни к одной записи раздела без потери доступа в этот раздел?

Нравится

7 комментариев

Сделайте бизнес процесс, который при создании записи будет забирать права на запись у нужной роли. 

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

а как быть со старыми записями?

А для старых - отдельный разовый бизнес-процесс, который пройдется по всем записям и перераздаст права.

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

Достаточно ресурсоемко, если учитывать, что в системе около 4 млн. записей. При запуске элемента для настройки прав доступа получаю такую ошибку: "Превышено ограничение 200000 записей при выгрузке данных объекта". Как можно ее обойти? Как-то зациклить элемент БП?

P.s. нашел данную статью: https://community.terrasoft.ru/questions/snyat-ogranichenie-na-koliches… с подобной ошибкой. Но данное решение кажется радикальным. На прод среде недопустимо запускать БП на 4 млн записей. Какие могут быть обходные пути?

Ну вообще можно сделать циклами через порционную вычитку данных. Но может быть вам будет проще выделить все записи через Действия -> Выбрать все и Настроить права доступа? Я попробовал - у меня 400к записей выделилось. 

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

Арнур Келгенбаев,

Или вот эту штуку можно посмотреть 

https://marketplace.terrasoft.ua/app/access-rights-setup-wizard-creatio

Арнур Келгенбаев пишет:

Достаточно ресурсоемко, если учитывать, что в системе около 4 млн. записей. При запуске элемента для настройки прав доступа получаю такую ошибку: "Превышено ограничение 200000 записей при выгрузке данных объекта". Как можно ее обойти? Как-то зациклить элемент БП?

Сделайте в SQL работу с правами. Те же самые таблицы, однотипное добавление и удаление. Работает в разы быстрее

Показать все комментарии

Доброго времени суток!

В управлении конфигурацией во вкладке "Администрирование: доступ к объектам" для раздела "Контакт" хочу настроить права доступа всем пользователям с организационной ролью "Консультанты". Во вкладке "Доступ к объекту" есть только одно правило для роли "Консультанты" с разрешением на чтение записей, во вкладке "Доступ к записям по умолчанию: чтение" тоже всего одно правило для чтения записей, созданных всеми сотрудниками, для "Консультантов". Вне зависимости от наличия правила доступа во вкладке "Доступ к записям по умолчанию: чтение" консультант видит 236 записей. Если прогнать БП, который дает права доступа для записей, за которыми числится ответственным консультант (их в системе 2 тестовые записи), то в разделе "Контакты" консультант будет видеть 238 записей. Я хочу разобраться, по какому принципу система отображает эти 236 записей. Подскажите, пожалуйста, в чем может быть причина? Для сведения, в системе свыше 3 млн контактов. Как можно найти признак, который объединяет эти записи?

Изображение удалено.

Нравится

1 комментарий

Добрый день!

Насколько я понимаю, вопрос в том, почему при розданных правах консультант видит 236 записей, а если создать 2 тестовых, в которых ответственным назначить консультанта, и прогнать БП, который раздает права - консультант будет видеть 238 записей?



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

Судя по большому количеству записей данного раздела в вашей системе - можно предположить, что они были импортированы через Excel или путем обогащения данных. В таком случае есть вероятность, что это и вызывает конфликт. Т.к. импортированные записи могут не совпадать с признаком "созданная сотрудником".

Если это поможет, консультант должен видеть ~ 3млн контактов, верно?

Показать все комментарии

Были настроены права по записям.

После чего были импортированы сами записи в систему. Итог их никто кроме админа не видит.

Пробовал менять поле "Кто создал" и ставить туда пользователя с нужными ролями, все равно никто ничего не видит.

Нравится

5 комментариев

Тут так: если у вас система более-менее свежая, тогда права расставятся по ответственному (должно хватить по идее) - добавьте в исходник поле "Ответственый" и из него грузите в поле "Ответственный" системы. Автора можете ставить любого, все равно будет считаться тот, кто импортировал. Мы первый раз решали процессом, которым правили при сохранении по условию права (но есть потенциальный дедлок), либо запросом на правку прав до дефолтного состояния уже после импорта (есть такой у поддержки, дают по запросу пользователя). Запрос к сожалению Вам изменит все права, в том числе и настроенные вручную в записи, наприме. Если же не свежая, тогда и у владельца права не появятся и тут только запросом или процессом при сохранении.

Дмитрий Степанов,

версия свежая.

Ваш совет в целом помог.

Но происходит теперь другая ситуация.

Что я импортирую записи, и их видят все. То есть по ролям не разбиваются.

Делаю импорт в 8 заходов, для каждой роли совой импорт.

Но  в итоге все видят все

А вот это уже точно проблема Вашей настройки прав. Ответственный видит свое, его менеджер видит все своего подразделения (если используется). Вы руками создайте запись с тем же ответственным и увидите, что будет. Я так понимаю, что там с иерархией прав у вас беда-беда ибо для ответственного вы там особо ничего не настроите. 

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

А права у меня все вида

Москва видит Москву

Питер видит Питер

и т.д.

Нет ролей которые видят все

 

Картинку настройки доступа к объектам в студию.

Показать все комментарии

Доброго времени суток, коллеги!
Извиняюсь, если вопрос бородатый, но беглый пробег по имеющимся темам мне не помог.
Нужно группе пользователей скрыть обязательное поле "Приоритет" в карточке инцидента. Чтобы они его вообще не видели и туда проставлялось значение по-умолчанию. Если в "правах доступа к полям" запрещаю доступ к этому полю, или оставляю только "чтение", то при создании инцидента не проставляется значение по-умолчанию, и, соответственно, не проходит сохранение.
Или запретить этой группе видеть варианты приоритетов, которые им нельзя видеть. Подобное, видимо, поднимается здесь https://community.terrasoft.ru/forum/topic/9503 . Но, возможно, просто прикрыть видимость проще будет?

Нравится

12 комментариев

Если при настройке прав вас всё устраивает, кроме значения по умолчанию, можно убрать обязательность, а значение проставлять на уровне триггера в БД.

Как вариант.
А может есть механизм просто сокрытия видимости соответствующего контрола на форме? И пусть оно там втихаря штатным механизмом проставляет значение по-умолчанию, проверяет это поле на обязательность и т.п.
Дело в том, что решение нужно временное: пока не выдрессировал манагеров правильно оценивать приоритетность, все лепят максимальный уровень, чтобы пролезть вне очереди :)

Если важно скрыть видимость только на карточке, можно просто скриптом на событие OnPrepare. Но тогда особо хитрые смогут посмотреть в гриде. Вам же не страшно, что посмотрят, только бы не меняли?

Верно, смотреть не жалко. Лишь бы поменять не могли.
Спасибо, через скрипт и сделаю.

Здравстуйте, Андрей!
Можно устанавливать свойство поля "IsVisible" в false при инициализации страницы в зависимости от текущего пользователя. Информацию о текущем пользователе можно получить из Connector.CurrentUser. Например:

if (Connector.CurrentUser.ContactName == "Василий")
{
       Self.ComponentsByName('edtName').IsVisible = false;
}

Что не правильно в таком варианте:

function wnd_IncidentEditOnPrepare(Window) {
.......
.......
.......
/* Сокрытие поля Приоритет от манагеров*/ 
	// получение ID группы
	var GroupID = Dataset.Values('OwnerGroupID');
	edtPriority.isVisible = (GroupID != '07744A4C-D95D-4A74-8861-B0F217654691') 
	//07744A4C-D95D-4A74-8861-B0F217654691 манагеры
	//4404B91C-F17E-4308-8726-4B3C602EA20B манагеры регионы

не падает, но и не работает. ID групп получил из sq_Group

Странное получение id группы. Пользователь может ходить в несколько групп. Я бы как-то так написал:

function UserHasGroup(UserID, GroupID) {
	var UserInGroup = Services.GetNewItemByUSI('ds_UserInGroup');
	UserInGroup.Close();
	ApplyDatasetFilter(UserInGroup, 'UserID', UserID, true);
	ApplyDatasetFilter(UserInGroup, 'GroupID', GroupID, true);
	UserInGroup.Open();
	if (UserInGroup.RecordsCount == 0) return false;
	return true;
}
 
function wnd_IncidentEditOnPrepare(Window) {
.......
.......
.......
/* Сокрытие поля Приоритет от манагеров*/ 
        edtPriority.IsVisible = !UserHasGroup(Connector.CurrentUser.ID, '07744A4C-D95D-4A74-8861-B0F217654691');
        //07744A4C-D95D-4A74-8861-B0F217654691 манагеры
        //4404B91C-F17E-4308-8726-4B3C602EA20B манагеры регионы

получение группы стырено из функции edtOwnerIDOnPrepareSelectWindow(LookupDataControl), буквально двумя строчками ниже. Правда, возможно там другие цели преследовались. Не подумал о вероятности нахождения в нескольких группах.
Вариант Александра меня полностью осчастливил.

Предположу, что можно поставить галочку в sq_ сервесе всегда выбирать в запросе. Если исчезает(полностью) элемент с формы который связан с полем, то поле в DataSet больше не выбирается.

Михаил, Вы правы, галка нужна.

"Борисов Михаил Евгеньевич" написал:

Предположу, что можно поставить галочку в sq_ сервесе всегда выбирать в запросе. Если исчезает(полностью) элемент с формы который связан с полем, то поле в DataSet больше не выбирается.


Можно подробнее про это?
У меня элемент формы не удаляется, а просто скрывается от шаловливых ручек, причём уже после того, как прошли все выборки. Можно было бы даже не скрыть полностью, а просто сделать его неактивным, чтобы пользователи визуально привыкали к правильному значению.

Здравствуйте, Андрей!
Загрузка необходимых полей происходит в ядре. Если просто скрыть колонку, то значение должно загружаться.
Если поля нет на карточке, то для загрузки значения может понадобится установить обязательность загрузки в sq.

Показать все комментарии

Задача:
Разделение права доступа на записи в справочнике Валют
Вводная:
Есть много офисов компании, например Московскому офису совершенно не интересно каждый раз выбирать валюту UAH, DKK и.т.д. следовательно логично разграничить доступ на валюты

Решение:
1. tbl_Currency -> поставить галочку Is Administrated By Records
2. wnd_CurrencyDictionary
a) Добавить pgAccessDetail
б) wndAccessDetail -> Window = wnd_AccessGridArea
в) Pages -> определить событие PagesOnChangeActivePage

3.wnd_CurrencyDictionaryScript
a) Use Scripts -> scr_WorkspaceUtils
Код самого скрипта нужно поменять следующим образом :

//------------------------------------------------------------------------------
// wnd_CurrencyDictionaryScript
//------------------------------------------------------------------------------

var CurrencyDictionary = new Object();
var BaseWorkspace = new Object();

function InitializeGridData() {
        CurrencyDictionary.CurrencyWindow = wndCurrency.Window;
        CurrencyDictionary.CurrencyWindow.Prepare();   
}

function InitializeCurrencyRateDetail() {
        CurrencyDictionary.CurrencyRateWindow = wndCurrencyRateDetail.Window;
        CurrencyDictionary.CurrencyRateWindow.Prepare();
}

function InitializeGlobalVariables() {
        CurrencyDictionary.CurrencyDataset = GetDatasetFromWindow(
                CurrencyDictionary.CurrencyWindow, DefDatasetLinkName);
        CurrencyDictionary.CurrencyRateDataset = GetDatasetFromWindow(
                CurrencyDictionary.CurrencyRateWindow, DefDatasetLinkName);
}

function InitializeGlobalDatalinks() {
        dlCurrency.Dataset = CurrencyDictionary.CurrencyDataset;
        dlCurrencyRate.Dataset = CurrencyDictionary.CurrencyRateDataset;
}

function OpenCurrencyDataset() {
        CurrencyDictionary.CurrencyDataset.Open();
}

function Initialize(Window) {
        InitializeGridData();
        InitializeCurrencyRateDetail();
        InitializeGlobalVariables();
        InitializeGlobalDatalinks();
        OpenCurrencyDataset();
}

function RefreshCurrencyRate() {
    CurrencyDictionary.CurrencyDataset.Open();
        var CurrencyID = CurrencyDictionary.CurrencyDataset.Values('ID');
        if (CurrencyID == null) {
                return;
        }
        SetAttribute(CurrencyDictionary.CurrencyRateWindow, 'ParentItemID',
                CurrencyID);
        RefreshDetailData(CurrencyDictionary.CurrencyDataset, 'ID',
                CurrencyDictionary.CurrencyRateDataset, 'CurrencyID');
}

// ----------------------------------------------------------------------------
// Event handlers
// ----------------------------------------------------------------------------

function wnd_CurrencyDictionaryOnPrepare(Window) {
        Initialize(Window);
}

function dlCurrencyOnDatasetAfterOpen(Dataset) {
//      RefreshCurrencyRate();
RefreshDetails()
}

function dlCurrencyOnDatasetAfterPositionChange(Dataset) {
//      RefreshCurrencyRate();
RefreshDetails()
}

function dlCurrencyOnDatasetRefreshRecord(Dataset, KeyValue, AddNewRecordOnPage) {
        if (AddNewRecordOnPage) {
//              RefreshCurrencyRate();
        RefreshDetails()
        }
}

function wnd_CurrencyDictionaryOnNotify(ScriptableService, Sender, Message, Data) {
        if (Message == MSG_CLOSE) {
                CloseWindow(Self);
        }
}


function PagesOnChangeActivePage(Pages) {
        RefreshDetails();
}

function RefreshDetails() {
        if (Pages.ActivePage.Name == pgCurrencyRate.Name) {
                RefreshCurrencyRate();
        } else
        if (Pages.ActivePage.Name == pgAccessDetail.Name) {

        //26.06 Create BaseWorkspace
        var Grid = wndCurrency.Window.ComponentsByName('grdData');     
        BaseWorkspace.GridDataset = CurrencyDictionary.CurrencyDataset;
        BaseWorkspace.Grid = Grid

        RefreshAccessDetail(BaseWorkspace, wndAccessDetail, 'tbl_CurrencyRight');
        }
}

Нравится

5 комментариев

Мне кажется, как раз не логично решать задачу доступом - если Московскому офису все-таки понадобятся закрытые от них валюты?
Имхо лучше сделать какую-нибудь детальку типа CurrencyInDepartment и фильтровать справочник валют по данным оттуда. Хотя, такая реализация немного сложнее

Дмитрий совсем Вас не понял. Права доступа разделяются на группы All Users -> Moscow -> Managers Moscow, All Users -> Moscow -> Accountant Moscow и.т.д. и как раз на группы и раздаются права.
При таком подходе Московский офис не видит не нужные им валюты, а если например бухгалтеру необходимо видеть что то дополнительно, ему раздаются права доступа (на группу Accountant Moscow)

А то что вы предлагаете очень лихо в силу того что Валюты - это очень базовый справочник

"Яворский Алексей" написал: то что вы предлагаете очень лихо в силу того что Валюты - это очень базовый справочник

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

Даже проще можно сделать:
*добавить таблицу CurrencyInUser
*в датасет справочника валют добавить булево поле подзапроса "Показывать мне"

(select 
....
(select ShowForMe from tbl_CurrencyInUser where CurrencyID = tbl_Currency.ID and UserID = :CurrentUserContactID)
....
from tbl_Currency)

*создать логику автозаполнения tbl_CurrencyInUser при создании нового пользователя и валюты
*наложить на датасет валют фильтр where ShowForMe = 1
*для грида справочника отключать фильтр

Алексей, спасибо за пример реализации. Так держать! :)

Показать все комментарии