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

[Pan]

Кто может подсказать, при настройке прав доступа на уровне записей возможно ли сделать так, что бы , например, пользователь 1 мог иметь полные права к примеру на одну группу спецификаций, а другую группу мог только просматривать. Т.е. меня интересует, возможно ли установить разные уровни доступа при настройке на уровне записей ( т.е в них самих) через фильтр ?

[mazzy]

никак. права на уровне записей это только view.
он либо показывает, либо не показывает.

права на запись/добавление/удаление надо программировать.

[Pan]

Спасибо. Я так и думала.

[linney]

>права на запись/добавление/удаление надо программировать.

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

[Valery]

Zitat:

Изначально опубликовано linney ...сами столкнулись с этой проблемой, когда надо, допустим, разрешать создавать записи в журнале платежей только по тем поставщикам\клиентам, по которым это право даровано данному манагеру... [/B]

А в чем проблема? Создаете для данного манагера персональную группу пользователей и настраиваете для нее доступ на уровне записей к справочникам п-ков/клиентов и журналам платежей...

[linney]

Проблема в невнимательности при чтении...

ПОВТОРЯЮ: использование стандартного функционала контроля на уровне записей НЕ запретит манагеру в журнале платежей СОЗДАТЬ платеж НЕ НА СВОЕГО ПОСТАВЩИКА, он может спокойно вбить руками КОД НЕ СВОЕГО поставщика и сохранить эту запись, не смотря на то, что в лукапе на поле код этого поставщика не виден...

[ZVV]

Zitat:

... для чего стандартная тогда, если она такая убогая, прости меня MBS

Из тоё же серии:

Я я вот при первых знакомствах с Аксаптой всё смотрел на неё и думал: "А нафига она вообще нужна?! Всё равно под наши предприятия всё переписывать...."

думал со временем пройдёт, но пока никак...

[Valery]

Zitat:

Изначально опубликовано linney
использование стандартного функционала контроля на уровне записей НЕ запретит манагеру в журнале платежей СОЗДАТЬ платеж НЕ НА СВОЕГО ПОСТАВЩИКА, он может спокойно вбить руками КОД НЕ СВОЕГО поставщика и сохранить эту запись, не смотря на то, что в лукапе на поле код этого поставщика не виден...

Для решения только этой проблемы не надо переписывать систему прав доступа. На форуме обсуждались способы как это сделать малой кровью
Вот, например, http://www.axforum.info/forums/showt...&threadid=5884
А ещё предлагался оригинальный способ/извращение: контрол закрыть для редактирования, а рядом расположить это же поле но сузить его так, чтобы осталась видна только стрелочка. Тогда вручную ввести ничего нельзя - можно только выбрать из списка

[Maxim Gorbunov]

Zitat:

Изначально опубликовано Valery
А ещё предлагался оригинальный способ/извращение: контрол закрыть для редактирования, а рядом расположить это же поле но сузить его так, чтобы осталась видна только стрелочка. Тогда вручную ввести ничего нельзя - можно только выбрать из списка

Для этих целей есть метод validateField на таблице.

[Hamster]

>... для чего стандартная тогда, если она такая убогая, прости меня MBS

Хм...
Итальянский базар:

Сеньёрита, эта кофта из шести?
О святой Януарий! Конечно 100% лучшая шерсть!!!!!!!!!!!!!!!!
А почему на ярлыке "60% синтетика"?
О святой Антоний! ДА ЧТО ВЫ ХОТИТЕ ЗА ТАКИЕ ДЕНЬГИ?????!!!!!!!!??????

[Андре]

Zitat:

Всё равно под наши предприятия всё переписывать....

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

[linney]

Zitat:

Изначально опубликовано Андре


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

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

Только вот таких требований - нормальных, логичных, обоснованных - я могу привести с два десятка. Еще чуть-чуть - и будет вся Ах, вот отчего мне грустно

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

[Михаил Андреев]

Zitat:

Изначально опубликовано linney
>права на запись/добавление/удаление надо программировать.

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

Правильно ли я понял, что у вас платежи от клиентов вносят менеджеры по продажам?

[George Nordic]

Приветствую, Михаил!

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

С Уважением,
Георгий.

[xonix]

Господа!
Я не понял: вы обсуждаете ситуацию, как застраховаться от намеренно "незаконного" с точки зрения политик компании, воода данных пользователем?
Вот он, русский менталитет... Да при таком раскладе ещё много где нужно менять.

А никто не пробовал подобные проблемы решать административными методами?
Т.е. если кто-то НАМЕРЕННО будет вносить не те данные - то штарф (денежный).
Откуда у пользователя появляется желание НАМЕРЕННО вносить неверные данные?

А проверяется как раз просто - отчёты.... можно в конце каждого дня.

[TDima]

День добрый!

Пытаюсь настроить доступ на уровне записи (фильтр по одной из аналитик) - работать не хочет.... В чем может быть причина?

[glibs]

Что за версия системы?

Какую таблицу вы конкретно мучаете?

Я попробовал на 3.0 сп5 в плане счетов. Работает.

[rigor]

Zitat:

Zitat von xonix

Господа!
Я не понял: вы обсуждаете ситуацию, как застраховаться от намеренно "незаконного" с точки зрения политик компании, воода данных пользователем?
Вот он, русский менталитет... Да при таком раскладе ещё много где нужно менять.

А никто не пробовал подобные проблемы решать административными методами?
Т.е. если кто-то НАМЕРЕННО будет вносить не те данные - то штарф (денежный).
Откуда у пользователя появляется желание НАМЕРЕННО вносить неверные данные?

А проверяется как раз просто - отчёты.... можно в конце каждого дня.

Судя по всему, "нерусский" менталитет должен ставить целью не решение проблем бизнеса, а ущучивание менеджеров. И руководителю более нечем заняться, как ежевечерним контролем правильности внесения данных. А лучше специально для этого нанять человека. Оно, конечно, тогда штрафы.
Но всё же лучше изначально не вводить юзера во искушение. Последующие разборы полётов занимают времени и ресурсов в разы больше, чем реализация не самой сложной защиты.

[itfs]

Стандартная RLS продается (продавалась?) отдельно. Можно не покупать, написать свою. Вопрос в экономичской целесобразности.

С уважением, itfs.

[mazzy]

Zitat:

Zitat von itfs

Можно не покупать, написать свою.

Можно. Но купить дешевле.
http://axapta.mazzy.ru/works/accessrecord/