Fixed #24100 -- Made the migration signals dispatch its plan and apps.

Thanks Markus for your contribution and Tim for your review.

1 files changed, 34 insertions, 0 deletions

diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
index b7371a1ed0..a3fad2d6ea 100644
--- a/docs/ref/signals.txt
+++ b/docs/ref/signals.txt
@@ -406,6 +406,23 @@ Arguments sent with this signal:
 ``using``
     The alias of database on which a command will operate.
 
+``plan``
+    .. versionadded:: 1.10
+
+    The migration plan that is going to be used for the migration run. While
+    the plan is not public API, this allows for the rare cases when it is
+    necessary to know the plan. A plan is a list of two-tuples with the first
+    item being the instance of a migration class and the second item showing
+    if the migration was rolled back (``True``) or applied (``False``).
+
+``apps``
+    .. versionadded:: 1.10
+
+    An instance of :data:`Apps <django.apps>` containing the state of the
+    project before the migration run. It should be used instead of the global
+    :attr:`apps <django.apps.apps>` registry to retrieve the models you
+    want to perform operations on.
+
 ``post_migrate``
 ----------------
 
@@ -448,6 +465,23 @@ Arguments sent with this signal:
     The database alias used for synchronization. Defaults to the ``default``
     database.
 
+``plan``
+    .. versionadded:: 1.10
+
+    The migration plan that was used for the migration run. While the plan is
+    not public API, this allows for the rare cases when it is necessary to
+    know the plan. A plan is a list of two-tuples with the first item being
+    the instance of a migration class and the second item showing if the
+    migration was rolled back (``True``) or applied (``False``).
+
+``apps``
+    .. versionadded:: 1.10
+
+    An instance of :data:`Apps <django.apps.apps>` containing the state of the
+    project after the migration run. It should be used instead of the global
+    :attr:`apps <django.apps.apps>` registry to retrieve the models you
+    want to perform operations on.
+
 For example, you could register a callback in an
 :class:`~django.apps.AppConfig` like this::