Merge branch 'main' of https://git.kocoder.xyz/Diplomarbeit-Absolventenverein/pm
Some checks failed
Word Count / count-words (push) Failing after 32s
Some checks failed
Word Count / count-words (push) Failing after 32s
This commit is contained in:
@@ -119,7 +119,28 @@ foreach (var item in PageState.Pages
|
||||
|
||||
Durch diesen Ansatz werden ausschließlich die für Benutzer relevanten Inhaltsseiten in der Navigation angezeigt. Gleichzeitig bleibt die Navigation vollständig dynamisch: Werden im CMS neue Seiten angelegt und als Navigationsseiten markiert, erscheinen diese automatisch im Menü, ohne dass eine Anpassung am Theme-Code notwendig ist.
|
||||
|
||||
![Filterlogik der Oqtane-Navigation] (./images/06-Adam/navigationsfilter_v2.svg)
|
||||
<!--  -->
|
||||
|
||||
``` {.mermaid width=75%}
|
||||
graph TD
|
||||
%%| filename: navigationsfilter_v2
|
||||
%%| fig-cap: Filterlogik der Oqtane-Navigation (Theme.razor)
|
||||
|
||||
Start[PageState.Pages<br/>Alle CMS-Seiten ~12 Seiten] --> Filter1[Filter 1: ParentId == null<br/>Nur Root-Seiten]
|
||||
Filter1 -- Unterseiten --> Rejected1[Aussortiert]
|
||||
Filter1 --> Filter2[Filter 2: hiddenNames<br/>Systemseiten ausblenden]
|
||||
Filter2 -- "Login, Register, Admin, Privacy, ..." --> Rejected2[Aussortiert]
|
||||
Filter2 --> Result[Sichtbare Navigation<br/>~3 Inhaltsseiten im Menü]
|
||||
Result -.-> Note[Neue Seiten im CMS erscheinen automatisch im Menü – kein Code nötig]
|
||||
|
||||
style Start fill:#444441,stroke:#B4B2A9,color:#D3D1C7
|
||||
style Filter1 fill:#3C3489,stroke:#AFA9EC,color:#CECBE6
|
||||
style Filter2 fill:#3C3489,stroke:#AFA9EC,color:#CECBE6
|
||||
style Rejected1 fill:#791F1F,stroke:#F09595,color:#F7C1C1
|
||||
style Rejected2 fill:#791F1F,stroke:#F09595,color:#F7C1C1
|
||||
style Result fill:#085041,stroke:#5DCAA5,color:#9FE1CF
|
||||
style Note fill:none,stroke:#B4B2A9,stroke-dasharray: 5 5,color:#B4B2A9
|
||||
```
|
||||
|
||||
Dies reduziert den Wartungsaufwand erheblich und stellt sicher, dass die Navigation stets dem aktuellen Stand der Plattform entspricht.
|
||||
|
||||
@@ -245,7 +266,33 @@ Am unteren Rand des Formulars befinden sich zwei Speicheroptionen: „Als Entwur
|
||||
|
||||
Der folgende Lebenszyklus zeigt die möglichen Zustände eines Eintrags und die Übergänge zwischen ihnen:
|
||||
|
||||
![Lebenszyklus eines Hall-of-Fame-Eintrags] (./images/06-Adam/hall_of_fame_lebenszyklus_v4.svg)
|
||||
<!--  -->
|
||||
|
||||
``` {.mermaid width=75%}
|
||||
graph TD
|
||||
%%| filename: hall_of_fame_lebenszyklus_v4
|
||||
%%| fig-cap: Lebenszyklus eines Hall-of-Fame-Eintrags
|
||||
|
||||
Start([Benutzer eingeloggt]) --> Create[Eintrag erstellen<br/>Duplikat- & Eigentümerprüfung]
|
||||
Create -- Fehler --> Rejected[Abgelehnt]
|
||||
Create --> Draft[Draft<br/>Nur für Eigentümer sichtbar]
|
||||
Draft -- Veröffentlichen --> Published[Published<br/>Öffentlich sichtbar]
|
||||
Published -- Meldung --> Reported[Gemeldet<br/>IsReported = true]
|
||||
Reported --> Admin[Admin-Entscheidung]
|
||||
Admin -- OK --> Approved[Freigegeben]
|
||||
Admin -- Verstoß --> Deleted[Gelöscht<br/>→ neuer Eintrag möglich]
|
||||
|
||||
%% Styling to match original SVG
|
||||
style Start fill:#444441,stroke:#B4B2A9,color:#D3D1C7
|
||||
style Create fill:#3C3489,stroke:#AFA9EC,color:#CECBE6
|
||||
style Rejected fill:#791F1F,stroke:#F09595,color:#F7C1C1
|
||||
style Draft fill:#085041,stroke:#5DCAA5,color:#9FE1CF
|
||||
style Published fill:#085041,stroke:#5DCAA5,color:#9FE1CF
|
||||
style Reported fill:#633806,stroke:#EF9F27,color:#FAC775
|
||||
style Admin fill:#444441,stroke:#B4B2A9,color:#D3D1C7
|
||||
style Approved fill:#27500A,stroke:#97C459,color:#C0DD97
|
||||
style Deleted fill:#791F1F,stroke:#F09595,color:#F7C1C1
|
||||
```
|
||||
|
||||
##### Meldefunktion
|
||||
|
||||
@@ -255,7 +302,26 @@ Die Meldefunktion ermöglicht es angemeldeten Benutzerinnen und Benutzern, einen
|
||||
|
||||
Die Meldefunktion ist dabei nicht direkt im Hall-of-Fame-Modul implementiert, sondern wird über eine zentrale Schnittstelle aus einem gemeinsamen Interfaces-Paket eingebunden. Dieses Konzept ermöglicht es, dieselbe Melde-Oberfläche in beliebig vielen weiteren Modulen wiederzuverwenden, ohne die Logik mehrfach implementieren zu müssen.
|
||||
|
||||
![Ablauf des globalen Reporting-Systems] (./images/06-Adam/reporting_sequence_diagram.svg)
|
||||
<!---->
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
%%| filename: reporting_sequence_diagram
|
||||
%%| fig-cap: Ablauf des globalen Reporting-Systems
|
||||
participant User
|
||||
participant Module
|
||||
participant ReportingComponent
|
||||
participant ReportingHandler
|
||||
|
||||
User-->>+Module: View entity
|
||||
Module-->>+ReportingComponent: Report current entity
|
||||
ReportingComponent-->>User: Ask for reason
|
||||
User-->>ReportingComponent: Enters reason
|
||||
ReportingComponent-->>+ReportingHandler: New report (entity + reason)
|
||||
ReportingHandler-->>-ReportingComponent: Done
|
||||
ReportingComponent-->>-Module: Report saved
|
||||
Module-->>-User: Report saved
|
||||
```
|
||||
|
||||
|
||||
##### PDF-Export
|
||||
|
||||
|
||||
@@ -556,7 +556,7 @@ Daraufhin wird der Benutzer zur LinkedIn-Authentifizierungsseite weitergeleitet.
|
||||
|
||||
Nach erfolgreicher Authentifizierung sendet LinkedIn eine Antwort an die zuvor definierte Redirect-URL der Webanwendung. Diese Antwort enthält einen Autorisierungscode, der anschließend vom Server der Webanwendung gegen ein Zugriffstoken ausgetauscht wird.
|
||||
|
||||
Wie in Abschnitt 4.3.1 beschrieben, werden die abgerufenen Profildaten zur Identifikation oder Neuanlage des Benutzerkontos in der lokalen Datenbank verwendet.
|
||||
Wie in Abschnitt 4.4.3.1 beschrieben, werden die abgerufenen Profildaten zur Identifikation oder Neuanlage des Benutzerkontos in der lokalen Datenbank verwendet.
|
||||
|
||||
### Implementierung des Premium-Bereichs
|
||||
|
||||
|
||||
Reference in New Issue
Block a user