u/Primary-Pattern4624

▲ 11 r/wandern

How to: Platz in ausgebuchter Alpenvereins-Hütte bekommen - dank automatischer Benachrichtigung, sobald etwas frei wird (einfache Anleitung)

Diese Anleitung bezieht sich auf Hütten, die über die Plattform hut-reservation.org gebucht werden können. Bestimmt lässt sich die Anleitung aber auch auf andere Buchungsplattformen übertragen.

Ihr plant eine Tour und eine Hütte ist genau an dem Tag, an dem ihr dort übernachten wollt, schon ausgebucht - und es gibt keine Warteliste? Kein Problem, denn mehr als jede vierte Reservierung wird wieder storniert. Ihr müsst es also nur schaffen, als erste davon zu erfahren, sobald ein Platz frei wird. Mit einem Trick könnt ihr euch automatisch darüber benachrichtigen lassen, damit ihr nicht mehrmals täglich selbst nachschauen müsst.

Die Idee ist simpel: Wir müssen zuerst ganz grundlegend verstehen, was passiert, wenn wir die Verfügbarkeit einer Hütte manuell über die Buchungsplattform prüfen. Dann müssen wir einem Programm beibringen, diese Prüfung alle paar Minuten für uns durchzuführen und uns zu benachrichtigen, sobald etwas frei ist. Das Programm müssen wir zum Glück nicht selbst bauen, sondern wir können einfach ein bestehendes Online-Tool dafür nutzen.

Nehmen wir als Beispiel die Lamsenjochhütte. Unter https://www.hut-reservation.org/reservation/book-hut/437/wizard lassen sich hierfür Schlafplätze reservieren. Wenn wir ins Datumsfeld zwei Tage eingeben, schickt unser Browser eine Anfrage an den Server: "Gibt es freie Schlafplätze in der Nacht von X auf Y?". Wenn die Hütte ausgebucht ist, antwortet der Server: 0 Plätze im Matratzenlager, 0 Mehrbettzimmer, 0 Zweierzimmer. Der Browser erhält die Antwort und zeigt sie uns an. So weit, so schlecht. Das Gute ist aber: Diese Anfrage muss nicht von unserem Browser kommen, sondern sie kann auch automatisiert von einem Programm verschickt werden.

Ein Online-Tool, das sich gut anbietet, um diese Anfrage zu verschicken, ist Checkly (eigentlich ist das Tool für andere Zwecke gedacht, aber das ist uns hier egal). Der kostenlose Hobby-Plan reicht völlig aus. Registrieren müsst ihr euch trotzdem. Anschließend:

1 - Klicke oben links auf "New".

2 - Klicke auf "API check".

3 - Fülle den Bereich "Make an HTTP request" aus. Ich gebe hier nur die Felder an, die geändert werden müssen, alles andere kann bleiben.

3/1 - Method: "POST"

3/2 - URL: Hier die folgende URL eingeben, wobei du die Zahl ganz am Ende durch die Zahl ersetzen musst, die eurer gewünschten Hütte entspricht: "https://www.hut-reservation.org/api/v1/reservation/checkAvailability/437" (der Link der Buchungsseite der Lamsenjochhütte enthält die Zahl "437", deshalb endet die URL in diesem Beispiel auf "437").

3/3 - Headers: "Content-Type" = "application/json"

3/4 - Body: "JSON"

