Allow new discipline deletion when it has no users and no collections

[acwhite211]

Fixes #7649

A newly created discipline could not be deleted from the System Configuration Tool even when it had no user-created records. The delete blocker flow was treating discipline owned tree definition data as blockers, so the UI reported the discipline as undeletable even though the intended business rule is narrower.

This PR adds a special case for disciplines in the delete_blockers API. A discipline can be deleted when it has no associated collections and no associated users. The implementation adds discipline specific guard blockers for collections and users, updates discipline deletion to enforce that rule before delete, and detaches discipline owned tree definitions during the delete flow so preloaded tree data does not create false blockers.

Checklist

• Self-review the PR after opening it to make sure the changes look good and
  self-explanatory (or properly documented)
• Add relevant issue to release milestone
• Add pr to documentation list
• Add automated tests

Testing instructions

Empty discipline deletion

• Open the System Configuration Tool as an admin user.
• Create a new discipline under an existing division.
• Without creating any collections for that discipline, open the discipline edit form and click Delete.

Verify:

• The discipline can be deleted successfully.
• The discipline disappears from the hierarchy/tree UI.
• GET /delete_blockers/delete_blockers/discipline/<id>/ returns an empty list.

Discipline with collection

• Create another new discipline and add a collection to it.
• Attempt to delete that discipline.

Verify:

• Deletion is blocked.
• The blocker response/modal includes Collection as the reason.

[acwhite211]

Looking to see if the discipline deletion process can be made faster.

[acwhite211]

Deleting all the schema config and tree records within the discipline was slowing down the discipline deletion request. One solution was to move the deletion process to the worker, similar to what we do for discipline creation. Another solution was using direct SQL queries, instead of using Django to go through and delete all the dependencies. I went ahead and implemented the direct SQL solution to avoid the complications of a delayed deletion through a worker process.

[alesan99]

• The discipline can be deleted successfully.
• The discipline disappears from the hierarchy/tree UI.
• GET /delete_blockers/delete_blockers/discipline/<id>/ returns an empty list.
• Deletion is blocked.
• The blocker response/modal includes Collection as the reason.

---

Disciplines are able to be deleted when expected 👍
I was previously experiencing speed issues, but now deletion happens fast

[bhumikaguptaa]

Verify:

• The discipline can be deleted successfully.
• The discipline disappears from the hierarchy/tree UI.
• GET /delete_blockers/delete_blockers/discipline/<id>/ returns an empty list.

Verify:

• Deletion is blocked.
• The blocker response/modal includes Collection as the reason.

Everything looks good, I was able to delete the discipline in the first part and able to verify deletion is blocked.

[emenslin]

• The discipline can be deleted successfully.
• The discipline disappears from the hierarchy/tree UI.
• GET /delete_blockers/delete_blockers/discipline/<id>/ returns an empty list.

Verify:

• Deletion is blocked.
• The blocker response/modal includes Collection as the reason.

I did get this error a couple times at the beginning but it would go away after refresh and I am no longer able to recreate so I am assuming it is some test panel issue.

Specify 7 Crash Report - 2026-03-18T17_38_16.846Z.txt