mod: контекстный-процессор теперь передает не только IS_DEBUG, но и ALLOW_TRACKING (куки, что клиент согласился на отлеживание через Google Tag Manager, Яндекс.Метрика и т.п.)

lpon_site/frontend/context_processors.py

@@ -1,27 +1,58 @@
 from django.conf import settings
 from django.http import HttpRequest
 
+# Имя куки, которая ставится клиенту, когда он СОГЛАСИЛСЯ на отслеживание
+# (Google Tag Manager, Яндекс.Метрика и т.п.). Если кука присутствует —
+# предупреждение о трекинге больше не показываем.
+ALLOW_TRACKING_COOKIE_NAME = "allow_tracking"
 
-def is_debug(request: HttpRequest) -> dict:
+
+def site_context(request: HttpRequest) -> dict:
     """
-    Контекст-процессор Django.
+    Общий (универсальный) контекст-процессор Django для всего проекта.
 
     ЗАЧЕМ ЭТО НУЖНО:
-        Автоматически добавляет флаг режима отладки во ВСЕ шаблоны проекта,
-        без необходимости передавать его вручную в контексте каждой вьюхе.
-        Контекстный-процессор необходимо зарегистрировать в settings.py:
-        TEMPLATES['OPTIONS']['context_processors']
+        Автоматически добавляет во ВСЕ шаблоны проекта переменные, которые
+        нужны почти на каждой странице, без необходимости передавать их
+        вручную в контексте каждой вьюхи. Контекст-процессор необходимо
+        зарегистрировать в settings.py: TEMPLATES['OPTIONS']['context_processors']
 
-    ПОЧЕМУ НЕ штатный django.template.context_processors.debug:
+    ПОЧЕМУ ОДИН УНИВЕРСАЛЬНЫЙ ПРОЦЕССОР, А НЕ НЕСКОЛЬКО РАЗНЫХ:
+        И DEBUG-флаг, и флаг согласия на трекинг — это одинаковые по сути
+        "сквозные" данные: маленькие, не завязанные на конкретную вьюху,
+        нужные почти во всех шаблонах (в _base.html). Заводить под каждую
+        такую мелочь отдельный контекст-процессор — это лишний файл и лишняя
+        строка регистрации в settings.py на ровном месте. Если в будущем
+        появится много разнородных "сквозных" переменных — тогда, возможно,
+        стоит разнести их по смыслу (например, отдельно cookies-consent,
+        отдельно debug/env), но пока их всего две — держим вместе.
+
+    ПОЧЕМУ НЕ штатный django.template.context_processors.debug (для IS_DEBUG):
         Штатный context-processor отдаёт переменную `debug` только если
         ОДНОВРЕМЕННО: settings.DEBUG == True И IP клиента входит в
         settings.INTERNAL_IPS (сверяется по request.META['REMOTE_ADDR']).
         В проекте с Docker/reverse-proxy — REMOTE_ADDR может быть не 127.0.0.1,
         а IP шлюза docker-сети, и потому штатный контекстный-процессор ненадёжен.
 
+    ПРО ALLOW_TRACKING:
+        Читаем куку request.COOKIES.get(ALLOW_TRACKING_COOKIE_NAME) — её
+        ставит клиентский JS (или сервер) ПОСЛЕ того, как пользователь
+        согласился с предупреждением об отслеживании (Google Tag Manager,
+        Яндекс.Метрика и т.п.). Если кука присутствует (независимо от её
+        значения — само наличие куки уже означает согласие) — предупреждение
+        в шаблоне больше не показываем, а также можно подключать сами
+        счётчики трекинга ({% if ALLOW_TRACKING %}...{% endif %}).
+
     :return
-        dict: словарь с единственным ключом IS_DEBUG (bool)
-              будет доступен во всех шаблонах как переменная контекста:
+        dict: словарь с ключами:
+            IS_DEBUG (bool) — режим отладки Django (settings.DEBUG);
+            ALLOW_TRACKING (bool) — согласился ли клиент на отслеживание
+                (определяется по наличию куки "allow_tracking").
+        Обе переменные доступны во всех шаблонах:
               {% if IS_DEBUG %}...{% endif %}
+              {% if ALLOW_TRACKING %}...{% endif %}
     """
-    return {"IS_DEBUG": settings.DEBUG}
+    return {
+        "IS_DEBUG": settings.DEBUG,
+        "ALLOW_TRACKING": ALLOW_TRACKING_COOKIE_NAME in request.COOKIES,
+    }