Um das JSON-Textfeld ausfüllen zu können, musst du zuerst wieder auf die normale Buchungsseite wechseln, also in unserem Beispiel https://www.hut-reservation.org/reservation/book-hut/437/wizard. Anschließend führst du folgende Schritte aus. Bitte beachten, die Anleitung bezieht sich auf Firefox. In anderen Browsern sind manche Felder vielleicht anders bezeichnet, aber es sollte die gleichen Funktionen geben. Ansonsten einfach Firefox nutzen bzw. kurz hierfür installieren.

  • Nachdem du die Seite aufgerufen hast, irgendwo auf der Seite eine Rechtsklick machen und dann auf "Untersuchen" klicken.
  • Es öffnet sich der Browser-Inspektor. Wechsle vom Inspektor in den Tab "Netzwerkanalyse".
  • Klicke jetzt in der Buchungsseite auf das Datumsfeld und wähle die Tage aus, in denen du in der Hütte übernachten willst.
  • In der Netzwerkanalyse erscheinen jetzt neue Einträge. Klicke dich durch zu dem Eintrag, bei dem unter "Kopfzeilen" der Filename "/api/v1/reservation/checkAvailability/437" steht ("437" ist aus unserem Beispiel, bei dir muss hier die ID deiner Hütte stehen).
  • Wechsle bei diesem Eintrag vom Tab "Kopfzeilen" in den Tab "Anfrage".
  • Aktiviere den Toggle "Unformatiert".
  • Kopiere den gesamten Anfrageinhalt und füge ihn in Checkly in das JSON-Textfeld ein.

4 - Klicke auf "Run request". Das Popup sollte ein grünes Häkchen und eine kleine grüne "200" anzeigen sowie einen Response Body (den musst du nicht lesen). Klicke auf "Close".

5 - Fülle den Bereich "Assertions" aus. In unserem Beispiel gehen wir davon aus, dass wir irgendein freies Bett wollen, egal ob Matratzenlager, Mehrbett- oder Zweierzimmer. Wir wollen benachrichtigt werden, wenn in einer der Kategorien etwas frei wird. Das heißt, dass wir den Zustand "In keiner der Kategorien ist etwas frei" als Normalzustand definieren, in dem wir nicht benachrichtigt werden.

5/1 - Source: "JSON body"

5/2 - Property: "availabilityPerDayDTOs[0].bedCategoriesData[0].totalFreePlaces"

5/3 - Comparison: "Equals"

5/4 - Target: "0"

5/5 - Klicke auf "Add".

5/6 - Jetzt nochmal das gleiche in der zweiten Zeile, also erneut Source = "JSON body", Comparison = "Equals" und Target = "0". Bei Property aber eine kleine Änderung vornehmen, und zwar die zweite "0" durch eine "1" austauschen, also "availabilityPerDayDTOs[0].bedCategoriesData[1].totalFreePlaces"

5/7 - Klicke nochmal auf "Add".

5/8 - Jetzt ein drittes Mal, aber dieses Mal bei Property die "1" durch eine "2" austauschen, also "availabilityPerDayDTOs[0].bedCategoriesData[2].totalFreePlaces".

5/9 - Ein letztes Mal auf "Add" klicken.

6 - Scrolle wieder nach oben und klicke erneut "Run request". Du solltest mehrere grüne Häkchen sehen (weil jede der Bettenkategorien tatsächlich 0 freie Plätze hat). Klicke auf "Close".

7 - Stelle unter "Frequency" ein, wie oft Checkly die Anfrage stellen soll (das entscheidet darüber, wie schnell du mitbekommst, dass es freie Plätze gibt). Unter 5 Minuten würde ich dir nicht empfehlen, um den Hut-Reservation-Server nicht unnötig zu belasten.

8 - Wähle unter "Locations" aus, dass die Anfragen nur aus Deutschland geschickt werden sollen.

9 - Wähle unter "Alert settings" die Option "Use specific notification settings" und dann "When a check has failed 1 time".

10 - Wähle unter "Where should we alert you?" die E-Mail-Adresse aus, mit der du dich registriert hast. Nachher (nachdem du deinen API Check gespeichert hast!) kannst du weitere Alert Channels hinzufügen (z. B. SMS), indem du in der linken Sidebar auf "Alert channels" klickst (wenn die Sidebar eingeklappt ist, klicke oben links auf die drei Striche). Meiner Erfahrung nach funktionieren die E-Mail-Alerts aber am zuverlässigsten. Ich würde mich nicht auf SMS-Alerts verlassen.

