Buchungsregeln

[hansmorb]

Wie

• Es werden keine Daten im Kalender bearbeitet sondern die Buchung wird zur Laufzeit abgebrochen. So können wir einen generischen Cache für alle Nutzenden behalten.

Da ich Veränderungen am Autoload gemacht habe, muss composer dump-autoload ausgeführt werden, bevor der Branch verwendet werden kann.

Dieser PR fügt Regeln hinzu, mit denen die Buchung eingeschränkt werden kann.

Überlegung für diesen Branch:

• Nutzenden nur eine "unconfirmed" Buchung gleichzeitig erlauben damit nicht ein Haufen von unbestätigten Buchungen erzeugt werden kann um die Buchungsregeln zu umgehen. Wenn zB. ein Nutzender einen nur 1 Tag pro Monat buchen kann könnte dieser einfach mehrere unbestätigte Buchungen für den gleichen Monat erzeugen und diese dann nacheinander bestätigen. Eine Buchungsprüfung wird nur bei Erstellung einer unbestätigten Buchung durchgeführt. Das ist eine Komfortfunktion, damit Nutzende nicht die ganze Buchungsstrecke durchspielen müssen nur um zu erfahren, dass die Buchung nicht möglich ist.
• Überbuchte Tage irgendwie handeln, vielleicht durch Info der Überbuchung im Buchung Post und das dann bei Regelevaluierung berücksichtigen
• Template bearbeiten, sd. Fehlermeldung oben auf der Seite steht und nicht erst hinter dem ganzen Post content, Screenshot zur Demonstration:
  

Dokumentation:
https://commonsbooking.org/wp-admin/post.php?post=2157&action=edit (WIP)

[datengraben]

@hansmorb ich schaue mir den PR am Wochenende final an.

Für mich nur als Merker, bisher verbleibende TODOs:

• Den neuen Filter-Hook aus dem PR mit Schnittstelle und Nutzung einmal auf der Buchungsregel-Seite und auf der Filter-Hook-Seite dokumentieren
• Feedback von Erstellern der originalen Issues einholen

[hansmorb]

• Den neuen Filter-Hook aus dem PR mit Schnittstelle und Nutzung einmal auf der Buchungsregel-Seite und auf der Filter-Hook-Seite dokumentieren

Ich habe eher schon überlegt diesen Hook rauszunehmen, als ich ein Beispiel dafür erstellen wollte ist mir nichts eingefallen, was nicht mit tiefem Verständnis von CB implementiert werden kann ergo auch nur von uns implementiert werden kann. Also wenn dann müssten sehr genau auch die Helpermethoden dokumentiert werden oder wir nehmen den Hook raus.

• Feedback von Erstellern der originalen Issues einholen

Zum 2.: Die verlinkte Issue ist nur lose damit verbunden, eigentliche Anforderung kam von der flotte Berlin.

[datengraben]

Nur kleinere Änderungen und Fragen, nichts wildes.

[datengraben]

@hansmorb

Ich habe eher schon überlegt diesen Hook rauszunehmen, als ich ein Beispiel dafür erstellen wollte ist mir nichts eingefallen, was nicht mit tiefem Verständnis von CB implementiert werden kann ergo auch nur von uns implementiert werden kann.

Ich finde diese Schnittstelle (Buchungsregeln) einen guten Kandidat um Arbeit/Code aus dem Core herauszuhalten. Das Thema kam ja schon vermehrt auf.

Vorteile wären:

1. Gibt es ja einige Menschen mit Coding-Skills in den Instanzen, welche zwar nicht unbedingt direkt am Core mitarbeiten wollen/können, aber ich denke in der Lage wären eine Buchungsregel selber zu schreiben.
2. Instanzen können ihre Buchungsregeln miteinander teilen. Die Flotte hat für CB1 ja schon einiges an custom-Plugins erstellt das nachgefragt wird.

Beispiele für Nicht-Core-Buchungsregeln wären zum Beispiel:

• Wenn benutzerdefinierte Meta-Werte an Post-Objekten genutzt werden die nicht im Core sind und relevant für den Buchungsprozess der Instanz sind.
  • Eine Instanz hat an bestimmte Items ein Meta-Feld gehangen um bei z.B. Fehlverhalten o.A. zu markieren, welche Items von Usern nicht mehr ausgeliehen werden dürfen. Vorstellbar finde ich hier auch etwas wie einen "Führerschein" für ein Item, welcher dann auch z.B. in einem Meta-Wert abgelegt wird.
  • Oder ob User eine Anmeldung über eine auf dieser Instanz eingerichteten 2FA aktiviert haben.

Also wenn dann müssten sehr genau auch die Helpermethoden dokumentiert werden oder wir nehmen den Hook raus.

Welche Helpermethoden meinst du genau?

Zum 2.: Die verlinkte Issue ist nur lose damit verbunden, eigentliche Anforderung kam von der flotte Berlin.

Ok.

[datengraben]

• Nutzenden nur eine "unconfirmed" Buchung gleichzeitig erlauben damit nicht ein Haufen von unbestätigten Buchungen erzeugt werden kann um die Buchungsregeln zu umgehen. Wenn zB. ein Nutzender einen nur 1 Tag pro Monat buchen kann könnte dieser einfach mehrere unbestätigte Buchungen für den gleichen Monat erzeugen und diese dann nacheinander bestätigen. Eine Buchungsprüfung wird nur bei Erstellung einer unbestätigten Buchung durchgeführt. Das ist eine Komfortfunktion, damit Nutzende nicht die ganze Buchungsstrecke durchspielen müssen nur um zu erfahren, dass die Buchung nicht möglich ist.

@hansmorb Das in einen eigenes Issue auslagern?