Права доступа на уровне записей

[tischenko]

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

[YellowSubmarine]

Создать группы пользователей = количеству пользователей и для каждой группы (фактически для каждого пользователя) настроить права доступа на уровне записей.

[Hamster]

Можно попробовать настроить RLS для поля createdBy.

Но
1) Настраивать придется для каждого пользователя
2) Не факт что это поле доступно для RLS
3) Не все таблицы имеют это поле (атрибут createdby)

Вариант 2 (для маньяков программеров):
можно создать в таблице поле, куда при создании записывается код группы пользователя и настраивать по нему

[tischenko]

Это я уже понял.

А есть ли возможность в аксапте в запросной форме в качестве критерия функцию подставить? Типа взять поле createdby а в качестве критерия curuserid() ?

[Hamster]

нет

[Maxim Gorbunov]

Quote:

Изначально опубликовано Hamster
Вариант 2 (для маньяков программеров):

Вообще-то, есть поле SalesTable.SalesTaker. Скорее всего, оно вполне удовлетворит требованиям.

2tischenko: В данном случае лучше, видимо, не заморачиваться с RLS. Добавьте отдельный параметр в модуле "Расчеты с клиентами", чтобы указывать группу пользователей, которым доступны все заказы. В init() DataSource SalesTable добавьте в query скрытый Range.

PHP Code:

if (!UserInfoHelp::userInUserGroup(curUserId(), mySuperuserGroup)) {
    queryBuildRange = this.query()
        .dataSourceTable(tableNum(SalesTable)
        .addRange(fieldNum(SalesTable, SalesTaker)); // или createdBy
    queryBuildRange.value(curUserId());
    queryBuildRange.status(RangeStatus::Hidden);
} 


[rus_stas]

Quote:

Изначально опубликовано Hamster
Вариант 2 (для маньяков программеров):
можно создать в таблице поле, куда при создании записывается код группы пользователя и настраивать по нему

Зачем программировать, если можно использовать поле Получатель (вкладка Настройки шапки заказа) и по этому полю настроить RLS.

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

[Hamster]

Невнимательно читал пост.... пропустил что это "заказы"


P.S
А теперь, когда вы все настроили, злобный юзер Петров взял и сменил SalesTaker на Иванова......

[Maxim Gorbunov]

Quote:

Изначально опубликовано Hamster
А теперь, когда вы все настроили, злобный юзер Петров взял и сменил SalesTaker на Иванова......

А для этого есть настройка прав доступа на поля таблицы.

[rus_stas]

А Максим меня всегда опережает с ответом

[tischenko]

Спасибо это помогло

if (UserInfoHelp::userInUserGroup(curUserId(), 'aaaa'))
{
q1 = new query();
qbr = q1.addDataSource(tableNum(SalesTable)).addRange(fieldNum(SalesTable, createdBy));
qbr.value(curUserId());
qbr.status(RangeStatus::Hidden);
this.query(q1);
}

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

Спасибо за внимание

[mazzy]

Quote:

Изначально опубликовано tischenko
Спасибо это помогло

не обольщайтесь
здесь известные проблемы подобного подхода
http://axapta.mazzy.ru/works/accessrecord/#knownproblem

[Maxim Gorbunov]

Ни в коем случае так не делайте. Вы создаете Query, затирая им стандартный. У вас не будет правильно работать переход к основной таблице (к таблице "Заказы").

Обратите внимание на то, что в том коде, который я писал раньше, Query не создается заново. Модифицируется уже созданный query.

[Maxim Gorbunov]

Quote:

Изначально опубликовано mazzy
не обольщайтесь
здесь известные проблемы подобного подхода
http://axapta.mazzy.ru/works/accessrecord/#knownproblem

А вот и нет. Такие проблемы возникнут только в том случае, если оставить для критерия RangeStatus::Open. Если ставить RangeStatus::Hidden или RangeStatus::Locked, пользователь не сможет добавить фильтры по тому же самому полю. Соответственно, описанной проблемы не возникнет.

[mazzy]

Quote:

Изначально опубликовано Maxim Gorbunov
А вот и нет. Такие проблемы возникнут только в том случае, если оставить для критерия RangeStatus::Open. Если ставить RangeStatus::Hidden или RangeStatus::Locked, пользователь не сможет добавить фильтры по тому же самому полю. Соответственно, описанной проблемы не возникнет.

Оба на! Здорово. И это поправили в 3.0...

Спасибо тебе, добрый фей.

[Wamr]

Quote:

Изначально опубликовано mazzy

Оба на! Здорово. И это поправили в 3.0...

Спасибо тебе, добрый фей.

Не обольщайтесь!
В "ограниченном" поле сделайте поиск записи "значение1, значение2". А теперь откройте фильтр...
--------
Забыл важный момент - искать надо 2 раза

[mazzy]

Quote:

Изначально опубликовано Wamr
Не обольщайтесь!

И тебе, добрый фей, спасибо.

Черт, ну почему так, а?!

[Maxim Gorbunov]

Wamr, спасибо за Ваш ответ! Давно не испытывал такого азарта, при поиске решения.

Действительно, против лома нет приема Как известно, у поговорки еще и окончание есть

Вот небольшая модификация класса SysSetupFormRun (немного изменен метод task()). После импорта этого проекта, поиск по полям, входящим в Locked или Hidden диапазоны, осуществляться не будет (будет заблокирован для этих полей).

[mazzy]

Перенесу-ка я в проекты.
Спасибо огромное.

[Maxim Gorbunov]

Как обычно сделал, а потом подумал

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

Таким образом, первоначальная задача (фильтрация списка заказов) была бы полностью решена, если в init'е кроме добавления нового range добавить еще и скрытие элементов дизайна, связанных с этим полем.