11 - Scrolle ganz nach oben und klicke auf "Create check" und dann auf "Save check".

Gratulation, du hast es geschafft!

Wichtige Hinweise:

  • Leider wird nicht jeder E-Mail-Alert automatisch bedeuten, dass es freie Plätze gibt, sondern es wird auch False Alerts geben - und zwar immer dann, wenn der Server nicht erreichbar ist. Das passiert hut-reservation.org jedoch nur selten.
  • Direkt nach der Registrierung auf Checkly hat man den Plan "Team Trial". Nach 14 Tagen wechselt man automatisch in den Hobby-Plan, aber der ist völlig ausreichend für unsere Zwecke.
  • Dadurch, dass diese Anleitung sehr detailliert ist, ist sie auch anfällig für Änderungen - entweder seitens hut-reservation.org oder seitens Checkly. In so einem Fall müsst ihr einfach schauen, was ihr wie anders machen müsst, um ans Ziel zu kommen.

Viel Erfolg und eine schöne Hüttentour!

reddit.com
u/Primary-Pattern4624 — 19 hours ago
▲ 4 r/alpenverein+1 crossposts

How to: Platz in ausgebuchter Hütte bekommen - dank automatischer Benachrichtigung, sobald etwas frei wird (einfache Anleitung)

Diese Anleitung bezieht sich auf Hütten, die über die Plattform hut-reservation.org gebucht werden können. Bestimmt lässt sich die Anleitung aber auch auf andere Buchungsplattformen übertragen.

Ihr plant eine Tour und eine Hütte ist genau an dem Tag, an dem ihr dort übernachten wollt, schon ausgebucht - und es gibt keine Warteliste? Kein Problem, denn mehr als jede vierte Reservierung wird wieder storniert. Ihr müsst es also nur schaffen, als erste davon zu erfahren, sobald ein Platz frei wird. Mit einem Trick könnt ihr euch automatisch darüber benachrichtigen lassen, damit ihr nicht mehrmals täglich selbst nachschauen müsst.

Die Idee ist simpel: Wir müssen zuerst ganz grundlegend verstehen, was passiert, wenn wir die Verfügbarkeit einer Hütte manuell über die Buchungsplattform prüfen. Dann müssen wir einem Programm beibringen, diese Prüfung alle paar Minuten für uns durchzuführen und uns zu benachrichtigen, sobald etwas frei ist. Das Programm müssen wir zum Glück nicht selbst bauen, sondern wir können einfach ein bestehendes Online-Tool dafür nutzen.

Nehmen wir als Beispiel die Lamsenjochhütte. Unter https://www.hut-reservation.org/reservation/book-hut/437/wizard lassen sich hierfür Schlafplätze reservieren. Wenn wir ins Datumsfeld zwei Tage eingeben, schickt unser Browser eine Anfrage an den Server: "Gibt es freie Schlafplätze in der Nacht von X auf Y?". Wenn die Hütte ausgebucht ist, antwortet der Browser: 0 Plätze im Matratzenlager, 0 Mehrbettzimmer, 0 Zweierzimmer. Der Browser erhält die Antwort und zeigt sie uns an. So weit, so schlecht. Das Gute ist aber: Diese Anfrage muss nicht von unserem Browser kommen, sondern sie kann auch automatisiert von einem Programm verschickt werden.

Ein Online-Tool, das sich gut anbietet, um diese Anfrage zu verschicken, ist Checkly (eigentlich ist das Tool für andere Zwecke gedacht, aber das ist uns hier egal). Der kostenlose Hobby-Plan reicht völlig aus. Registrieren müsst ihr euch trotzdem. Anschließend:

1 - Klicke oben links auf "New".

2 - Klicke auf "API check".

3 - Fülle den Bereich "Make an HTTP request" aus. Ich gebe hier nur die Felder an, die geändert werden müssen, alles andere kann bleiben.

3/1 - Method: "POST"

