Серия вопросов к разбирающимся в аттейне

[Evgeniy]

Всем доброго времени суток! Вот решил еще поэксплуатировать коллективный разум, а то в этом аттейне чем дальше в лес... Вот такой вот возник набор вопросов:
1. Сервер navision attain поддерживает несколько БД или нет? А то у меня что-то сложилось впечатление, что нет, исходя из доков.
2. БД в аттейне делится на компании. Структура бд, набор таблиц и т.д. при этом одинаковые для всех фирм или не обязательно?
3. При использовании SQL Server одна и та же таблица в navision отражается в разных таблицах на сервере, по числу фирм в БД. Зачем это надо?
4. Существует ли в navision аналог интерфейсов в 1С?. Т.е. для разных пользователей структура меню разная и юзер не видит ссылок на то, на что у него прав все равно нет.
5. Как присваиваются права? Не в техническом смысле, там все понятно, а в логическом. Там полторы сотни ролей (они бы хоть их названия что ли перевели, шутки ради). Не существует никакого механизма простого определения, какую роль я должен юзеру дать, чтобы он получил доступ к данному объекту?

Вот... Буду очень признателен, если кто-нибудь ответит хотя бы на часть вопросов. Если это rtfm (а это вполне может быть он), то отошлите, плз, к конкретному месту в доках. Спасибо.

[komar]

конкретного места в доках не помню, вот некоторые ответы:
1. В базе данных лежат и данные, и приложение - как же ему в таком случае поддерживать несколько баз с одним приложением?
2. Одинаковые
3. Такова жизнь.
4. Глава 5-3 руководства Архитектура Навижн
5. Заведи свои роли.

[Evgeniy]

Спасибо большое. Но:

Цитата:

1. В базе данных лежат и данные, и приложение - как же ему в таком случае поддерживать несколько баз с одним приложением?

В каком смысле приложение? Насколько я понял, в БД лежат данные и структура данных (аналог конфигурации в 1С, например). По идее на сервере должно быть сколько угодно баз, каждая своей конфигурации; при использовании SQL Server так и есть, а вот navision server при установке требует выбрать БД. Это значит, что она там все-таки одна?

Цитата:

4. Глава 5-3 руководства Архитектура Навижн

Там описано предоставление прав доступа, а я имел ввиду интерфейсы

Цитата:

5. Заведи свои роли.

Это понятно, я имел ввиду, как использовать существующие.

[Grizzly]

> 1. Сервер navision attain поддерживает несколько БД или нет? А то у меня
> что-то сложилось впечатление, что нет, исходя из доков.

Если ты имеешь в виду один сервер как процесс, который управляет несколькими БД, то нет. Но на одном компьютере ты можешь запустить столько процессов, сколько у тебя БД. Поэтому один компьютер у тебя может управлять несколькими БД.

> 2. БД в аттейне делится на компании. Структура бд, набор таблиц и т.д. при
> этом одинаковые для всех фирм или не обязательно?

да одинаковы, во всех компаниях одной БД различаются только табличные данные.

> 3. При использовании SQL Server одна и та же таблица в navision отражается
> в разных таблицах на сервере, по числу фирм в БД. Зачем это надо?

С одной стороны, Navision Attain построен таким образом, что работа пользователя с несколькими или со всеми компаниями одновременно исключена и поэтому хранить данные в одной таблице нет необходимости. С другой, для любой СУБД верно правило - чем больше таблица, тем ниже скорость выполнения операций с данными.

> 4. Существует ли в navision аналог интерфейсов в 1С?. Т.е. для разных
> пользователей структура меню разная и юзер не видит ссылок на то, на
> что у него прав все равно нет.

Я, к сожалению, не знаком с 1С. Но если ты имеешь в виду главное меню, т.е. то, которое появляется при входе пользователя в систему, то оно может быть настроено индивидуально для каждого пользователя (Финансы/Настройка/Пользователи/Настройка). Если же ты имеешь ввиду то, как это сделано в Axapta (IntellyMorph), когда внешний вид форм "на лету" изменяется в зависимости от прав доступа у пользователя, то нет.

[Evgeniy]

to (Grizzly):
Спасибо. По поводу 1-3 - понятно, а вот по поводу 4 -не совсем:
меня интересует именно настройка главного меню для пользователей (а лучше бы для групп пользователей); но в "Финансы/Настройка/Пользователи/Настройка" настраиваются всего несколько параметров - разрешить учет от/до и т.д.. Где тут настройка главного меню? Или я не там смотрю?

[Grizzly]

Там есть поле "Главное Меню ID". Если оно у тебя по умолчанию не показывается, наведи курсор мыши на заголовок таблицы, нажми правую кнопку, выбери пункт "Показать" и поставь галочку у нужного поля.

[Evgeniy]

Понял, спасибо... Но вообще это круто- получается я для каждого типа главного меню должен отдельную форму создавать... а если их несколько десятков...как-то невесело...

[Grizzly]

И это не устраивает? )

И как же это должно быть в идеале? Без привязки к Attain, на примере абстрактной системы.

[Pavel]

