---
title: "Signaler"
version: 6.1
locale: sv
source: https://docs.djangoproject.com/sv/6.1/ref/signals/
canonical: https://djangodocs.dev/sv/6.1/ref/signals/
---
# Signaler

En lista över alla signaler som Django skickar. Alla inbyggda signaler skickas med hjälp av [`send()`](/sv/6.1/topics/signals/#django.dispatch.Signal.send)-metoden.

> **See also**
>
> Se dokumentationen för [signal dispatcher](/sv/6.1/topics/signals/) för information om hur du registrerar dig för och tar emot signaler.
>
> Ramverket [authentication](/sv/6.1/topics/auth/) sänder [signaler när en användare är inloggad/utloggad](/sv/6.1/ref/contrib/auth/#topics-auth-signals).

## Modellsignaler

Modulen [`django.db.models.signals`](#module-django.db.models.signals) definierar en uppsättning signaler som skickas av modellsystemet.

> **Warning**
>
> Signaler kan göra din kod svårare att underhålla. Överväg att implementera en hjälpmetod på en [custom manager](/sv/6.1/topics/db/managers/#custom-managers), för att både uppdatera dina modeller och utföra ytterligare logik, eller annars [overriding model methods](/sv/6.1/topics/db/models/#overriding-model-methods) innan du använder modellsignaler.

> **Warning**
>
> Många av dessa signaler skickas av olika modellmetoder som `__init__()` eller [`save()`](/sv/6.1/ref/models/instances/#django.db.models.Model.save) som du kan åsidosätta i din egen kod.
>
> Om du åsidosätter dessa metoder i din modell måste du anropa den överordnade klassens metoder för att dessa signaler ska skickas.
>
> Note also that Django stores signal handlers as weak references by default,
> so if your handler is a local function, it may be garbage collected. To
> prevent this, pass `weak=False` when you call the signal’s
> [`connect()`](/sv/6.1/topics/signals/#django.dispatch.Signal.connect).

> **Note**
>
> Modellsignaler `avsändare`-modeller kan refereras till när man ansluter en mottagare genom att ange dess fullständiga applikationsetikett. Till exempel: kan en `Question`-modell som definieras i `polls`-applikationen refereras som `'polls.Question'`. Denna typ av referens kan vara ganska praktisk när man hanterar cirkulära importberoenden och utbytbara modeller.

### `pre_init`

#### `django.db.models.signals.pre_init`

När du instansierar en Django-modell skickas den här signalen i början av modellens metod `__init__()`.

Argument som skickas med denna signal:

**avsändare**

  Den modellklass som just fått en instans skapad.

**`args`**

  En lista med positionella argument som skickas till `__init__()`.

**`kwargs`**

  En ordlista med nyckelordsargument som skickas till `__init__()`.

Till exempel: har [tutorial](/sv/6.1/intro/tutorial02/) den här raden:

```
q = Question(question_text="What's new?", pub_date=timezone.now())
```

De argument som skickas till en [`pre_init`](#django.db.models.signals.pre_init) hanterare skulle vara:

| Argument | Värde |
| --- | --- |
| avsändare | `Fråga` (själva klassen) |
| `args` | `[]` (en tom lista eftersom det inte fanns några positionella argument som skickades till `__init__()`)) |
| `kwargs` | `{'question_text': "What's new?",`<br>`'pub_date': datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=datetime.UTC)}` |

### `post_init`

#### `django.db.models.signals.post_init`

Som pre\_init, men den här skickas när metoden `__init__()` är klar.

Argument som skickas med denna signal:

**avsändare**

  Som ovan: modellklassen som just har fått en instans skapad.

**`instans`**

  Den faktiska instansen av den modell som just har skapats.

  > **Note**
  >
  > [`instance._state`](/sv/6.1/ref/models/instances/#django.db.models.Model._state) ställs inte in innan signalen `post_init` skickas, så attributen `_state` har alltid sina standardvärden. Till exempel: är `_state.db` `None`.

> **Warning**
>
> Av prestandaskäl bör du inte utföra frågor i mottagare av signalerna `pre_init` eller `post_init` eftersom de skulle utföras för varje instans som returneras under iterationen av queryset.

### `pre_save`

#### `django.db.models.signals.pre_save`

Detta skickas i början av en modells [`save()`](/sv/6.1/ref/models/instances/#django.db.models.Model.save)-metod.

Argument som skickas med denna signal:

**avsändare**

  Modellklassen.

**`instans`**

  Den faktiska instans som sparas.

**`raw`**

  En boolean; `True` om modellen sparas exakt som den presenteras (t.ex. vid laddning av en [fixture](/sv/6.1/topics/db/fixtures/#fixtures-explanation)). Man bör inte fråga/ändra andra poster i databasen eftersom databasen kanske inte är i ett konsekvent tillstånd ännu.

**`använder`**

  Det databasalias som används.

**`uppdatera_fält`**

  Den uppsättning fält som ska uppdateras enligt [`Model.save()`](/sv/6.1/ref/models/instances/#django.db.models.Model.save), eller `None` om `update_fields` inte skickades till `save()`.

### `post_save`

#### `django.db.models.signals.post_save`

Som [`pre_save`](#django.db.models.signals.pre_save), men skickas i slutet av metoden [`save()`](/sv/6.1/ref/models/instances/#django.db.models.Model.save).

Argument som skickas med denna signal:

**avsändare**

  Modellklassen.

**`instans`**

  Den faktiska instans som sparas.

**`skapad`**

  En boolean; `True` om en ny post skapades.

**`raw`**

  En boolean; `True` om modellen sparas exakt som den presenteras (t.ex. vid laddning av en [fixture](/sv/6.1/topics/db/fixtures/#fixtures-explanation)). Man bör inte fråga/ändra andra poster i databasen eftersom databasen kanske inte är i ett konsekvent tillstånd ännu.

**`använder`**

  Det databasalias som används.

**`uppdatera_fält`**

  Den uppsättning fält som ska uppdateras enligt [`Model.save()`](/sv/6.1/ref/models/instances/#django.db.models.Model.save), eller `None` om `update_fields` inte skickades till `save()`.

### `pre_delete`

#### `django.db.models.signals.pre_delete`

Skickas i början av en models [`delete()`](/sv/6.1/ref/models/instances/#django.db.models.Model.delete)-metod och en querysets [`delete()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.delete)-metod.

Argument som skickas med denna signal:

**avsändare**

  Modellklassen.

**`instans`**

  Den faktiska instans som raderas.

**`använder`**

  Det databasalias som används.

**`ursprung`**

  Den instans av `Model` eller `QuerySet` från vilken borttagningen skedde, dvs. den instans vars metod `delete()` anropades.

### `post_delete`

#### `django.db.models.signals.post_delete`

Som [`pre_delete`](#django.db.models.signals.pre_delete), men skickas i slutet av en models [`delete()`](/sv/6.1/ref/models/instances/#django.db.models.Model.delete)-metod och en querysets [`delete()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.delete)-metod.

Argument som skickas med denna signal:

**avsändare**

  Modellklassen.

**`instans`**

  Den faktiska instans som raderas.

  Observera att objektet inte längre kommer att finnas i databasen, så var mycket försiktig med vad du gör med denna instans.

**`använder`**

  Det databasalias som används.

**`ursprung`**

  Den instans av `Model` eller `QuerySet` från vilken borttagningen skedde, dvs. den instans vars metod `delete()` anropades.

### `m2m_changed`

#### `django.db.models.signals.m2m_changed`

Skickas när en [`ManyToManyField`](/sv/6.1/ref/models/fields/#django.db.models.ManyToManyField) ändras på en modellinstans. Strängt taget är detta inte en modellsignal eftersom den skickas av [`ManyToManyField`](/sv/6.1/ref/models/fields/#django.db.models.ManyToManyField), men eftersom den kompletterar [`pre_save`](#django.db.models.signals.pre_save)/[`post_save`](#django.db.models.signals.post_save) och [`pre_delete`](#django.db.models.signals.pre_delete)/[`post_delete`](#django.db.models.signals.post_delete) när det gäller att spåra ändringar i modeller, inkluderas den här.

Argument som skickas med denna signal:

**avsändare**

  Den mellanliggande modellklassen som beskriver [`ManyToManyField`](/sv/6.1/ref/models/fields/#django.db.models.ManyToManyField). Denna klass skapas automatiskt när ett many-to-many-fält definieras; du kan komma åt den med hjälp av attributet `through` på many-to-many-fältet.

**`instans`**

  Den instans vars many-to-many-relation uppdateras. Detta kan vara en instans av `sender`, eller av den klass som [`ManyToManyField`](/sv/6.1/ref/models/fields/#django.db.models.ManyToManyField) är relaterad till.

**`handling`**

  En sträng som anger vilken typ av uppdatering som görs av relationen. Detta kan vara något av följande:

  **`"pre_add"`**

    Skickas *innan* ett eller flera objekt läggs till i relationen.

  **`"post_add"`**

    Skickas *efter* att ett eller flera objekt har lagts till i relationen.

  **`"pre_remove"`**

    Skickas *innan* ett eller flera objekt tas bort från relationen.

  **`"post_remove"`**

    Skickas *efter* att ett eller flera objekt har tagits bort från relationen.

  **`"pre_clear"`**

    Skickas *innan* relationen är avklarad.

  **`"post_clear"`**

    Skickas *efter* att relationen är avklarad.

**`omvänd`**

  Anger vilken sida av relationen som uppdateras (dvs. om det är den framåtriktade eller omvända relationen som ändras).

**`modell`**

  Klassen för de objekt som läggs till i, tas bort från eller rensas från relationen.

**`pk_set`**

  För åtgärderna `pre_add` och `post_add` är detta en uppsättning primärnyckelvärden som kommer att läggas till, eller har lagts till, i relationen. Detta kan vara en delmängd av de värden som lämnats in för att läggas till, eftersom inmatningar måste filtrera befintliga värden för att undvika ett `IntegrityError` i databasen.

  För åtgärderna `pre_remove` och `post_remove` är detta en uppsättning primärnyckelvärden som skickades in för att tas bort från relationen. Detta är inte beroende av om värdena faktiskt kommer att tas bort eller har tagits bort. I synnerhet kan icke-existerande värden skickas in och visas då i `pk_set`, även om de inte har någon effekt på databasen.

  För åtgärderna `pre_clear` och `post_clear` är detta `None`.

**`använder`**

  Det databasalias som används.

`raw`

> > **New in Django 6.1**
>
> En boolean; `True` om modellen sparas exakt som den presenteras (t.ex. vid laddning av en [fixture](/sv/6.1/topics/db/fixtures/#fixtures-explanation)). Man bör inte fråga/ändra andra poster i databasen eftersom databasen kanske inte är i ett konsekvent tillstånd ännu.

Till exempel:, om en `Pizza` kan ha flera `Topping`-objekt, modellerade så här:

```
class Topping(models.Model):
    # ...
    pass

class Pizza(models.Model):
    # ...
    toppings = models.ManyToManyField(Topping)
```

Om vi ansluter en hanterare så här:

```
from django.db.models.signals import m2m_changed

def toppings_changed(sender, **kwargs):
    # Do something
    pass

m2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)
```

och gjorde sedan något liknande:

```pycon
>>> p = Pizza.objects.create(...)
>>> t = Topping.objects.create(...)
>>> p.toppings.add(t)
```

de argument som skickas till en [`m2m_changed`](#django.db.models.signals.m2m_changed) hanterare (`toppings_changed` i exemplet ovan) skulle vara:

| Argument | Värde |
| --- | --- |
| avsändare | `Pizza.toppings.through` (den mellanliggande m2m-klassen) |
| `instans` | `p` (instansen `Pizza` som modifieras) |
| `handling` | `"pre_add"` (följt av en separat signal med `"post_add"`) |
| `omvänd` | `False` (`Pizza` innehåller [`ManyToManyField`](/sv/6.1/ref/models/fields/#django.db.models.ManyToManyField), så detta anrop ändrar den framåtriktade relationen) |
| `modell` | `Topping` (klassen för de objekt som läggs till `Pizza`) |
| `pk_set` | `{t.id}` (eftersom endast `Topping t` lades till i relationen) |
| `använder` | `"default"` (eftersom standardroutern skickar skrivningar hit) |
| `raw` | `False` (since it is not loaded from a fixture) |

Och om vi då skulle göra något sådant här:

```pycon
>>> t.pizza_set.remove(p)
```

de argument som skickas till en [`m2m_changed`](#django.db.models.signals.m2m_changed) hanterare skulle vara:

| Argument | Värde |
| --- | --- |
| avsändare | `Pizza.toppings.through` (den mellanliggande m2m-klassen) |
| `instans` | `t` (instansen `Topping` som modifieras) |
| `handling` | `"pre_remove"` (följt av en separat signal med `"post_remove"`) |
| `omvänd` | `True` (`Pizza` innehåller [`ManyToManyField`](/sv/6.1/ref/models/fields/#django.db.models.ManyToManyField), så detta anrop modifierar den omvända relationen) |
| `modell` | `Pizza` (klassen för de objekt som tagits bort från `Topping`) |
| `pk_set` | `{p.id}` (eftersom endast `Pizza p` togs bort från relationen) |
| `använder` | `"default"` (eftersom standardroutern skickar skrivningar hit) |
| `raw` | `False` (since it is not loaded from a fixture) |

### `klass_förberedd`

#### `django.db.models.signals.class_prepared`

Skickas när en modellklass har ”förberetts”, det vill säga när en modell har definierats och registrerats i Djangos modellsystem. Django använder denna signal internt; den används vanligtvis inte i tredjepartsapplikationer.

Eftersom den här signalen skickas under appregisterpopulationsprocessen och [`AppConfig.ready()`](/sv/6.1/ref/applications/#django.apps.AppConfig.ready) körs efter att appregistret är helt populerat, kan mottagare inte anslutas i den metoden. En möjlighet är att ansluta dem till `AppConfig.__init__()` istället, och se till att inte importera modeller eller utlösa anrop till appregistret.

Argument som skickas med denna signal:

**avsändare**

  Modellklassen som just var förberedd.

## Ledningens signaler

Signaler skickade av [django-admin](/sv/6.1/ref/django-admin/).

### `pre_migrate`

#### `django.db.models.signals.pre_migrate`

Skickas av kommandot [`migrate`](/sv/6.1/ref/django-admin/#django-admin-migrate) innan det börjar installera ett program. Det sänds inte ut för program som saknar en `models`-modul.

Argument som skickas med denna signal:

**avsändare**

  En [`AppConfig`](/sv/6.1/ref/applications/#django.apps.AppConfig)-instans för den applikation som ska migreras/synkroniseras.

**`app_config`**

  Samma som `avsändare`.

**`verbosity`**

  Anger hur mycket information `manage.py` skriver ut på skärmen. Se flaggan [`--verbosity`](/sv/6.1/ref/django-admin/#cmdoption-verbosity) för mer information.

  Funktioner som lyssnar efter [`pre_migrate`](#django.db.models.signals.pre_migrate) bör justera vad de matar ut på skärmen baserat på värdet av detta argument.

**`interaktiv`**

  Om `interactive` är `True` är det säkert att uppmana användaren att mata in saker på kommandoraden. Om `interactive` är `False` ska funktioner som lyssnar på denna signal inte försöka uppmana till något.

  Till exempel: uppmanar [`django.contrib.auth`](/sv/6.1/topics/auth/#module-django.contrib.auth)-appen bara till att skapa en superanvändare när `interactive` är `True`.

**`stdout`**

  Ett strömliknande objekt som kan användas för att omdirigera verbose-utdata.

**`använder`**

  Aliaset för den databas som ett kommando ska användas på.

**`plan`**

  Den migreringsplan som kommer att användas för migreringskörningen. Planen är inte ett publikt API, men detta möjliggör de sällsynta fall då det är nödvändigt att känna till planen. En plan är en lista med 2-tuples där det första objektet är en instans av en migreringsklass och det andra objektet visar om migreringen rullades tillbaka (`True`) eller tillämpades (`False`).

**`apps`**

  En instans av [`Apps`](/sv/6.1/ref/applications/#module-django.apps) som innehåller projektets tillstånd före migreringskörningen. Den bör användas i stället för det globala registret [`apps`](/sv/6.1/ref/applications/#django.apps.apps) för att hämta de modeller som du vill utföra åtgärder på.

### `post_migrera`

#### `django.db.models.signals.post_migrate`

Skickas i slutet av kommandona [`migrate`](/sv/6.1/ref/django-admin/#django-admin-migrate) (även om inga migreringar körs) och [`flush`](/sv/6.1/ref/django-admin/#django-admin-flush). Det sänds inte ut för program som saknar en `models`-modul.

Den som hanterar den här signalen får inte ändra databasscheman eftersom det kan leda till att kommandot [`flush`](/sv/6.1/ref/django-admin/#django-admin-flush) misslyckas om det körs under kommandot [`migrate`](/sv/6.1/ref/django-admin/#django-admin-migrate).

Argument som skickas med denna signal:

**avsändare**

  En [`AppConfig`](/sv/6.1/ref/applications/#django.apps.AppConfig)-instans för den applikation som just installerades.

**`app_config`**

  Samma som `avsändare`.

**`verbosity`**

  Anger hur mycket information `manage.py` skriver ut på skärmen. Se flaggan [`--verbosity`](/sv/6.1/ref/django-admin/#cmdoption-verbosity) för mer information.

  Funktioner som lyssnar på [`post_migrate`](#django.db.models.signals.post_migrate) bör justera vad de matar ut på skärmen baserat på värdet av detta argument.

**`interaktiv`**

  Om `interactive` är `True` är det säkert att uppmana användaren att mata in saker på kommandoraden. Om `interactive` är `False` ska funktioner som lyssnar på denna signal inte försöka uppmana till något.

  Till exempel: uppmanar [`django.contrib.auth`](/sv/6.1/topics/auth/#module-django.contrib.auth)-appen bara till att skapa en superanvändare när `interactive` är `True`.

**`stdout`**

  Ett strömliknande objekt som kan användas för att omdirigera verbose-utdata.

**`använder`**

  Det databasalias som används för synkronisering. Standard är databasen `default`.

**`plan`**

  Den migreringsplan som användes för migreringskörningen. Planen är inte ett offentligt API, men detta möjliggör de sällsynta fall då det är nödvändigt att känna till planen. En plan är en lista med 2-tuples där det första objektet är en instans av en migreringsklass och det andra objektet visar om migreringen rullades tillbaka (`True`) eller tillämpades (`False`).

**`apps`**

  En instans av [`Apps`](/sv/6.1/ref/applications/#django.apps.apps) som innehåller projektets tillstånd efter migreringskörningen. Den bör användas i stället för det globala registret [`apps`](/sv/6.1/ref/applications/#django.apps.apps) för att hämta de modeller som du vill utföra åtgärder på.

Du kan till exempel registrera en återuppringning i en [`AppConfig`](/sv/6.1/ref/applications/#django.apps.AppConfig) så här:

```
from django.apps import AppConfig
from django.db.models.signals import post_migrate

def my_callback(sender, **kwargs):
    # Your specific logic here
    pass

class MyAppConfig(AppConfig):
    ...

    def ready(self):
        post_migrate.connect(my_callback, sender=self)
```

> **Note**
>
> Om du anger en [`AppConfig`](/sv/6.1/ref/applications/#django.apps.AppConfig)-instans som avsändarargument, se till att signalen är registrerad i [`ready()`](/sv/6.1/ref/applications/#django.apps.AppConfig.ready). `AppConfig` återskapas för tester som körs med en modifierad uppsättning av [`INSTALLED_APPS`](/sv/6.1/ref/settings/#std-setting-INSTALLED_APPS) (t.ex. när inställningar åsidosätts) och sådana signaler bör anslutas för varje ny `AppConfig`-instans.

## Signaler för begäran/svar

Signaler som skickas av kärnramverket när en begäran behandlas.

> **Warning**
>
> Signaler kan göra din kod svårare att underhålla. Överväg [använda ett mellanprogram](/sv/6.1/topics/http/middleware/) innan du använder request/response-signaler.

### `begäran_startad`

#### `django.core.signals.request_started`

Skickas när Django börjar bearbeta en HTTP-begäran.

Argument som skickas med denna signal:

**avsändare**

  Hanteringsklassen - t.ex. `django.core.handlers.wsgi.WsgiHandler` \- som hanterade begäran.

**omgivning**

  Den ordbok för ”miljö” som tillhandahålls för begäran.

### ”Begäran\_avslutad

#### `django.core.signals.request_finished`

Skickas när Django avslutar leveransen av ett HTTP-svar till klienten.

Argument som skickas med denna signal:

**avsändare**

  Hanterarklassen, som ovan.

### har fått undantag från begäran

#### `django.core.signals.got_request_exception`

Denna signal skickas när Django stöter på ett undantag under behandlingen av en inkommande HTTP-begäran.

Argument som skickas med denna signal:

**avsändare**

  Oanvänd (alltid `None`).

**`begäran`**

  Objektet [`HttpRequest`](/sv/6.1/ref/request-response/#django.http.HttpRequest).

## Test av signaler

Signaler skickas endast när [kör tester](/sv/6.1/topics/testing/overview/#running-tests).

### `inställning_ändrad`

#### `django.test.signals.setting_changed`

Denna signal skickas när värdet på en inställning ändras via kontexthanteraren `django.test.TestCase.settings()` eller [`django.test.override_settings()`](/sv/6.1/topics/testing/tools/#django.test.override_settings) dekorator/kontexthanteraren.

Det skickas faktiskt två gånger: när det nya värdet tillämpas (”setup”) och när det ursprungliga värdet återställs (”teardown”). Använd argumentet `enter` för att skilja mellan de två.

Du kan också importera den här signalen från `django.core.signals` för att undvika import från `django.test` i situationer som inte är test.

Argument som skickas med denna signal:

**avsändare**

  Inställningshanteraren.

**`inställning`**

  Namnet på inställningen.

**`värde`**

  Värdet på inställningen efter ändringen. För inställningar som ursprungligen inte finns, i fasen ”teardown”, är `value` `None`.

**`enter`**

  En boolean; `True` om inställningen tillämpas, `False` om den återställs.

### `template_rendered`

#### `django.test.signals.template_rendered`

Skickas när testsystemet renderar en mall. Denna signal sänds inte ut under normal drift av en Django-server - den är endast tillgänglig under testning.

Argument som skickas med denna signal:

**avsändare**

  Objektet [`Template`](/sv/6.1/ref/templates/api/#django.template.Template) som renderades.

**`mall`**

  Samma som avsändaren

**`kontext`**

  Den [`Context`](/sv/6.1/ref/templates/api/#django.template.Context) med vilken mallen renderades.

## Databas-omslag

Signaler som skickas av databasomslaget när en databasanslutning initieras.

### `anslutning_skapad`

#### `django.db.backends.signals.connection_created`

Sent when the database wrapper makes the initial connection to the
database. This is particularly useful if you’d like to send any post
connection commands to the SQL backend.

Argument som skickas med denna signal:

**avsändare**

  Databasens omslagsklass - t.ex. `django.db.backends.postgresql.DatabaseWrapper` eller `django.db.backends.mysql.DatabaseWrapper`, etc.

**`anslutning`**

  Den databasanslutning som öppnades. Detta kan användas i en konfiguration med flera databaser för att skilja på anslutningssignaler från olika databaser.

## Tasks signals

> **New in Django 6.0**

Signals sent by the [tasks](/sv/6.1/ref/tasks/) framework.

### `task_enqueued`

#### `django.tasks.signals.task_enqueued`

Sent once a Task has been enqueued.

Argument som skickas med denna signal:

**avsändare**

  The backend class which the Task was enqueued on to.

**`task_result`**

  The enqueued [`TaskResult`](/sv/6.1/ref/tasks/#django.tasks.TaskResult).

### `task_started`

#### `django.tasks.signals.task_started`

Sent when a Task has started executing.

Argument som skickas med denna signal:

**avsändare**

  The backend class which the Task was enqueued on to.

**`task_result`**

  The started [`TaskResult`](/sv/6.1/ref/tasks/#django.tasks.TaskResult).

### `task_finished`

#### `django.tasks.signals.task_finished`

Sent once a Task has finished executing, successfully or otherwise.

Argument som skickas med denna signal:

**avsändare**

  The backend class which the Task was enqueued on to.

**`task_result`**

  The finished [`TaskResult`](/sv/6.1/ref/tasks/#django.tasks.TaskResult).