Auslaufende Ressourcen

[JJB]

Wie ist das eigentlich konzeptionell von der Entwicklung her gedacht, damit umzugehen, wenn Ressourcen "auslaufen".

Es ist ja vollkommen klar, dass auf dieser Welt nichts für immer hält. Ein Raum, den man mal zur Verfügung hat, existiert vielleicht ab einem bestimmten Zeitpunkt nicht mehr (oder man darf ihn nicht mehr nutzen), ein Gerät gibt den Geist auf und so weiter...

Leider habe ich keine Möglichkeit gefunden, einer Ressource ein solches Ablebensdatum hinzuzufügen, so dass sie ab dem Zeitpunkt nicht mehr reserviert werden kann. Löschen will ich sie auch nicht, da der Zeitpunkt zum einen noch in der Zukunft liegt, da zum anderen damit aber auch all die Nutzungen der Ressource in der Vergangenheit verloren gehen. Die würde ich gerne aus dokumentarischen Zwecken behalten.

Was also tun?

[Simon2]

@jjb Ich würde

• In den Kommentar der Ressource einen entsprechenden Hinweis einfügen ("ACHTUNG: Ab 31.12.2022 nicht mehr verfügar!" o.ä.) und
• ab einem gewissen Zeitpunkt die "Freigabemöglichkeit" einschränken und der Freigeber muss dann eben alle Anfragen über den Zeitpunkt hinaus ablehnen.
• Alternativ könnte man auch stumpf die Ressource für den "danach-Zeitraum" ausbuchen. (01.01.2023 - 31.12.2024 ganztägig mit "nicht mehr verfügbar").

Einen Ablauf konzeptionell in CT zu verankern, halte ich für nicht unbedingt nötig.
Es gibt ja auch andere mögliche "Einschränkungen" (bestimmte Technik vorübergehend nicht verfügbar, Bestuhung ändert sich, ....) - da alle Eventualitäten abzufackeln, wäre Aufwand, dann

• für andere FRs fehlt und
• in der Benutzung schnell überkomplex wird.

Gruß

Simon

[JJB]

@simon2 Vielen Dank für deine Antwort. Wie kann man Ressourcen Kommentare geben? Oder meinst du eine Anpassung der Bezeichnung?

[Simon2]

@jjb Sorry, das Feld heißt in den Stammdaten "Ort" - hatte ich falsch im Kopf.
Ist aber ein Freitextfeld, so dass nichts dagegen spricht, dort auch noch eine passenden Kommentar dran zu hängen (Also aus "im Gemeindehaus" -> "im Gemeindehaus - ACHTUNG: DIESER RAUM FÄLLT AM 01.01.2023 WEG!!" zu machen)

[bwl21]

@simon2 das ist aber ein übler workaround ...

[Simon2]

@bwl21 sagte in Auslaufende Ressourcen:

@simon2 das ist aber ein übler workaround ...

Welchen meinst du?
1 Hinweis bei der Ressource (und entsprechendes Ablehnen)
2 "Blocker" für die Zeit nach dem Ablauf

Gerade 2 finde ich ziemlich elegant und "zieht" auch bei so Sachen, wie Buchungen, die über den Kalender angefragt werden oder Verschiebungen...

Eine "Ablaufmechanik" - gerade, wenn sie halbwegs flexibel sein sollte - stelle ich mir vom Effekt nicht viel anders vor und dafür im Handling komplizierter...

[bwl21]

@simon2 sorry, beim Ort einen Kommentar einzutragen, finde ich einen üblen Workaround. Sollte eigentlich den FR stützen

Aber das mit dem Blocker finde ich gut.

[Simon2]

@bwl21 sagte in Auslaufende Ressourcen:

@simon2 sorry, beim Ort einen Kommentar einzutragen, finde ich einen üblen Workaround....

Optimal finde ich das auch nicht und natürlich bin ich im Prinzip bei dir: Man sollte Attribute als das nutzen, als was sie gedacht sind.
... allerdings sehe ich hier keinerlei "echte Ortssemantik" hinterlegt (gibt kein Adressfeld, Maps-Koordinaten, ... was typisch für einen Ort wäre, auch keine Operationen oder Referenzen, die die Ortseigenschaften nutzen/berücksichtigen).

