942 new variable user permission team

[mborodii-prog]

Summary

Adds a recipe variable named user_permission_team.

This variable is intended to expose the permission-driving team for the current recipe run, so recipes can branch behavior based on the user's effective permission team.

Problem

Some recipes need to apply different limits depending on the user running them.

For example, a web research recipe may allow one group to process more rows than another group. The row limits themselves should remain recipe logic, but the recipe needs access to the current user's effective permission group.

Changes

• Added user_permission_team as an automatic recipe variable.
• For remote recipe runs, user_permission_team is read from recipe metadata when the backend provides it.
• For local/direct runs, user_permission_team falls back to the authenticated token claim named user_permission_team.
• Explicit caller-provided variables still take precedence.
• Added tests for templated values, if conditions, explicit overrides, and remote recipe metadata.

Backend Contract

WranglesPY expects the effective permission group to be provided as:

user_permission_team

The same name is exposed inside recipes.

Usage Examples

Use in an if condition:

wrangles:
  - create.column:
      output: allowed
      value: true
      if: user_permission_team == 'admin'

Use as a templated value:

read:
  - test:
      rows: 1
      values:
        group: ${user_permission_team}

Use to choose a row limit in recipe variables:

variables:
  max_rows: 100

wrangles:
  - filter:
      if: user_permission_team == 'small_team'
      where: index < ${max_rows}

[ebhills]

Queue triage (2026-07-27)

• Disposition: Draft — delivery-owner action
• Delivery owner: @mborodii-prog
• Next action: Validate and document the backend/token contract for user_permission_team, keep explicit-override coverage, then request one primary reviewer.

GitHub is the status record; update this PR rather than the external spreadsheet.

[Copilot]

Pull request overview

Adds user_permission_team as an automatic recipe variable sourced from authentication claims or remote recipe metadata.

Changes:

• Adds token and metadata permission-team extraction.
• Preserves explicit variable overrides and adds recipe tests.
• Isolates training tests from backend model creation.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
wrangles/recipe.py	Injects the permission-team variable.
wrangles/auth.py	Extracts permission teams from tokens.
tests/recipes/test_variables.py	Tests recipe variable behavior.
tests/connectors/test_train.py	Replaces backend-dependent test operations with mocks.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ebhills]

@copilot - 2 things:

• in a previous review the agent changed the name of tests and functions from user_group to user_permission_team, probably because of the title of this PR. However, we had decided to refer to this new variable as user_group because 'group' refers to both teams (childern) and orgs (parents), either of which can determine authorization. Upon further consideration, let's change all references to applied_permission_group. this makes its meaning clear.
• resolve the conflicts.

[Copilot]

@copilot - 2 things:

• in a previous review the agent changed the name of tests and functions from user_group to user_permission_team, probably because of the title of this...

Updated the canonical permission-group variable to applied_permission_group and kept backward-compatible aliases for the previous user_permission_team key while preserving explicit override behavior. Commit: f160f63.

[ebhills]

@mborodii-prog - please see my recent comments about the name for this variable. I have decided to call it:
applied_permission_group

Please review this here and in API-Core & wranglesXL to ensure we are consistent across all 3. And let's make sure it's visible in XL (via inspect)