SeVaiscraВ Искре это выглядит так
А как в Искре решаются вопросы разграничения прав доступа и бизнес-правил?
разграничения прав доступа...
1. Простая авторизация. Имя, пароль, разрешенный период доступа и т.п.
2. Ролевой доступ. Настройка профилей для групп пользователей и определение полномочий в рамках профиля. После подключения к серверу и прохождения процедуры простой авторизации дальнейшая работа с приложениями возможна только в рамках предоставленного пользователю профиля (доступные сервисы, параметры их запуска и т.п.). Если пользователю разрешен доступ к более чем одному профилю, то предоставляется выбор профиля для текущей сессии.
3. На уровне приложений. Каждый пользователь работает в рамках сессии. Параметры ее достуны разработчику приложений, естественно он имеет возможность использовать их при построении выборок, в процедурах СУБД и других элементах на которых построена бизнес-логика приложения. Т.е., к примеру, если требуется обеспечить доступ пользователя только к "своим" записям в БД, то в запрос добавляется условие WHERE owner = :OWNER, где :OWNER - параметр сессии, логин пользователя. И т.д. и т.п.

SeVa,

что касается бизнес-правил, то в этом вопросе Искра просто предоставляет интерфейсы для исполнения этих самых правил. Создается процедура формирования проводок, регистрируется в системе в качестве сервиса с параметрами (допустим ID документа), привязывается к нужному документу (документам), становится доступной для запуска с панели задач документа или по событию (Сохранение, Учет документа и т.п.). А уж что в этой процедуре - решает разработчик приложения.
примерно так

p.s. с проводками конечно банальный пример, но понятный всем. Не нужно дополнительных объяснений.

SeVaПриблизительно понятно(демонстрашки крутятся слишком быстро,нет возможности остановить и прокрутить).А каким образом будут разруливаться ситуации,которые приблизитено описал автор топика:
-только создатель документа имеет право на редактирование,публикацию и возвращение на правку
-непосредственный руководитель и ряд ответственных лиц(например, куратор проекта согласовывает счет), могут согласовывать и возращать на правку
-определенный круг лиц в зависимости от типа документа может возращать на правку и подписывать после согласования.
Подписанный документ не может редактироваться.
эти вопросы решаются на уровне приложения. Описанная Вами логика, например, применяется в системе визирования документов . Логика реализована на уровне СУБД. Пользователь размещает документ в системе, срабатывает логика его маршрутизации и определенные маршрутом и полномочиями пользователи получают доступ к документу. Проставляют свои визы, пишут замечания и т.п. , документ движется далее, пока не будет полностью согласован.
В качестве резюме: Искра не содержит встроенной логики, она исполняет логику приложения созданного разработчиком. Искра предоставляет только интерфейсы для компоновки сервисов из которых состоит приложение в единое взаимосвязанное целое.