Browse Source

Used :ticket: role in all tickets links.

Sergey Fedoseev 5 years ago
parent
commit
abc51d44af

+ 2 - 2
docs/releases/1.11.txt

@@ -449,8 +449,8 @@ Backwards incompatible changes in 1.11
   dependency for GeoDjango. In older versions, it's only required for SQLite.
 
 * ``contrib.gis.maps`` is removed as it interfaces with a retired version of
-  the Google Maps API and seems to be unmaintained. If you're using it, `let
-  us know <https://code.djangoproject.com/ticket/14284>`_.
+  the Google Maps API and seems to be unmaintained. If you're using it,
+  :ticket:`let us know <14284>`.
 
 * The ``GEOSGeometry`` equality operator now also compares SRID.
 

+ 3 - 5
docs/releases/1.2.1.txt

@@ -3,8 +3,6 @@ Django 1.2.1 release notes
 ==========================
 
 Django 1.2.1 was released almost immediately after 1.2.0 to correct two small
-bugs: one was in the documentation packaging script, the other was a bug_ that
-affected datetime form field widgets when localization was enabled.
-
-.. _bug: https://code.djangoproject.com/ticket/13560
-
+bugs: one was in the documentation packaging script, the other was a
+:ticket:`bug <13560>` that affected datetime form field widgets when
+localization was enabled.

+ 1 - 3
docs/releases/1.2.4.txt

@@ -66,12 +66,10 @@ configuration.
 
 Most users -- even users with multiple-database configurations -- need
 not be concerned about the data loss bug, or the manual configuration of
-:setting:`TEST_DEPENDENCIES`. See the `original problem report`_
+:setting:`TEST_DEPENDENCIES`. See the :ticket:`original problem report <14415>`
 documentation on :ref:`controlling the creation order of test
 databases <topics-testing-creation-dependencies>` for details.
 
-.. _original problem report: https://code.djangoproject.com/ticket/14415
-
 GeoDjango
 =========
 

+ 2 - 2
docs/releases/1.5.1.txt

@@ -10,9 +10,9 @@ compatible with Django 1.5, but includes a handful of fixes.
 The biggest fix is for a memory leak introduced in Django 1.5. Under certain
 circumstances, repeated iteration over querysets could leak memory - sometimes
 quite a bit of it. If you'd like more information, the details are in
-`our ticket tracker`__ (and in `a related issue`__ in Python itself).
+:ticket:`our ticket tracker <19895>` (and in `a related issue`__ in Python
+itself).
 
-__ https://code.djangoproject.com/ticket/19895
 __ https://bugs.python.org/issue17468
 
 If you've noticed memory problems under Django 1.5, upgrading to 1.5.1 should

+ 2 - 3
docs/releases/1.5.txt

@@ -505,7 +505,8 @@ between other versions of ``simplejson``:
 - ``simplejson.JSONEncoder`` gained a ``namedtuple_as_object`` keyword
   argument in version 2.2.
 
-More information on these incompatibilities is available in `ticket #18023`_.
+More information on these incompatibilities is available in
+:ticket:`ticket #18023 <18023#comment:10>`.
 
 The net result is that, if you have installed ``simplejson`` and your code
 uses Django's serialization internals directly -- for instance
@@ -517,8 +518,6 @@ At this point, the maintainers of Django believe that using :mod:`json` from
 the standard library offers the strongest guarantee of backwards-compatibility.
 They recommend to use it from now on.
 
-.. _ticket #18023: https://code.djangoproject.com/ticket/18023#comment:10
-
 String types of hasher method parameters
 ----------------------------------------
 

+ 2 - 3
docs/topics/db/aggregation.txt

@@ -199,9 +199,8 @@ modified using any other ``QuerySet`` operation, including ``filter()``,
 Combining multiple aggregations
 -------------------------------
 
-Combining multiple aggregations with ``annotate()`` will `yield the wrong
-results <https://code.djangoproject.com/ticket/10060>`_ because joins are used
-instead of subqueries:
+Combining multiple aggregations with ``annotate()`` will :ticket:`yield the
+wrong results <10060>` because joins are used instead of subqueries:
 
     >>> book = Book.objects.first()
     >>> book.authors.count()

+ 2 - 3
docs/topics/forms/modelforms.txt

@@ -963,9 +963,8 @@ extra forms displayed.
 
 Also, ``extra=0`` doesn't prevent creation of new model instances as you can
 :ref:`add additional forms with JavaScript <understanding-the-managementform>`
-or send additional POST data. Formsets `don't yet provide functionality
-<https://code.djangoproject.com/ticket/26142>`_ for an "edit only" view that
-prevents creation of new instances.
+or send additional POST data. Formsets :ticket:`don't yet provide functionality
+<26142>` for an "edit only" view that prevents creation of new instances.
 
 If the value of ``max_num`` is greater than the number of existing related
 objects, up to ``extra`` additional blank forms will be added to the formset,

+ 1 - 3
docs/topics/testing/overview.txt

@@ -275,9 +275,7 @@ setting.
 Caches are not cleared after each test, and running "manage.py test fooapp" can
 insert data from the tests into the cache of a live system if you run your
 tests in production because, unlike databases, a separate "test cache" is not
-used. This behavior `may change`_ in the future.
-
-.. _may change: https://code.djangoproject.com/ticket/11505
+used. This behavior :ticket:`may change <11505>` in the future.
 
 Understanding the test output
 -----------------------------