Member Junction
    Preparing search index...

    Resolves the effective SearchScope permission for a (user, scope, agent) triple.

    Resolution order (later steps only run if the earlier did not produce a definitive answer):

    1. Agent.SearchScopeAccess === 'None' → reject (explicit agent-side deny).
    2. Direct grant: a SearchScopePermission row with UserID = user.ID and SearchScopeID = scope.ID. PermissionLevel = 'None' is an explicit deny that short-circuits and rejects regardless of role grants.
    3. Role grants: SearchScopePermission rows where RoleID is in the user's UserRoles. The highest non-None level wins. None entries are ignored at the role level (see comment below).
    4. Agent.SearchScopeAccess === 'All' → allow at Search level (lets trusted agents act across all scopes when no user-side grant exists).
    5. No grant → reject.

    The user-direct-None rule (step 2) is intentional: an admin who explicitly denies a user on a scope should not have that decision overridden by a role membership the user happens to also hold. Role-level None entries are not authoritative because they are usually authored as a placeholder (e.g., to make a row exist before granting it later) and would create surprising lockouts when a user joins a role.

    Index

    Constructors

    Methods

    • Checks whether the given scope is in the agent's assigned-scope list via __mj.AIAgentSearchScope. Used to enforce the SearchScopeAccess='Assigned' deny-list rule. Returns true when at least one matching row exists with Status='Active'; false otherwise.

      Parameters

      • agentID: string
      • searchScopeID: string
      • contextUser: UserInfo

      Returns Promise<boolean>