Вы указали, что пользователь портала не видит писем в «Истории», это корректное поведение системы. В рамках базовой логики – портал самообслуживания не подразумевает общения письмами, в таком случае вообще портал самообслуживания теряет смысл. В системе реализована отдельная логика по работе с обращениями, происхождение у которых «Email». А пользователь, у которого есть портальные учетные данные – предполагается будет общаться с поддержкой и регистрировать обращения через портал.

Мы реализовывали раздачу прав пользователям портала на записи в БП. 

Ключевое здесь - это выдача прав на Activity по полученному письму. 

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

Владмир, спасибо за информацию. Жалко, что на скриншоте ничего не видно. Можно сделать дололнение для маркета.

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

Постараюсь реализовать, но сложно со временем пока что. В том процессе еще много добавлено. 

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

Владимир Соколов,

Владимир, подскажите, пожалуйста, как именно происходила раздача прав (настройка элемента процесса)? Требуется ли дополнительная настройка прав в разделе Администрирования: Доступ к объектам?

Если все права раздаёт процесс, то вручную менять не надо. Но лучше свяжитесь напрямую с Владимиром и уточните к него.

Здравствуйте, Сергей!

Суть изменений в том, что есть детали которые не администрируются по записям вообще и настраивать правила достаточно трудозатратно и не оправданно сложно. На текущий момент в версиях 7.11.3 данная фича по умолчанию выключена. Т.е. вне зависимости от заполненности поля поведение по проверке прав не изменится. 

Общая логика работы фичи такая: если по объекту выключено администрирование по записям и указан родительский объект, то при работе с записями вычитываются накладываются права на из родительского объекта. Никакого копирования прав не происходит, проверка на лету.



По  кейсу с ошибкой изменения адреса. Скорее всего дело вот в чем: при изменении записи адреса выполняется его синхронизация с основной записью контрагента (обновление в Контрагент основного адреса из детали Адреса для возможности удобной работы с этими данными в реестре Контрагенты). Т.к прав на изменение не хватает, то и изменение завершается с ошибкой.

Коллеги, подскажите, пожалуйста, где можно прочитать о данной функциональности? Не могу найти в Системе данный чекбокс.

Вот он:

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

Спасибо!!!!!

Интересная задача, но должна решаться стандартным БП, который запускается с определенной регулярностью, и в зависимости от времени перераспределяет права на dashboard

Я бы решил данную задачу создав Константные временные рамки. Привязал бы данный справочник к Сущности Дашбоард и далее При отображении Дашбоардов фильтровал какие показывать какие нет. Создание 1 нового Справочника, Создание ссылки. Доработка страниц по отрисовки и отображению Дашбоардов. Все. Более я не вижу других идей как быстрее сделать. Так как идти в сторону Прав это интересно. Но это больше времени по доработкам.

Добрый день, Алексей!

 

Если я даю человеку доступ, допустим на чтение, получит ли группа руководителей роли, в которую он входит такие же права?

Да, получит.

А если мне надо, чтобы руководители получили права с правом делегирования другому сотруднику, как тогда? 

В таком случае для нужной роли в правах администрирования по записям нужно чтоб в колонке "Уровень доступа" стоял доступ с правом делегирования (значек в виде ключика).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и т.д.

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

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

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

Я так думаю надо перенести права, которые раздаются по-умолчанию при создании записи. В таком случае вам в таблицу SysEntitySchemaRecordDefRight. 

Максим Цынгаев, да интересует как автоматизировать проставление дефолтных пермишнов по записям?.

Грубо говоря: Пользователи с ролью "Москва" должны видеть только записи созданные пользователями с ролью "Москва",

А пользователи с ролью "Санакт-Петербург" . должны видеть только записи созданные пользователями с ролью "Санакт-петербург"

И таких ролей у меня 30 штук, а права нужно раздать на 40+ объектов (разделов).

Как пример: Раздел "Обращения" я раздаю на него права доступа "Администрируется по записям"

И 30 раз проставляю:

Кто создает "Москва" кому дано право "Москва"

Кто создает "Санакт-Петербург" кому дано право "Санакт-Петербург"

и т.д.

Хотелось бы как-то это автоматизировать.

Варфоломеев Данила,большое спасибо помогли, добавить записи получилось. то что нужно

INSERT ... SELECT, думаю, будет оптимальным решением

доступ по операциям —> поиск по коду "CanManageLookup" —> добавляете пользователей

Ок, спасибо. Получилось

Варфоломеев Данила,

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

Данил. Вам стоит смотреть в сторону замещения метода initQueryFilters в разделе. Он будет фильтровать записи при загрузке раздела и физически снять его пользователи не смогут.

В лиде делать выбор не из объекта Контрагенты, а из объекта, построенного на VIEW (заодно и покажете только те поля, которые хотите показать).

Вообще все права валяются в Sys[#название объекта#]Right. И выбор в server studio в принципе делается 1 селектом. Если доступа к бд нет, то поможет sqlExecuter.

Если вы про раздел "SQL сценарии" в конфигураторе, то оттуда возможны только update/delete/create скрипты.

Данила, селект в Sys[#название объекта#]Right даст результат только если в таблице есть ссылка на конкретную запись объекта администрирования, в данном случае пользователя. Но если пользователь находится в организационной роли и права на запись предоставлены этой роли, то обычный селект по идентификатору пользователя не поможет. Так же обстоят дела со всеми вариантами наследования - если в его орг. роли есть функциональная роль и права на запись предоставлены функциональной роли, роли руководителей, которые наследуют все права подчиненных ролей и т.д. Скорее всего должна быть какая-то функция, которая запускается, когда пользователь переходит в раздел и ему отображаются все доступные записи с учетом наследования прав или когда пользователь пытается сохранить запись. 

Возможно кто-нибудь с этим сталкивался? 

На всякий случай - это процедура "GetOwnUserRoles"