3/2 - URL: Hier die folgende URL eingeben, wobei du die Zahl ganz am Ende durch die Zahl ersetzen musst, die eurer gewünschten Hütte entspricht: "https://www.hut-reservation.org/api/v1/reservation/checkAvailability/437" (der Link der Buchungsseite der Lamsenjochhütte enthält die Zahl "437", deshalb endet die URL in diesem Beispiel auf "437").

3/3 - Headers: "Content-Type" = "application/json"

3/4 - Body: "JSON"

Um das JSON-Textfeld ausfüllen zu können, musst du zuerst wieder auf die normale Buchungsseite wechseln, also in unserem Beispiel https://www.hut-reservation.org/reservation/book-hut/437/wizard. Anschließend führst du folgende Schritte aus. Bitte beachten, die Anleitung bezieht sich auf Firefox. In anderen Browsern sind manche Felder vielleicht anders bezeichnet, aber es sollte die gleichen Funktionen geben. Ansonsten einfach Firefox nutzen bzw. kurz hierfür installieren.

  • Nachdem du die Seite aufgerufen hast, irgendwo auf der Seite eine Rechtsklick machen und dann auf "Untersuchen" klicken.
  • Es öffnet sich der Browser-Inspektor. Wechsle vom Inspektor in den Tab "Netzwerkanalyse".
  • Klicke jetzt in der Buchungsseite auf das Datumsfeld und wähle die Tage aus, in denen du in der Hütte übernachten willst.
  • In der Netzwerkanalyse erscheinen jetzt neue Einträge. Klicke dich durch zu dem Eintrag, bei dem unter "Kopfzeilen" der Filename "/api/v1/reservation/checkAvailability/437" steht ("437" ist aus unserem Beispiel, bei dir muss hier die ID deiner Hütte stehen).
  • Wechsle bei diesem Eintrag vom Tab "Kopfzeilen" in den Tab "Anfrage".
  • Aktiviere den Toggle "Unformatiert".
  • Kopiere den gesamten Anfrageinhalt und füge ihn in Checkly in das JSON-Textfeld ein.

4 - Klicke auf "Run request". Das Popup sollte ein grünes Häkchen und eine kleine grüne "200" anzeigen sowie einen Response Body (den musst du nicht lesen). Klicke auf "Close".

5 - Fülle den Bereich "Assertions" aus. In unserem Beispiel gehen wir davon aus, dass wir irgendein freies Bett wollen, egal ob Matratzenlager, Mehrbett- oder Zweierzimmer. Wir wollen benachrichtigt werden, wenn in einer der Kategorien etwas frei wird. Das heißt, dass wir den Zustand "In keiner der Kategorien ist etwas frei" als Normalzustand definieren, in dem wir nicht benachrichtigt werden.

5/1 - Source: "JSON body"

5/2 - Property: "availabilityPerDayDTOs[0].bedCategoriesData[0].totalFreePlaces"

5/3 - Comparison: "Equals"

5/4 - Target: "0"

5/5 - Klicke auf "Add".

5/6 - Jetzt nochmal das gleiche in der zweiten Zeile, also erneut Source = "JSON body", Comparison = "Equals" und Target = "0". Bei Property aber eine kleine Änderung vornehmen, und zwar die zweite "0" durch eine "1" austauschen, also "availabilityPerDayDTOs[0].bedCategoriesData[1].totalFreePlaces"

5/7 - Klicke nochmal auf "Add".

5/8 - Jetzt ein drittes Mal, aber dieses Mal bei Property die "1" durch eine "2" austauschen, also "availabilityPerDayDTOs[0].bedCategoriesData[2].totalFreePlaces".

5/9 - Ein letztes Mal auf "Add" klicken.

6 - Scrolle wieder nach oben und klicke erneut "Run request". Du solltest mehrere grüne Häkchen sehen (weil jede der Bettenkategorien tatsächlich 0 freie Plätze hat). Klicke auf "Close".

