Разграничение прав доступа к записям таблицы

[mdconsult]

Здравствуйте.
Есть такая задача. Необходимо настроить права доступа пользователей таким бразом чтобы видеть пользователи могли все записи. А редактировать только те, которые были созданы конкретным пользователем. Конкретно речь идет о таблице клиентов. Менеджеры будут видеть всех клиентов. Но вносить изменения должны иметь возможность только в карточки своих клиентов ( у которых они проставлены как "ответственные").
Не очень понимаю как это сделать.
Можно настроить для каждого пользователя свою группу чтобы он видел и редактировал только своих. А вот как сделать чтобы он видел и остальных, но не редактировал?

Прошу прощения, если тема уже была на форуме. Поискал - не нашел. Если знаете - киньте ссылку на ветку.
Работаю в 3-ке.

[Gustav]

Насколько я понимаю, RLS тут использовать не получится, поэтому посмотрите, как сделано в форме LedgerJournalTable, конкретно - метод active в датасорсе. Там вопрос "разрешать редактировать или нет" решается по значению поля posted (разнесено). Соответственно, у вас вместо этого будет проверка, является ли текущая запись - записью, созданной текущим пользователем. Остальное - по аналогии.

[petergunn]

Цитата:

Сообщение от mdconsult

...
Но вносить изменения должны иметь возможность только в карточки своих клиентов ( у которых они проставлены как "ответственные").
...

Задача сводится к тому чтобы дать пользователю возможность редактировать записи по определенному условию?
На источнике данных CustTable перекрыть метод active():

#Admin
public int active()
{
    boolean allowEdit       ;
    int     ret = super()   ;
 
    allowEdit = UserInfoHelp::userInUserGroup( curUserId(), #AdminUserGroup ) ||
                CustTable.<"ответстенный"> == curUserId() ;
    CustTable_ds.allowEdit( allowEdit ) ;
    
    return ret;
}

[mdconsult]

Цитата:

Сообщение от Gustav

Насколько я понимаю, RLS тут использовать не получится, .

У меня тоже такое ощущение. Потому что пробовал и так, и эдак. Результат: "либо-либо".
Спасибо, сейчас попробуем.

[mdconsult]

Цитата:

Сообщение от petergunn

Задача сводится к тому чтобы дать пользователю возможность редактировать записи по определенному условию?

Именно. Если в поле "Ответственный" проставлен пользователь - он может редактировать запись. Если нет - только смотрит.

Сейчас попробую оба варианта.

[belugin]

Лучше все-таки сделать SecurityKey чем хардкодить группу

#Admin
public int active()
{
    boolean allowEdit       ;
    int     ret = super()   ;
 
    allowEdit = hasSecurityKeyAccess(securityKeyNum(CustEditOthersCustomers_ZED), AccessType::Read) ||
                CustTable.<"ответстенный"> == curUserId() ;
    CustTable_ds.allowEdit( allowEdit ) ;
    
    return ret;
}

[mdconsult]

Цитата:

Сообщение от petergunn

На источнике данных CustTable перекрыть метод active():

Да, кстати, не указал, что меня интересует подобное разграничение на таблицу smmBusRelTable. Чтобы "Деловые отношения" модуля CRM менеджеры просматривали все, а редактировали только свои.

[sukhanchik]

Цитата:

Сообщение от belugin

Лучше все-таки сделать SecurityKey чем хардкодить группу

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

Это очень хорошо видно, когда в роли настройщика прав сталкиваешься с задачей настроить права. С первого взгляда догадаться - "А на что влияет этот ключик" - нереально в принципе. Это надо знать. А в дереве ключей - такое недопустимо - там все права так или иначе понятны как раздаются.
А вот "скрытые" права доступа задаются именно через группы.

По крайне мере - так сделано в системе.

[petergunn]

Цитата:

Сообщение от mdconsult

Да, кстати, не указал, что меня интересует подобное разграничение на таблицу smmBusRelTable. Чтобы "Деловые отношения" модуля CRM менеджеры просматривали все, а редактировали только свои.

Если речь идет о форме smmBusRelTable то тогда понятно о каком поле "Ответственный" шла речь - smmBusRelTable.MainContact, код сотрудника из EmplTable? В таком случае необходимо модифицировать метод active() источника данных smmBusRelTable.

Можно предварительно сохранить в переменную код текущего сотрудника при открытии формы:
ClassDeclaration формы:

class FormRun extends ObjectRun
{
    ...
    EmplId  currentContactId ;
    ...
}

в методе init() формы:

void init()
{
    ...
    currentContactId = smmUtility::getCurrentContact() ;
    ...
}

Если речь идет о DAX 4.0 и предположения о том что пользователь может править "своих" (при условии что связь userId->EmplId определена) клиентов и тех у которых поле 'Ответственный' не задано (иметь возможность сделать ранее введенную запись 'своей') то примерно так:

#Admin
int active()
{
    boolean allowEdit ;

    ...
    allowEdit = UserInfoHelp::userInUserGroup( curUserId(), #AdminUserGroup ) || // администраторы могут править все?
                ( currentContactId && ( smmBusRelTable.MainContact == currentContactId
                                        // если возможность править записи с неуказанным ответственным не нужна - закоментировать строку ниже
                                        || !smmBusRelTable.MainContact                 
                ) ) ;
    smmBusRelTable_ds.allowEdit( allowEdit ) ;
    ...
}

В Axapta 3.0 по-моему при открытии формы требовалось что бы пользователь был связан с сотрудником (связь userId->EmplId будет гарантирована), поэтому часть условия (currentContactId) можно опустить:

#Admin
int active()
{
    boolean allowEdit ;

    ...
    allowEdit = UserInfoHelp::userInUserGroup( curUserId(), #AdminUserGroup ) || // администраторы могут править все?
                ( smmBusRelTable.MainContact == currentContactId
                  // если возможность править записи с неуказанным ответственным не нужна - закоментировать строку ниже
                  || !smmBusRelTable.MainContact                 
                ) ;
    smmBusRelTable_ds.allowEdit( allowEdit ) ;
    ...
}

[Ivanhoe]

Цитата:

Сообщение от sukhanchik

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

В стандарте есть особый ключик в ветке Admin и совсем уж нестандартная ветка ключей Business Connector Proxy. Как раз для разграничения доступа. DAX 4.0 SP2.

[sukhanchik]

Цитата:

Сообщение от Ivanhoe

В стандарте есть особый ключик в ветке Admin и совсем уж нестандартная ветка ключей Business Connector Proxy. Как раз для разграничения доступа. DAX 4.0 SP2.

Исключения как раз подтверждают правило.
Есть права доступа, относящиеся к ядру системы (exe-шнику). Это разработка, администрирование, Бизнес-коннектор. Из них разработка и бизнес-коннектор не имеют своего меню. Администрирование - имеет - но у него и похожая структура. За исключением открытия доступа к домену (что тоже является свойством ядра в большей степени). Конфигуратор продукции подчинен разработке - т.к. сам является генератором кода.
Все остальное имеет одинаковую структуру меню (исключая локализацию в т.ч. польские и чешские ключи).
Поэтому общее правило - ориентироваться на то, как это сделано в большинстве функционала (особенно в sys-слое).

[mdconsult]

Большое спасибо всем, кто откликнулся и помогал советами.
Отдельное спасибо petergunn.
Вставил проверку по пользователю и все заработало.