flows: fix OOB flow incorrectly setting pending user

closes #3224

Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>

authentik/flows/migrations/0018_oob_flows.py

@@ -14,7 +14,7 @@ return not akadmin.has_usable_password()"""
 PREFILL_POLICY_EXPRESSION = """# This policy sets the user for the currently running flow
 # by injecting "pending_user"
 akadmin = ak_user_by(username="akadmin")
-context["pending_user"] = akadmin
+context["flow_plan"].context["pending_user"] = akadmin
 return True"""
 
 

website/docs/flow/stages/email/index.md

@@ -13,11 +13,11 @@ By default, the email is sent to the currently pending user. To override this, y
 For example, create this expression policy and bind it to the email stage:
 
 ```python
-request.context["email"] = "foo@bar.baz"
+request.context["flow_plan"].context["email"] = "foo@bar.baz"
 # Or get it from a prompt
-# request.context["email"] = request.context["prompt_data"]["email"]
+# request.context["flow_plan"].context["email"] = request.context["prompt_data"]["email"]
 # Or another user attribute
-# request.context["email"] = request.context["pending_user"].attributes.get("otherEmail")
+# request.context["flow_plan"].context["email"] = request.context["pending_user"].attributes.get("otherEmail")
 return True
 ```
 

website/docs/flow/stages/user_write.md

@@ -14,6 +14,6 @@ Starting with authentik 2022.5, users can be added to dynamic groups. To do so,
 from authentik.core.models import Group
 group, _ = Group.objects.get_or_create(name="some-group")
 # ["groups"] *must* be set to an array of Group objects, names alone are not enough.
-request.context["groups"] = [group]
+request.context["flow_plan"].context["groups"] = [group]
 return True
 ```

website/docs/releases/v2022.7.md

@@ -14,6 +14,10 @@ slug: "2022.7"
     In earlier versions, cyclic group relations can lead to a deadlock when one of groups in the relationship are bound to an application/flow/etc.
     This is now limited to 20 levels of recursion.
 
+-   Change in context behaviour for policies executed within flows
+
+    In previous versions, the policy context would be set to a reference to the currently active flow plan context. This makes it so any changes to `context` wre directly reflected in the flow context. The context has been changed to only include the values, and as such updates like this won't be reflected in the flow. Instead, `context['flow_plan']` is now set, which contains a full reference to the flow Plan, allowing for more customisability than previously. Context changes can be mad by modifying `context['flow_plan'].context`.
+
 ## New features
 
 -   User paths