7 - Stelle unter "Frequency" ein, wie oft Checkly die Anfrage stellen soll (das entscheidet darüber, wie schnell du mitbekommst, dass es freie Plätze gibt). Unter 5 Minuten würde ich dir nicht empfehlen, um den Hut-Reservation-Server nicht unnötig zu belasten.

8 - Wähle unter "Locations" aus, dass die Anfragen nur aus Deutschland geschickt werden sollen.

9 - Wähle unter "Alert settings" die Option "Use specific notification settings" und dann "When a check has failed 1 time".

10 - Wähle unter "Where should we alert you?" die E-Mail-Adresse aus, mit der du dich registriert hast. Nachher (nachdem du deinen API Check gespeichert hast!) kannst du weitere Alert Channels hinzufügen (z. B. SMS), indem du in der linken Sidebar auf "Alert channels" klickst (wenn die Sidebar eingeklappt ist, klicke oben links auf die drei Striche). Meiner Erfahrung nach funktionieren die E-Mail-Alerts aber am zuverlässigsten. Ich würde mich nicht auf SMS-Alerts verlassen.

11 - Scrolle ganz nach oben und klicke auf "Create check" und dann auf "Save check".

Gratulation, du hast es geschafft!

Wichtige Hinweise:

  • Leider wird nicht jeder E-Mail-Alert automatisch bedeuten, dass es freie Plätze gibt, sondern es wird auch False Alerts geben - und zwar immer dann, wenn der Server nicht erreichbar ist. Das passiert hut-reservation.org jedoch nur selten.
  • Direkt nach der Registrierung auf Checkly hat man den Plan "Team Trial". Nach 14 Tagen wechselt man automatisch in den Hobby-Plan, aber der ist völlig ausreichend für unsere Zwecke.
  • Dadurch, dass diese Anleitung sehr detailliert ist, ist sie auch anfällig für Änderungen - entweder seitens hut-reservation.org oder seitens Checkly. In so einem Fall müsst ihr einfach schauen, was ihr wie anders machen müsst, um ans Ziel zu kommen.

Viel Erfolg und eine schöne Hüttentour!

alpin.de
u/Primary-Pattern4624 — 1 day ago

More then a year ago, I posted here to ask whether anyone has experiences in building a custom web client for the Nextcloud Deck app (or any Nextcloud app). We didn't find any examples where it has been tried, but nevertheless decided to do it, for the purpose of seamlessly integrating it into our platform. Now that it's done, we can share what we learnt.

tl;dr: It worked, the result is great (according to our users and ourselves), but it was a rather long and stony way for our small team. If you are curious how it turned out, you can test the result for yourselves (our platform is also available in English of course, the screenshots are just from our German blog post).

The background (only relevant for understanding the context):

  • We are the wechange eG, a small cooperative from Berlin.
  • We develop and operate the open source platform UniteOS (backend: Django/Python; frontend: mostly React).
  • The platform enables users to collaborate and network.
  • To collaborate, users can create groups, invite other users and then use various tools together.
  • Most of the collaboration tools are based on integrated open source software (Rocket.Chat for messaging, BigBlueButton for video conferencing...). The integration includes the sync of user accounts (SSO), group memberships and roles/permissions.
  • We've already integrated Nextcloud, in particular the Files app.
  • Each group on the platform is synced to a Nextcloud group, and each of them has a group folder.
  • This integration is anything but pretty for the user: When I'm in a group on the platform and want to access the cloud folder, the original Nextcloud web client opens in a new tab. It's a huge navigation and design break.

