Здравствуйте!
Подскажите как правильно решить следующую задачу:
На контрагенте есть поле тип - выпадающий список со значениями: клиент, конкурент, поставщик и т.п.

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

Насколько понимаю, это задача должна решаться через скрипты на сохранении контрагента.

Куда и какой скрипт правльно вставить?

Нравится

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

При сохранении записи необходимо проверять изменение типа - событие AfterPost текущего Dataset, а для самой вставки записей прав лучше использовать процедуры СУБД.

"Кулак Олег" написал:

Спасибо, Олег.
а можете прокомментировать, почему лучше напрямую в бд выставлять права, а не через скрипты (например, ProcessGiveRecordRightsToContact)?

А можно ли как-то получить список всех ID-ок пользователей, входящих в определенную группу?

"Уймин Андрей" написал:А можно ли как-то получить список всех ID-ок пользователей, входящих в определенную группу?

Попробуйте для этой цели использовать сервис sq_UserInGroup

"Уймин Андрей" написал:Спасибо, Олег.
а можете прокомментировать, почему лучше напрямую в бд выставлять права, а не через скрипты (например, ProcessGiveRecordRightsToContact)?

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

"Уймин Андрей" написал:А можно ли как-то получить список всех ID-ок пользователей, входящих в определенную группу?

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

"Раловец Ольга" написал:лучше раздавать права группе пользователей

Полностью согласен с Ольгой. Это единственно верный вариант.

да, точно, конечно же, надо на группы! спасибо, Ольга и Олег!

а скрипты (в частности AfterPost) можно выполнять только под правами текущего пользователя?

Не сами скрипты. В скриптах Вы будете добавлять записи в таблицу прав с помощью сервисов DataSet, SelectQuery, а они при формировании запроса на вставку позаботятся о том, чтобы эти запросы выполнялись от имени текущего пользователя и соответственно с его правами. Это реализовано в ядре и изменить нельзя. А хранимые процедуры по умолчанию выполняются от имени создателя, следовательно будут пользоваться правами того, под кем Вы создавали хранимку, и поэтому Вы наверняка будете создавать ее под пользователем с максимальными правами, иначе с процедурой раздачи прав могут быть проблемы.

"Раловец Ольга" написал:

небольшое уточнение: а если создается новая запись, то у создающего пользователя ведь гарантированно будет право на добавление прав?

"Уймин Андрей" написал:ебольшое уточнение: а если создается новая запись, то у создающего пользователя ведь гарантированно будет право на добавление прав?

Да

Ну а если пользователь, у которого есть право на изменение контрагента, но нет права на изменение прав на эту запись, изменит тип контрагента и сохранит запись, то ваш скрипт перераздать права не сможет

да, понятно
спасибо!

Я бы рекомендовал для таких целей использовать триггеры. Хранимая процедура, которая может выдавать права и доступна для выполнения любому пользователю - это нормальная дыра в безопасности.

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

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

Нравится

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

Руслан, а галочка у tbl_Contact Администрируется по записям стоит?

В том -то и дело, что галочки -то стоят :-( да я и не менял в этой области ничего в админке, причем не было представлений - Контакты, Контракты, Документы .... я конечно руками их перенес из тестовой базы и права назначил... но почему это могло произойти ....
По моему эти таблицы изначально администрируться по записям(в базе которая идет в поставке)....разве нет?

"Черных Руслан" написал: я конечно руками их перенес из тестовой базы и права назначил... но почему это могло произойти ....

Это зря. Не думаю что Вы все правильно сделали.

"Черных Руслан" написал:По моему эти таблицы изначально администрируться по записям(в базе которая идет в поставке)....разве нет?

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

Теперь после переноса представлений dbo.vw_Contact, dbo.vw_ContactRight из тестовой базы... при создании пользователем контакта права по-умолчанию не переносятся на запись :-(, хотя в Администрировании все настроено...

Снять галочку "Администрируется" с контактов, удалить tbl_ContactRight (если нужно сохранить данные), поставить галочку "Администрируется" и сохранить изменения в БД. Должно помочь.

После обширных танцев В-О-О-О-Т с таким бубном...я восстановил функциональность, но какого исчезли вьюхи? Грешу только на то, что переносил изменения в сервисах утилитой Mareg в т.ч. и изменения в таблицах, но я читал на форуме, что утилита переносит информацию и в БД, и все изменения действительно есть в БД просто нет вью на основную таблицу и таблицу прав....

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