The ProtectedError errors must be raised during the collection phase and not the deletion one.

For ProtectedError to be raised during the collection phase, we need to know whether a call is the top-level call or not. Recursive calls to collect() cannot raise when they find restricted objects because those objects may be found through a different path by the caller. That's why I added the fail_on_restricted argument. Please let me know if this is acceptable.

Still need to fix the documentation build errors, and add another test case for the above potential problem about recursive calls not raising ProtectedError, so this is not ready for another review yet.

@izquierdo, do you plan to return to this soon or should we close it?

I'm sorry for temporarily suspending work on this, I will return to it soon. Please do not close.

Thank you for the review. Working on the extra requested tests and other comments, and will also rebase this on top of the latest.

Gentle reminder @izquierdo, will you be picking this one up again?

just 2 flake8 errors

I believe all comments have been addressed now.

This is something that should be discussed on the mailing list, but would it make sense to have a RestrictedError here for RESTRICT in place of ProtectedError?

Changed to RestrictedError but should I still open up a discussion in the mailing list?

@izquierdo I don't think that discussion is necessary. Please uncheck "Patch needs improvement" flag if you believe that all comments have been addressed.

Thank you for the review, added tests and addressed comments

Thanks for updates 👍 Can you check tests failures on MySQL and MariaDB? (delete.tests.OnDeleteTests.test_restrict_generic_foreign_key_and_no_fast_delete).

Please don't use force-push.

I'm extremely sorry, I rebased on master and completely missed this comment before force-pushing. Please push again and I'll handle the comments from there.

Recovered your commit and did one final force push to get back there

@izquierdo Only three comments left:

• Fixed #27272 -- Added an on_delete RESTRICT handler to allow cascading deletions while protecting direct ones. #7364 (comment)
• Fixed #27272 -- Added an on_delete RESTRICT handler to allow cascading deletions while protecting direct ones. #7364 (comment)
• Fixed #27272 -- Added an on_delete RESTRICT handler to allow cascading deletions while protecting direct ones. #7364 (comment)

@izquierdo Can you take a look at my comments? ☝️

Addressed comments

test_restrict_indirect_cascade Do we need this? I'm not sure how this path is different from test_restrict_path_cascade_indirect.

The main difference is that there's an extra model between the object from which deletion started and the restricted object, instead of a single model with two instances. This was added as requested earlier. Other than that the diamond structure is the same. I do believe it's better to test both situations but this can be removed if you disagree.

Another difference is that test_restrict_indirect_cascade tries to delete the intermediate model (B1) whereas test_restrict_path_cascade_indirect doesn't try to (its intermediate model is R). But this scenario is tested in test_restrict too so I don't think it's necessary to add it to test_restrict_path_cascade_indirect if we end up removing test_restrict_indirect_cascade.

test fail when I add ParentA on MySQL/MariaDB: django.db.utils.IntegrityError: (1451, 'Cannot delete ....

This happens because of a missing dependency and is also fixed by b1a586f

Do we know why we need a special workaround for MySQL/MariaDB? maybe it's related with the fact that constraints checks cannot be deferred, in this case we should use connections[using].features.can_defer_constraint_checks. Otherwise, we probably need another database feature.

This comment suggests that the sorting is indeed because constraint checks cannot be deferred:

But it's not just a workaround for that -- it's also used to dispatch signals in the right order. If you apply the following patch to master:

diff --git a/django/db/models/deletion.py b/django/db/models/deletion.py
index 62afff1f50..6fa9e53bdc 100644
--- a/django/db/models/deletion.py
+++ b/django/db/models/deletion.py
@@ -298,7 +298,8 @@ class Collector:
         # if possible, bring the models in an order suitable for databases that
         # don't support transactions or cannot defer constraint checks until the
         # end of a transaction.
-        self.sort()
+        if not connections[self.using].features.can_defer_constraint_checks:
+            self.sort()
         # number of objects deleted for each model label
         deleted_counter = Counter()

then you get failures on test_relational_post_delete_signals_happen_before_parent_object and test_deletion_order when not using MySQL/MariaDB.

Should I update the docstring on sort() to clarify this?

The latest comments are addressed, please let me know what to do regarding:

• Removal of test_restrict_indirect_cascade
• Docstring on sort()
• Any other comments

Thank you for the review, I appreciate your thoroughness.

@izquierdo Thanks for your patience and explanations 🥇 . We're ready to merge 🚀 🎉