Есть пользователь, к нему прикреплено две row-level роли, в которых есть ограничения на, скажем, сущность aaa. Первая роль ограничивает просмотр так что доступны только свои записи, т.е. aaa.createdBy={currentUser.id}, вторая роль более “мягкая” и дает доступ ко всем экземплярам aaa, которые относятся к подразделению моего пользователя, например, aaa.division={currentUser.division}.
Вопрос: что увидит в гриде по сущности aaa мой пользователь? По нашему опыту ситуация нестабильная и в каких то ситуациях пользователь на увидит датасет, который соответствует первой row-level роли, а в каких то ситуациях второй row-level роли.
У кого какой опыт? Просьба поделиться. Видится что по хорошему нельзя в разных row-level ролях определять ограничения для одной и той же сущности, потому как в большинстве случаев они будут противоречивы. Если это так тогда наверное система должна как минимум предупреждать о нежелательных настройках, которые пользователь собирается произвести в row-level ролях.
Вообще должны проверяться все row-level роли, и пользователь должен видеть записи, которые удовлетворяют обоим условиям одновременно.
Нужно больше информации о проблеме: версия Jmix, как создана роль (аннотированный интерейс или в рантайме в базе), как задано условие (JPQL или предикат).
В идеале, чтобы ускорить решение проблемы, хотелось бы демо-проект, на котором видна ошибка.
Т.е. в текущем варианте права на сущность определяются по принципу конъюнкции всех условий.
Хотя в логике ролевой модели доступа как раз-таки должен работать принцип дизъюнкции.
Потому как пользователю даются минимальные права доступа, а потом добавлением различных ролей исполнителя доступ должен расширяться.
Изначально имею доступ только к своим объектам. Добавили роль руководителя - вижу свои объекты и объекты подчиненных. И т.д.
А сейчас добавление роли руководителя вынуждает удалять базовую минимальную роль.
Ресурсные (resource) роли и роли уровня строк (row-level roles) работают по разному. Из документации:
Ресурсные роли предоставляют пользователям разрешения на определенные объекты и операции, которые по умолчанию запрещены. Пользователь без ресурсных ролей не имеет разрешений и не может получить доступ к системе. Роли уровня строк, напротив, ограничивают доступ к определенным экземплярам сущностей. Пользователь без ролей уровня строк имеет доступ ко всем экземплярам сущности (если это разрешено ресурсными ролями).
Т.е. ресурсная роль - это разрешение, а row-level роль - это ограничение. И каждая новая row-level роль, назначенная на пользователя, ещё больше ограничивает набор строк БД, которые данный пользователь видит.
Роли уровня строк - ограничительные. Вопросов нет.
Вопрос как они ограничивают доступ в случае совместного ограничения.
Если ограничение на сущность распространяется на несколько ролей, то ОГРАНИЧЕНИЕ должно возникать если все эти роли запрещают доступ к экземпляру сущности.
А сейчас доступ РАЗРЕШАЕТСЯ если все роли разрешают доступ!!!
Обычная ситуация: сотрудник организации работает в двух отделах. В каждом отделе разрешено работать только с документами своего отдела и не разрешено с документами второго. Есть две роли уровня строк, которые разрешают видеть только документы своего отдела. Если мы назначим эти две роли нашему сотруднику - он не увидит ничего!!! Для такого сотрудника нужно делать свою индивидуальную роль с видимостью двух отделов.
А если таких отделов у меня пятнадцать и сотрудников вовлеченных в работу нескольких отделов пару сотен? Сколько ролей я должен буду сделать? Для каждого сотрудника свою? Это в корне неверная логика.
Еще раз
Определение ограничения ролью уровня строк должно производиться по правилу:
Ограничения, если мы говорим, например, про кусочки JPQL запросов суммируются по AND. Т.е. в вашей конкретной задаче если у сотрудника две row-level роли для документоа отдела А и Б, то для такого сотрудника сформируется запрос
select документ where (документ в отделе А) **И** (документ в отделе Б)
Очевидно, такой запрос ничего не вернёт, потому что документ у вас не может быть в двух отделах одновременно.
Логика тут не неверная, она подчиняется чёткому правилу сбора всех ограничений по условию И. Вопрос в том, что для вашей задачи в вашем конкретном подходе к использованию ролей она не подходит.
Сработает, например, вариант, если вы сделаете не множество ролей для каждого отдела, а сделаете одну роу-левел роль “Пользователь должен видеть документы СВОИХ отделов”, дальше вы где-то в модели данных для каждого пользователя задаёте список его отделов, а в запросе к роу-левел роли у вас будет выражение, которое сделает что-то типа
select документ where документ.отдел в списке отделов текущего пользователя