Es ist einfach ein Freitextfeld, das mehr zurällig "Ort" heißt. Wenn man in seiner Übersetzung "Ort" zu "Kommentar" (oder gar "Auslaufdatum") umbenennen würde, würde das absolut funktionieren.

Bei uns (deshalb hatte ich ursprünglich auch gedacht, dass das Feld "Kommentar" heißt) steht da auch mehr ein Hinweis, wo der Raum sich befindet - (in der Art "Ihr wisst schon: Hinter dem Wirtschaftsraum links" ).
Deshalb fände ich das nicht so besonders schlimm.

Aber das mit dem Blocker finde ich gut.

Danke für die Klärung.
Finde ich auch eine gute (und bessere als die andere) Lösung - ist mir aber erst als zweites eingefallen und deshalb nachgeschoben. Und wer weiß: Vielleicht gefällt einem die "Kommentarlösung" auch besser .und der freut sich vielleicht darüber.

Gruß

Simon

[Andrej]

@simon2 sagte in Auslaufende Ressourcen:

... auch keine Operationen oder Referenzen, die die Ortseigenschaften nutzen/berücksichtigen).

Das stimmt so nicht. Soweit ich weiß wird die Ortsangabe der Ressource an die ical Datei im Kalendertermin übergeben, welcher diese Ressource enthält.
Das stammt noch aus der Zeit bevor man direkt einen Ort im Kalendertermin anlegen konnte.

[Simon2]

@andrej OK, die ical-Datei habe ich mir nicht angeschaut.
Aber der Text wird dann vermutlich im Kalender zwar unter der Rubrik "Ort" angezeigt, hat dort aber ähnlich wenig "Ortseigenschaften" wie im CT-Ressourcenmodul, oder?

[bwl21]

@simon2 sagte in Auslaufende Ressourcen:

Es ist einfach ein Freitextfeld, das mehr zurällig "Ort" heißt. Wenn man in seiner Übersetzung "Ort" zu "Kommentar" (oder gar "Auslaufdatum") umbenennen würde, würde das absolut funktionieren.

Ich habe in letzter Zeit einiges an Datenmigrationen durchgeführt, und fand in solchen Freitextfeldern plötzlIche Telefonnummern obwohl es E-mails sein sollten ...

Daher bin ich der Meinung, es sollte Immer ein Freitextfeld geben für solche, nicht im Schema vorgesehenen Daten. Wenn es ein solches allgemeines Freitextfeld nicht gibt, provozieren wir solche üblen Workarounds.

[Andrej]

@simon2 sagte in Auslaufende Ressourcen:

@andrej OK, die ical-Datei habe ich mir nicht angeschaut.
Aber der Text wird dann vermutlich im Kalender zwar unter der Rubrik "Ort" angezeigt, hat dort aber ähnlich wenig "Ortseigenschaften" wie im CT-Ressourcenmodul, oder?

Ich denke, es hängt von der Anwendung ab, mit der man die ical nutzt/ einbindet. Ich habe zum Beispiel die Termine in meiner Kalender APP auf dem Smartphone und dort ist bei der Ortsangabe direkt ein Link "Auf Karte finden". Dieser sendet dann die Angaben bei Ort an google maps und zeigt auf der Karte die Treffer an.

[Simon2]

@bwl21 sagte in Auslaufende Ressourcen:

...
Daher bin ich der Meinung, es sollte Immer ein Freitextfeld geben für solche, nicht im Schema vorgesehenen Daten. Wenn es ein solches allgemeines Freitextfeld nicht gibt, provozieren wir solche üblen Workarounds.

Gerne - allerdings sehe ich immer noch nicht, was an dieser Nutzung ein "..übler Workaround.." ist.
Für mich ist eigentlich das Gegenteil ein "übler Workaround": Wenn man in Freitextfeldern "geheime Schnittstellen" implementiert. Also z.B. in bestimmtes Format nutzen muss, damit (ggf. woanders) ein Prozess/Programm/... funktioniert.
Das Übel sind mMn nicht Freitextfelder, sondern deren Missbrauch für technische Auswertung.
Solange klar ist, dass Freitextfelder immer nur von Menschen interpretiert werden, habe ich kein Problem mit einer "individuellen Interpretation".
... und wo Information nicht (nur) von Menschen interpretiert werden, sollte man keine Freitextfelder (oder zumindest keine Freitexteingaben) verwenden.
Aber nun genug von meiner Schnittstellenphilosophie.

