added chapter verwalten and edited the website menu
This commit is contained in:
@@ -29,7 +29,7 @@ Um einen Einblick in den Aufbau eines Django-Projektes zu erlangen wird dies im
|
||||
|
||||
|
||||
\subsection{Datenmodellierung}
|
||||
Die Struktur der bereits bestehenden Datenbank im Django-Framework und die Erweiterungen dessen werden hier genauer erläutert. Zunächst wird auf die Ergänzung des bestehenden \textit {UserModel} eingegangen, nachdem veranschaulicht der Abschnitt das \textit {PostModel} und abschlie"send werden die Zusammenhänge der Modelle dargestellt.
|
||||
Die Struktur der bereits bestehenden Datenbank im Django-Framework und die Erweiterungen dessen werden hier genauer erläutert. Zunächst wird auf die Ergänzung des bestehenden \textit{UserModel} eingegangen, nachdem veranschaulicht der Abschnitt das \textit{PostModel} und abschlie"send werden die Zusammenhänge der Modelle dargestellt.
|
||||
|
||||
Alle Modelle werden als Django-Modelle deklariert um beim kompilieren des Codes dem Compiler mitzuteilen, dass diese integriert werden müssen (vgl. [Dja18]). Mit der folgenden Eingabe
|
||||
\\
|
||||
@@ -100,16 +100,28 @@ Das gestaffeltes Berechtigungsmanagement ist im Prototyp notwendig um den Umgang
|
||||
|
||||
Studenten sollen zunächst Informationen weder einpflegen, noch editieren dürfen. Die einzigen Änderungen die sie vornehmen können sind auf Ihre eigene Datenbank fokussiert. Das Hinzufügen von Tags um die damit verbunden Posts auf dem persönlichen Dashboard zu sehen wird ihnen gewährleistet. Dies soll verhindern, dass Informationen nicht zu leichtfertig geändert oder gelöscht werden.
|
||||
|
||||
---text anders strukurieren ---
|
||||
Dozenten und Angestellte der Hochschule sind dazu berechtigt, Posts zu erstellen, zu editieren und wieder zu löschen. Zudem können sie, wie Studenten, Tags abonnieren und ebenso das persönliche Dashboard gestalten. Das Einloggen in die Administratoroberfläche kann vorgenommen werden, jedoch sind der Gruppe noch keinerlei Rechte zugewiesen. Durch das Setzen des booleschen Wert \glqq is\_staff\grqq\ auf \glqq True\grqq\ beim Erstellen der Benutzergruppe, ist es möglich im Code der Applikation Abfragen durchzuführen. Dadurch lassen sich bestimmte Views individuell an die eingeloggte Person anpassen. Möchte man dies ändern, kann man das von Django bereitgestellte Feld \glqq User Permissions\grqq\ im Admin-back-end unter Users, und dem Namen der Person, die gewünschte Berechtigung zuteilen. Diese sind von Django vorgegeben und betreffen alle vorhandenen Modelle der Applikation. Soll ein User zum Beispiel erlaubt sein einen Tag aus dem Archiv zu löschen, so wählt er das Feld \glqq taggit \textbar Tag \textbar can delete Tag\grqq\ und schiebt es von der Auswahl zu den Berechtigungen.
|
||||
Dozenten und Angestellte der Hochschule sind dazu berechtigt, Posts zu erstellen, zu editieren und wieder zu löschen. Zudem können sie, wie Studenten, Tags abonnieren und somit ebenso das persönliche Dashboard gestalten. Das Einloggen in die Administratoroberfläche kann vorgenommen werden, jedoch sind der Gruppe noch keinerlei Rechte zugewiesen. Möchte man dies ändern, kann man das von Django bereitgestellte Feld \glqq User Permissions\grqq\ im Admin-back-end unter Users, und dem Namen der Person, die gewünschte Berechtigung zuteilen. Diese sind von Django vorgegeben und betreffen alle vorhandenen Modelle der Applikation. Soll ein User zum Beispiel erlaubt sein einen Tag aus dem Archiv zu löschen, so wählt er das Feld \glqq taggit \textbar Tag \textbar can delete Tag\grqq\ und schiebt es von der Auswahl zu den Berechtigungen.
|
||||
Durch das Setzen des booleschen Wert \glqq is\_staff\grqq\ auf \glqq True\grqq\ beim Erstellen der Benutzer, ist es möglich im Code der Applikation Abfragen durchzuführen. Dadurch lassen sich bestimmte Views an die eingeloggte Personengruppe anpassen. So ist das Menü für Dozenten und Angestellte ein umfangreicheres als das, der Studenten.
|
||||
|
||||
|
||||
\section{Funktionen}
|
||||
User Stories einbinden als Grafik
|
||||
Um die wichtigsten Funktionen des Prototypen festlegen zu können werden User Stories erstellt (vgl. Abbildung 3.4.). Diese bestehen aus kurzen Sätzen und beschreiben aus Sicht des Nutzers das Verwenden einer Funktion. Die Priorisierung bezieht sich hierbei auf die Relevanz der Funktion, wobei die Funktionen mit einem rotem Punkt sehr wichtig für den Prototypen sind, Orang wichtige Funktionen sind aber nicht unbedingt notwendig und Grün kaum relevant sind.
|
||||
|
||||
\begin{figure}[!h]
|
||||
\centering
|
||||
\includegraphics[width=0.9\textwidth]{figures/userstories}
|
||||
\caption{User Stories}
|
||||
\hfill
|
||||
\end{figure}
|
||||
|
||||
\subsection{Verwalten}
|
||||
Posts erstellen, editieren und löschen
|
||||
(draft-list und post new für Mitarbeiter)
|
||||
Das Verwalten der Artikel soll von berechtigten Nutzern hauptsächlich im Front-end stattfinden. Der Vorgang des Erstellens, des Löschens und des Editierens der einzelnen Einträge wird im Folgenden konkretisiert.
|
||||
|
||||
Ein neuer Artikel wird erstellt. Das \glqq +\grqq\ in der Menüleiste leitet den Benutzer zu einer Unterseite. Hier können alle Felder befüllt werden, die im PostForm-Formular in der Datei forms.py festgelegt wurden. Dazu gehören der Titel und der Text, die als Pflichtfelder gelten. Das Feld \glqq Tags \grqq\ muss ebenfalls mindestens einen Wert enthalten um die Validierung der Eingaben sichern zu können. Eine Ausnahme bildet das Datum der Veröffentlichung. Bleibt das Feld leer so wird der Post automatisch der Liste der Entwürfe beigefügt.
|
||||
|
||||
Die eindeutige Zuordnung der Eingabe im Front-end zur Verarbeitung der verschiedenen Artikel im Back-end ist mit einem \textit{Primary Key} realisiert. In der View \glqq post\_new \grqq\ wird zunächst die Validität aller Eingaben geprüft. Falls dies der Fall ist, wird der Post als Objekt zurückgegeben, jedoch durch das optionale \textit{Keywort} \glqq commit=false \grqq\ noch nicht in der Datenbank abgelegt. Das ist notwendig um dem Objekt spezifische Informationen mitzugeben. In diesem Kontext wird der aktuell eingeloggte User als Autor hinterlegt. Jedoch birgt die Vorgehensweise eine Problematik im Speichervorgang einer \textit{ManyToMany} Relation zwischen zwei Modellen. Da Informationen nur auf ein bereits in der Datenbank bestehendes Objekt gesichert werden können ist dies zunächst nicht möglich.
|
||||
Im Prototyp nutzt das \textit{PostModel} die \textit{ManyToMany} Konnektivität mit dem Modell des TaggabelManagers. Um die Eingabe des Tag-Felds trotzdem im neuen Artikel speichern zu können, wird zunächst das Objekt gespeichert, um nachdem explizit das von Django zur Verfügung gestellte \glqq form.save\_m2m() \grqq\ aufrufen zu können.
|
||||
--- pk erklären
|
||||
|
||||
|
||||
\subsection{Abonnieren}
|
||||
@@ -120,3 +132,13 @@ Tag-map? Filtern nach abonnierten Posts, alle Posts und Posts mit bestimmten Tag
|
||||
|
||||
\subsection{Benachrichtigung}
|
||||
Mail-Benachrichtigung wöchentlich
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user