Настройка прав доступа Аксапта 3.0

[tolstjak]

Всем здравствуйте.

Имеется следующая проблема:
В настоящее время пользователи имеют возможность нажатием правой кнопки мышки выбрать меню - Паспорт записи - форма "Информация по проводке".
Как закрыть на этой форме кнопку - Переименование?
Не могу найти.

Заранее благодарен за ответ.


Александр

[raz]

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

[tolstjak]

Цитата:

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

А не подскажите как эту кнопку сначала найти в Правах доступа?

[Megacrusher]

В правах доступа не найдете и не ищите....
Закройте ее вообще для всех... Форма SysRecordInfo свойством Visible на кнопке Rename ... c правами доступа будете возится дольше. Если понадобится быстро под админом откроете и все делов...

[tolstjak]

Цитата:

Изначально опубликовано Megacrusher
В правах доступа не найдете и не ищите....
Закройте ее вообще для всех... Форма SysRecordInfo свойством Visible на кнопке Rename ... c правами доступа будете возится дольше. Если понадобится быстро под админом откроете и все делов...

Большое спасибо.

[Maxim Gorbunov]

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

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

[Megacrusher]

Замучаешься по всем таблицам права доступа на редактирование давать или не давать .... А если забудешь и дашь на добавление? Расхлебовать то кому потом? Проще надо делать...

[mazzy]

Программировать?

[Megacrusher]

2 mazzy
Я знаю как звучит это слово "Программирование" Режет слух и как будто бы говорит "Готовьтесь к большим переменам и проблемам". Но в моем понимании: если кнопка мешает работе - убить (т.е. скрыть "убивать" не надо это вредно) кнопку. И никаких гвоздей... А на поиск оптимального решения уйдет время... А время это деньги... Деньги это упущенные возможности.

[mazzy]

ок. как скажешь, Megacrusher.

С чем готов согласиться - нужно искать эффективное решение. "Убить кнопку" может быть таким решением.

[raz]

Проще на кнопку повесить SecurityKey типа AdminSetup и нет проблем.

[Megacrusher]

Цитата:

Изначально опубликовано raz
Проще на кнопку повесить SecurityKey типа AdminSetup и нет проблем.

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

[glibs]

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

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

[glibs]

Ой, простите.

Забыл еще сказать, что если вы не пользуетесь "RLS" и боитесь, что при добавлении нового пользователя вы вдруг забудете отобрать у него права, то с очень высокой вероятностью вы неправильно структурировали группы пользователей.

[komar]

Цитата:

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


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

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

[Megacrusher]

2 glibs

Конечно у меня не достаточно входной информации от tolstjak в сявзи с этим я рассчитываю на самое худшее (т.е. пессиместично) , и продолжаю утверждать, что скрыть кнопку самый безболезненный вариант. Объясню почему. Это просто моя методика работы и именно так скорее всего я бы сделал сам. Смоделирую ситуации.
Ситуация № 1 Система полностью настроена, ключевые поля настроены с помощью номерных серий.
В этом случае я 100% скрываю кнопку "переименовать" от всех и даже от себя. Потому как это кнопка помогает далеко не всегда и не во всех справочниках. Помню как то переименовали коды банковских счетов (в 2.5) а в общем журнале в неразнесенных журналах (да и в других журналах) все осталось по старому Первое что я сказал было №$%&... Ну ничего... Джобик за 5 мин написал все поправил.

Ситуацию № 2 Система настроена не полностью, что то перенастраивается. Стандарты наименования кодов и ключевые поля делаются по подсказке пользователей. Предположим им удобно вносить по своему шаблону. И они кодируют сами по описанным правилам.
В этом случае я делаю ключ, но только называю его (RenameFields) вешаю на кнопарь, может еще придумаю куда его повесить. И делаю группу Advanced Users куда включаю этот ключ.

Ситуацию № 3 Система в плане становления (нулевой цикл) большинство пользователи равноправны вносят большие объемы информации и пересекаются по участкам и хорошо обучены.
Вот в этом случае имеет смысл сделать разграничение по таблицам поиграть с правами на чтение и добавление записей.

Вот как бы я делал.

Насчет "мучаться с правами доступа" Вы уверены, что это необходимо делать всегда? Вы уверены что лучше потратить неделю на настройку по всем таблицам а потом столько же по времени перенастраивать если это понадобится? Не экономней ли это же время пустить на более важные проблемы?

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

[tolstjak]

Цитата:

Изначально опубликовано glibs
Ой, простите.

Забыл еще сказать, что если вы не пользуетесь "RLS" и боитесь, что при добавлении нового пользователя вы вдруг забудете отобрать у него права, то с очень высокой вероятностью вы неправильно структурировали группы пользователей.

Простите за возможно глупый вопрос, но что такое "RLS" ?

[Megacrusher]

RLS - это Record level security

Администрирование\Настройки\Контроль доступа\Доступ на уровне записей

[mazzy]

клево. занес в FAQ

[glibs]

Цитата:

Изначально опубликовано Megacrusher
...Насчет "мучаться с правами доступа" Вы уверены, что это необходимо делать всегда? Вы уверены что лучше потратить неделю на настройку по всем таблицам а потом столько же по времени перенастраивать если это понадобится? Не экономней ли это же время пустить на более важные проблемы?...

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

Цитата:

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

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

В случае с RLS такими настройками мне обойтись не удалось.