@andrej sagte in Auslaufende Ressourcen:

..."Auf Karte finden". Dieser sendet dann die Angaben bei Ort an google maps und zeigt auf der Karte die Treffer an.

Nunja - das ist aber dann quasi Glückssache, ob das funktioniert - bzw. muss man dann manuell auf die "Kartenapp" anpassen (Was passiert eigentlich, wenn jemand eine andere App nutzt? Sind die Daten kompatibel?).
Außerdem ist das schon eine sehr spezielle Interpretation des Begriffes "Ort". Wir haben z.B. nur eine Adresse für unsere 2 Gebäude mit 12 Räumen. Da hilft eine Ortsangabe, die per Google-Maps auswertbar ist, nicht viel.

Apropos: "Hilfreich" sind bei uns Ortsangaben, die auf gemeindeintern übliche Begrifflichkeiten zurückgreifen "unter der Kirche", "Neben dem Wirtschaftstraum", .... ich wüsste nicht, wie das gemeindeübergreifend formalisiert werden sollte.

[Andrej]

@simon2 sagte in Auslaufende Ressourcen:

Nunja - das ist aber dann quasi Glückssache, ob das funktioniert - bzw. muss man dann manuell auf die "Kartenapp" anpassen

Ja, definitiv Glückssache! Ich sag ja auch nicht, dass ich es so wie es ist gut finde, wollte nur darauf hinweisen, dass das Ortsfeld in den Ressourcen an die ical übergeben wird und dadurch eben nicht ein x-beliebiges Freitextfeld ohne Funktion ist.
Ideal ist es bei Weitem nicht, zumal bei einem Termin mit mehreren Ressourcen alle Ortsangaben hintereinander gesetzt werden. Sinnvoll ist das meiner Meinung nach nicht.
Wesentlich besser ist es, wenn der ical Datei die neu hinzugekommende Ortsangabe aus dem Kalender mitgegeben wird und nicht die aus den hinterlegten Ressourcen. Aber das ist ein anderes Thema und dazu gibt es auch bereits andere Forenbeiträge.

[bwl21]

@simon2 sagte in Auslaufende Ressourcen:

Solange klar ist, dass Freitextfelder immer nur von Menschen interpretiert werden, habe ich kein Problem mit einer "individuellen Interpretation".
... und wo Information nicht (nur) von Menschen interpretiert werden, sollte man keine Freitextfelder (oder zumindest keine Freitexteingaben) verwenden.

leider ist das nicht wirklich klar. Spätestens bei einer anstehende Migration oder Ankopplung externer System kommt der Wunsch auf, auch solche Felder zu verarbeiten. Da reicht es, dass man den Freitext verarbeiten muss (dazu gibt es brauchbare Techniken). Wenn man aber die Bedeutung nicht kennt wegen einer 'individuellen Interpretation', d.h. wenn das Label 'ort' heisst, manchmal aber eine E-Mail drin steht, wird da deutlich komplexer. Darauf wollte ich hinweisen.

Aber nun genug von meiner Schnittstellenphilosophie.

dem schließe ich mich an

[Simon2]

@bwl21 sagte in Auslaufende Ressourcen:

...leider ist das nicht wirklich klar. Spätestens bei einer anstehende Migration oder Ankopplung externer System kommt der Wunsch auf, auch solche Felder zu verarbeiten. ....

Dann muss man aber sowieso erst einmal eine "Datenbereinigung" durchführen (denn woher sollte in den Jahren vorher schon sichergestellt sein, dass man das nun plötzlich erforderte Format eingehalten hat?).
BTW: Ich glaube, hier sprechen wir von ein paar Handvoll Daten - die kann man in so einem Fall schon relativ einfach "glattziehen".