Django Admin: administracija bez nepotrebnog razvoja

Razvoj poslovne aplikacije često počinje jednostavnim zahtjevom: zaposlenicima treba mjesto na kojem mogu unositi, pretraživati i uređivati podatke. Izrada cijelog administracijskog sučelja od nule može uzeti velik dio vremena. Django Admin omogućuje da do upotrebljivog internog alata dođemo brže — pod uvjetom da razumijemo za što je namijenjen.

Što je Django Admin?

Django Admin automatski gradi sučelje za upravljanje modelima nakon što ih registriramo. Korisnici s odgovarajućim dozvolama mogu pregledavati zapise, dodavati nove, mijenjati postojeće i koristiti pretragu ili filtre. Uz malo konfiguracije moguće je dobiti preglednu administraciju klijenata, događaja, artikala ili dokumenata.

To ne znači da administrator treba biti jedino sučelje poslovnog sustava. Django Admin prvenstveno je namijenjen internom osoblju koje razumije podatke i postupke. Za krajnje korisnike često je bolji posebno oblikovan portal s manje mogućnosti i jasnije vođenim koracima.

Korisne prilagodbe u nekoliko redaka

Primjer modela Zahtjev može sadržavati broj, podnositelja, datum i status. U ModelAdmin konfiguraciji definiramo stupce popisa, filtriranje po statusu i pretraživanje po broju. Ako postoji odnos s većim brojem povezanih zapisa, vrijedi odabrati prikladno polje za pretragu umjesto dugog padajućeg izbornika.

from django.contrib import admin
from .models import Zahtjev

@admin.register(Zahtjev)
class ZahtjevAdmin(admin.ModelAdmin):
    list_display = ("broj", "status", "datum")
    list_filter = ("status",)
    search_fields = ("broj",)

Ovaj primjer pretpostavlja da model ima navedena polja. Sličnom konfiguracijom mogu se dodati grupe polja, povezani zapisi i administracijske akcije. Svaka prilagodba treba služiti konkretnom načinu rada, ne samo pokazati mogućnosti frameworka.

Ovlasti su važnije od izgleda

To što netko može otvoriti administraciju ne znači da smije vidjeti sve zapise. Django nudi modelsku razinu dozvola, ali za ograničavanje pojedinih zapisa često treba dodatna logika, primjerice filtriranje get_queryset() i provjere u has_view_permission() ili has_change_permission().

Posebnu pažnju zaslužuju masovne akcije: korisnik koji ne može otvoriti pojedini zapis ne bi smio promijeniti deset zapisa odjednom zbog propusta u provjeri. Uloge testirajte stvarnim korisničkim računima, uključujući one s najmanjim ovlastima.

Kada iz administracije prijeći u vlastito sučelje?

Ako zaposlenici obrađuju zahtjeve korak po korak, trebaju sučelje prilagođeno procesu. Dobar primjer je recepcija koja ne bi trebala vidjeti sve tehničke stupce modela, nego jednostavan obrazac za rezervaciju i potvrdu. Tada se poslovni dio prebacuje u zasebne Django viewove i predloške, dok Admin ostaje alat za održavanje i povremene korekcije.

Takav razvoj nije bacanje prethodnog rada. Modeli, pravila, validacija i poslovne usluge ostaju korisni. Mijenja se samo način na koji zaposlenik koristi aplikaciju.

Praktično pravilo

Za prvu internu verziju testirajte Django Admin kako biste brzo provjerili strukturu podataka i korisničke potrebe. Ne koristite ga kao opravdanje za preskakanje dizajna ovlasti, evidencije promjena ili korisničkog testiranja. Prava ušteda dolazi kada ranije dobijete funkcionalan alat, a kasnije bezbolno izgradite sučelje ondje gdje ono stvarno treba.

Kada administracija postane poslovni proces

Zamislimo evidenciju internih dokumenata. U početnoj verziji djelatnik kroz Django Admin unosi naslov, kategoriju, datum i datoteku. Nakon nekog vremena pojavljuje se zahtjev za odobravanjem prije objave, pregledom dokumenata po odjelima i javnim prikazom odabranih zapisa. Django Admin i dalje može služiti održavanju, ali svakodnevni postupak odobravanja zaslužuje vlastito sučelje. To se može razviti nad postojećim modelima bez bacanja početnog rada.

Posebno je važno razlikovati pravo uređivanja od prava objave. Interni korisnik ne mora biti ovlašten učiniti dokument javnim, čak i ako može ispraviti njegov naslov. Takva pravila treba provjeravati na serveru, uključujući kod administracijskih akcija.

Česta pitanja

Je li Admin siguran za više korisnika? Može biti ako su pristupi i ovlasti pravilno definirani. Samo uključivanje korisničke prijave nije dovoljno za ograničavanje pojedinih zapisa.

Može li Admin zamijeniti sav razvoj? Za internu evidenciju ponekad može. Za specifične procese i vanjske korisnike često je primjerenije oblikovati zasebne ekrane.

Treba li Admin javno izlagati? Pristup treba dodatno zaštititi i ograničiti prema procjeni rizika. Administracijska prijava nije namijenjena anonimnim posjetiteljima.

Plan za prvu administracijsku verziju

Prije izrade lijepog korisničkog portala često se isplati provjeriti osnovne podatke kroz jednostavnu internu administraciju. Django Admin može omogućiti tu provjeru, ali je potrebno izdvojiti vrijeme za kvalitetne modele, filtre i ovlasti. Kad zaposlenici počnu raditi, brzo se vidi gdje su potrebni novi ekrani.

• Jesu li nazivi polja, obvezni podaci i odnosi među zapisima razumljivi ljudima koji ih svakodnevno unose?
• Može li zaposlenik pronaći zapis prema najčešće korištenim kriterijima bez ručnog pregledavanja stotina redaka?
• Koje su masovne akcije dopuštene i postoji li dodatna potvrda za nepovratne promjene?
• Može li korisnik nenamjerno vidjeti ili promijeniti zapis koji pripada drugom odjelu ili organizaciji?
• Jesu li promjene važnih poslovnih podataka evidentirane i može li odgovorna osoba pregledati povijest?
• Koje tri radnje najviše smetaju zaposlenicima i treba li za njih razviti zasebno sučelje?

Najkorisniji Admin nije najbogatiji opcijama, nego onaj koji podržava razumljiv i siguran unos podataka.