Цитата:

Изначально опубликовано Grizzly
И это не устраивает? )

И как же это должно быть в идеале? Без привязки к Attain, на примере абстрактной системы.

В идеале именно так и должно быть. Данное свойство позволяет организовать персональные рабочие места для каждого пользователя системы (или роли).

[Grizzly]

Цитата:

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


В идеале именно так и должно быть. Данное свойство позволяет организовать персональные рабочие места для каждого пользователя системы (или роли).

Pavel, целью своего вопроса я хотел определить что неустраивается в этом именно Evgeniy, т.к. он выразил некое сожаление по этому поводу. Вполне вероятно, что его "хотелки" легко решаются стандартными средствами.

С другой стороны, если говорить об "идеале", то я далек от мысли, что назначение пользователю отдельно (!) прав доступа и интерфейса, как принято в Attain, является совершенным решением. Это всего лишь приемлемое решение для систем подобного класса.

[Evgeniy]

Цитата:

И как же это должно быть в идеале? Без привязки к Attain, на примере абстрактной системы.

Не знаю, наверное дело втом, что я с 1с довольно долго общался, но я как-то привык к системе, когда есть иерархический набор пунктов меню, есть набор интерфейсов, и для каждого интерфейса включается/выключается данный пункт меню. Т.е. если я вдруг захотел добавить что-то кому-то, то я просто ставлю галку в нужном месте. И управление интерфесами сосредоточено в одном месте. А здесь у меня будет туча форм, я должен в нужную добавить какие-то кнопки, прописать какие-то ссылки, а если это нужно сделать для 10 интерфейсов, причем быстро? Все-таки 10 галок поставить/снять - это одно дело , а 10 раз одно и ту же процедуру с рисованием этих кнопок прделывать - немножко другое... Хотя в общем-то переживем....

[Pavel]

Цитата:

Изначально опубликовано Grizzly
он выразил некое сожаление по этому поводу

Его замечания по "технике" реализации, а не по "логике".

Цитата:

Изначально опубликовано Grizzly
С другой стороны, если говорить об "идеале", то я далек от мысли, что назначение пользователю отдельно (!) прав доступа и интерфейса, как принято в Attain, является совершенным решением.

Тогда в чем его несовершенство (отличие от "идеала")?

[Pavel]

Цитата:

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

Есть разные варианты по "технике" настройки. К сожалению, не могу дать совета по аттейн, но в аксапте , например, все выполняется аналогично описанному выше способу, т.е. открываете настройку прав для пользователя или группы пользователей, и в разделе «Доступ к пунктам меню» выбирая необходимые пункты, устанавливаете доступ (конечно же, любимыми «галочками»).

[Rungart]

В Attain возможно управлять видимостью элемента следующим образом:
1. В свойствах элемента присваиваешь полю Name какое-либо значение, отличное от задаваемого по умолчанию, к примеру "Поле1".
2. В триггере OnOpenForm пишешь код :
if Userid='VASILIY' then begin
CurrForm.Поле1.VISIBLE(false);
end;
Т.о пользователю VASILIY элемент Поле1 виден не будет.

[Grizzly]

Цитата:

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


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

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

[Grizzly]

Цитата:

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


Его замечания по "технике" реализации, а не по "логике".



Тогда в чем его несовершенство (отличие от "идеала")?

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

Дело в том, что в настройка интерфейса под конкретного пользователя таким образом как это делается в Attain, хотим мы того или нет, является также инструментом ограничения прав доступа к функциональности системы. Кстати, некоторые ограничения, например, ограничения на доступ на уровне поля в таблице, могут быть сделаны только на уровне интерфейса.

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

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

Однако, между интерфейсом и правами доступа в системах управления предприятием существует четкая связь - выполняемые пользователем функции. Поэтому, на мой взгляд, в "идеале" настройка для пользователя должна осуществляться в терминах элементарных (неделимых) бизнес функций. Для выполнения каждой функции необходимы некоторые права доступа, которые, например, в Attain благодаря структурированности и типизации его языка легко могут быть определены автоматически. Таким образом, для каждой группы пользователей по выполняемым ей бизнес функциям легко могут быть получены права на доступ к объектам системы. А по этим правам система на основе базового меню, которое разрешает все, должна сгенерировать меню для группы пользователей.

Что касается персонализации меню (и вообще интерфейса) под конкретного пользователя, то этим должен заниматься сам пользователь. В его руки дается система со всеми необходиыми функциями, а как их разместить пусть решается он сам. Для этого ему можно дать возможность на основе стандартных для его группы настроек создавать свои.
Еще, на мой взгляд, полезной для этих целей является функция ведения системой рейтинга выполняемых команд. Самые часто используемые команды помещаются системой в наиболее доступное место. Таким образом система как бы сама подстраивается под особенности работы конкретного пользователя.

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

[Grizzly]

************** удален повтор by Mazzy *********

[Grizzly]

************** удален повтор by Mazzy *********

[Pavel]

Позиция сформулирована достаточно ясно. Только больше не нужно постить это сообщение.

[Evgeniy]

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