Refs #31670 -- Removed whitelist/blacklist terminology in docs and comments.

django/contrib/gis/db/backends/base/operations.py

@@ -36,7 +36,7 @@ class BaseSpatialOperations:
     # match; used in spatial_function_name().
     function_names = {}
 
-    # Blacklist/set of known unsupported functions of the backend
+    # Set of known unsupported functions of the backend
     unsupported_functions = {
         'Area', 'AsGeoJSON', 'AsGML', 'AsKML', 'AsSVG', 'Azimuth',
         'BoundingCircle', 'Centroid', 'Difference', 'Distance', 'Envelope',

docs/releases/1.1.3.txt

@@ -45,6 +45,6 @@ password hashes.
 To remedy this, ``django.contrib.admin`` will now validate that
 querystring lookup arguments either specify only fields on the model
 being viewed, or cross relations which have been explicitly
-whitelisted by the application developer using the pre-existing
+allowed by the application developer using the pre-existing
 mechanism mentioned above. This is backwards-incompatible for any
 users relying on the prior ability to insert arbitrary lookups.

docs/releases/1.2.4.txt

@@ -45,7 +45,7 @@ password hashes.
 To remedy this, ``django.contrib.admin`` will now validate that
 querystring lookup arguments either specify only fields on the model
 being viewed, or cross relations which have been explicitly
-whitelisted by the application developer using the pre-existing
+allowed by the application developer using the pre-existing
 mechanism mentioned above. This is backwards-incompatible for any
 users relying on the prior ability to insert arbitrary lookups.
 

docs/spelling_wordlist

@@ -781,7 +781,6 @@ viewable
 virtualized
 Weblog
 whitelist
-whitelisted
 whitespace
 whitespaces
 whizbang

docs/topics/forms/modelforms.txt

@@ -420,7 +420,7 @@ fields, especially when new fields are added to a model. Depending on how the
 form is rendered, the problem may not even be visible on the web page.
 
 The alternative approach would be to include all fields automatically, or
-blacklist only some. This fundamental approach is known to be much less secure
+remove only some. This fundamental approach is known to be much less secure
 and has led to serious exploits on major websites (e.g. `GitHub
 <https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation>`_).
 

docs/topics/security.txt

@@ -261,7 +261,7 @@ User-uploaded content
      from something like ``usercontent-example.com``. It's *not* sufficient to
      serve content from a subdomain like ``usercontent.example.com``.
 
-  #. Beyond this, applications may choose to define a whitelist of allowable
+  #. Beyond this, applications may choose to define a list of allowable
      file extensions for user uploaded files and configure the web server
      to only serve such files.
 

tests/admin_views/tests.py

@@ -791,7 +791,7 @@ class AdminViewBasicTest(AdminViewBasicTestCase):
         self.assertEqual(response.status_code, 200)
 
         # Filters should be allowed if they involve a local field without the
-        # need to whitelist them in list_filter or date_hierarchy.
+        # need to allow them in list_filter or date_hierarchy.
         response = self.client.get("%s?age__gt=30" % reverse('admin:admin_views_person_changelist'))
         self.assertEqual(response.status_code, 200)