refactor: drop grouping decision in favor of more flexible approach

Author: mariajgrimaldi

docs/decisions/0006-policy-store-and-enforcement-model.rst

@@ -26,11 +26,6 @@ Use a Casbin Model CONF that Supports Core Principles
 - Favor simple matchers to improve performance and maintainability. This means avoiding complex regexes and nested logic where possible.
 - Use Casbin's built-in support for role hierarchies (g, g2) to manage role inheritance and simplify policy definitions.
 
-Do not Handle Grouping and Context Inheritance via Casbin's Built-in Mechanisms
--------------------------------------------------------------------------------
-- Grouping resources will not be implemented via Casbin's built-in grouping mechanisms (g, g2) but will be explicitly managed when checking permissions in the application layer. For example, if a user has the ``course_admin`` role in ``org:123``, this will not automatically grant them the ``course_admin`` role in all courses within that org. Instead, the application layer will need to check both the user's role and the specific context (e.g., organization or course) when making authorization decisions.
-- Define roles that are context-specific, such as ``course_admin`` for a specific course or ``org_admin`` for a specific organization.
-
 Establish Naming Conventions for Subjects, Actions, Objects, and Contexts
 -------------------------------------------------------------------------
 - Favor the use of simple and easy to read matchers and policies to keep the system maintainable. Revisit complexity if needed.