The decision to build a custom web client for the Nextcloud Deck App:

  • Our users rightfully yearned for kanban boards to replace our old, in-house to-do list app.
  • Our product strategy is to preferably integrate proven open source tools instead of reinventing the wheel.
  • We decided to integrate the Deck app, because it has the features we want and because we run a Nextcloud server for each of our platforms already anyway.
  • Basic concept: One board per group, all group members can edit, group admins have additional permissions.
  • We evaluated whether we just integrate the Deck app like we integrated the Files app: Let our backend create a board and share it with the group, let the users open the board in a new tab. Or maybe display the board in an iframe within the group, at least.
  • We discarded both options, because we wanted to actually provide a great and seamless user experience (and because we had the funding from our clients to do something better).
  • We decided to build a custom web client, which directly accesses the API of the Deck app.
  • Our research showed that it should be possible, but that it hasn't really been done by anyone yet.

How it went:

  • Creating a UI mockup for the boards and the cards was more challenging than expected, but doable of course.
  • Our frontend dev was surprisingly fast in implementing the mockup in React.
  • Writing the logic that our backend creates and shares boards was easy.
  • I wish I could say that that was it, but the devil's in the details.

The issues were (from bigger to smaller):

  • Supporting notifications (we want our users to get notified when they get assigned or mentioned, for example). We had to fork the Deck app, because there were issues with the event system (our PR is approved, but not merged yet). Additionally, we had to create a small Nextcloud app as a notification bridge, and write additional logic in our backend.
  • Migrating the content from our old to-do list app to the new boards was a little challenge.
  • Mapping permissions. Our user roles don't fully align with with permission levels in the Deck app, so we implemented a little hacky solution. We got what we want: our group admins can manage lists and labels using proxy endpoints, but they can't directly manage, archive or delete the board.
  • Partly missing or wrong documention of Deck app APIs, no clear error codes. Not a huge deal, our improvements are merged.
  • Effort for our DevOps team: Setting up CORS in nginx (so our client can access Nextcloud APIs); setting up the Notify Push app (for real time collaboration).
  • We deactivated the original view of the Deck app, so now debugging is difficult (only via API).

Advantages of our web client compared to the original client:

  • Practical and intuitive embedding in the context of the group.
  • Better UI: Content of a card is displayed on one page instead of 3 or 4 tabs. Managing labels and lists is also easier.
  • Comments are more visible and we added comment threads (that can be collapsed and resolved), so discussions are more structured.
  • Quality of life features, like inserting graphics into the descriptions with copy&paste
  • Notifications for important events (within the platform, via email and/or as push to the mobile app, depending on your preferences).

Our conclusion:

  • The result works really well and the feedback from our users is very positive, so that's good.
  • The problem was not building our own web client, but the more complex architecture of two separate backends, especially since the Nextcloud and its apps are not designed to be integrated in other platforms (which we knew already).
  • In hindsight, it probably would have been easier to just entirely build our own backend instead of using the one of the Deck app. We would have missed some features (like interoperability with mobile Deck app clients) and would have had other issues, but it probably would have been quicker.
  • Now, we are depending on the Deck app API, but we knew that before and it had only few major changes in the past. It can even be an advantage: If the Deck app gets new features, we just have to build the frontend for it, if we want to.

Potential takeaways for other product managers - probably transferable to other Nextcloud apps and not just Deck:

  • If you just want to build a custom user interface with your design, navigation etc., building a web client and connecting it to the API is not so hard (especially if you use AI for design and coding, I guess).
  • If you want to deeply integrate an app into an existing architecture, there will probably be several obstacles, which might not be unsolvable, but time-consuming.

HOW YOU CAN TEST OUR CUSTOM WEB CLIENT:

  • We operate the public platform wechange.de (based on UniteOS). Here, you can very simply try out our app.
  • Click here to sign up. You can use any display name. You can also skip the profile setup.
  • After signup, you are immeditially added to this group. Here, the Task Board App is activated and you can use it.
  • Feel free to let me know what you think!

PS: We are currently doing something similar with our calendar - we are connecting our web client directly with the CalDAV server that comes with the Nextcloud Calendar app. Wish us luck!

EDIT: Our repo

Our Deck app client is part of our NextJS frontend (latest version). This is the entry component.

u/Primary-Pattern4624 — 2 months ago