Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kommunikation von Ortsangaben bei Herkünften #97

Closed
jmenzi opened this issue Mar 30, 2021 · 9 comments
Closed

Kommunikation von Ortsangaben bei Herkünften #97

jmenzi opened this issue Mar 30, 2021 · 9 comments

Comments

@jmenzi
Copy link
Collaborator

jmenzi commented Mar 30, 2021

So wie ich dich verstanden habe, ist es derzeit leider noch nicht möglich die Herkunftsorte bei den Herkünften vor den Gärtnerinnen zu verstecken, da die nötigen Tools fehlen. Zudem ist es für die Gärtnerinnen wichtig, dass sie zumindest die Herkunftsgemeinde kennen. Intern haben wir deshalb besprochen, dass es zum Schutz der Vorkommen auch ausreichen würde, dass die Gärtner*innen lediglich die Gemeinde sehen können, die genauen Flurnamen und die Koordinaten der Herkünfte und Sammlungen müssten aber (sobald dies technisch möglich ist) versteckt werden.

@barbalex
Copy link
Owner

Eine Beta-Version des Werkzeugs soll das schon können. Es geht also was.

@Seraina1
Copy link
Collaborator

Konnte dies bereits umgesetzt werden? Oder ist dies mittlerweile möglich?
Aktuell nutzen weder die Artveratwortlichen, noch die Gärtnereien die Datenbank wirklich. Da die Gärtnerinnen und Gärtner akuell sowieso noch nicht sehr Computeraffin sind, ist dies wohl noch ferne Zukunftsmusik.
Die Gärtnereien haben aber bereits die Möglickeit, die Datenbank zu nutzen, daher würde ich diese Anpassung dennoch umsetzten, für den Fall der Fälle.

@barbalex
Copy link
Owner

Ich brauche ca. 3 Stunden, um herauszufinden, ob das mittlerweile technisch geht. Autorisierung ist komplex und hängt immer vom ganzen Umfeld ab. Wenn ich es dann gleich mache, ist es in total ca. 5 Stunden gemacht.

Es lohnt sich also nicht, zuerst zu klären und dann erst zu entscheiden. Ihr müsst entscheiden, ob das geklärt werden soll und wenn möglich gleich umgesetzt.

@barbalex barbalex added this to the 2023 milestone Mar 30, 2023
@barbalex
Copy link
Owner

o.k., hab nochmals ein paar Stunden mit dem Problem verbracht.

Wie es scheint, kann die letztes Jahr implementierte Lösung der API das für diesen Fall nicht auf eine sichere Art lösen 😢

Ich müsste eine andere API verwenden, z.B. die in apflora verwendete.

Aber das wäre eine RIESEN-Sache, ganz grob geschätzt zwei Wochen Arbeit.

Was ich machen kann: App-Seitig in Abhängigkeit der Rolle die Daten einschränken. Das ist nicht sauber und nicht sicher vor technisch versierten Benutzern. Aber es würde erreichen, dass diese Daten in der App nicht angezeigt werden.

Ich würde das nur so implementieren, wenn ihr es explizit so wünscht.

@barbalex
Copy link
Owner

Habe jetzt an der nicht perfekten Umgehung gearbeitet.

Es gibt ein Problem. Und das würde auch bei der sauberen Implementation auftreten.

Ich kann stoppen, dass die Ortsangaben vom Server synchronisiert werden.

Das Problem ist: vermehrung funktioniert auch ohne Internetverbindung. Und zwar, indem es alle Daten, die man zugreifen darf, auf das jeweilige Gerät synchronisiert.

Will heissen: Gärtner, die auf dem betreffenden Gerät schon einmal angemeldet haben, haben früher die Ortsangaben synchronisiert. Und sehen sie darum weiterhin.

Was sie nicht mehr synchronisieren können und daher nicht sehen:

  • Ortsangaben von Herkünften, die seit der Anpassung von vermehrung (also der nächsten Version) erstellt werden
  • Ortsangaben aller Herkünfte, sobald sie auf einem neuen Gerät oder Browser anmelden

Ausserdem würden sie Änderungen von Ortsangaben nicht mehr synchronisieren. Will heissen: Die Ortsangaben, die sie sehen, können (theoretisch bzw. in Einzelfällen) veraltet sein.

Das kann ich nur verhindern, indem ich den Code so anpasse, dass er bei Gärtnern während der Synchronisation alle Ortsangaben, die zuvor auf das Gerät synchronisiert wurden, löscht.

Das Problem hierbei:

  • Es ist aufwändig zu programmieren
  • Nach der Löschung müsste vermehrung die Tatsache speichern, dass die Löschung durchgeführt wurde. Sonst läuft die entsprechende Abfrage bei jeder künftigen Synchronisierung, auch bei Gärtnern bzw. auf Geräten, auf denen diese Daten gar nie synchronisiert wurden
  • Obiges macht die Sache noch aufwändiger zu programmieren
  • ...und dieser komplexe (und damit schwer verständliche und fehlerträchtige) Code, wird in alle Zukunft weiter bestehen und bei jeder künftigen Synchronisierung ausgeführt werden

Um die Komplexität wieder loszuwerden, müsste ich in einer vernünftigen Zeitspanne, z.B. in einem Jahr, diesen Code wieder entfernen.

Das Ganze ist daher nicht sehr appetitlich.

Ausserdem: Ein Gärtner hätte vor der Löschung die Daten exportieren können und hätte sie somit in Excel weiterhin verfügbar.

Darum meine Frage an dich: Ist es nötig, die früher synchronisierten Ortsangaben zu löschen?

@barbalex
Copy link
Owner

Nicht-mehr-Synchronisieren von Ortsangaben ist in Version 1.8.0 implementiert

@barbalex
Copy link
Owner

Löschen lokal geladener Ortsangaben bei Gärtnern in Version 1.12.0 implementiert

@Seraina1
Copy link
Collaborator

Habe jetzt an der nicht perfekten Umgehung gearbeitet.

Es gibt ein Problem. Und das würde auch bei der sauberen Implementation auftreten.

Ich kann stoppen, dass die Ortsangaben vom Server synchronisiert werden.

Das Problem ist: vermehrung funktioniert auch ohne Internetverbindung. Und zwar, indem es alle Daten, die man zugreifen darf, auf das jeweilige Gerät synchronisiert.

Will heissen: Gärtner, die auf dem betreffenden Gerät schon einmal angemeldet haben, haben früher die Ortsangaben synchronisiert. Und sehen sie darum weiterhin.

Was sie nicht mehr synchronisieren können und daher nicht sehen:

  • Ortsangaben von Herkünften, die seit der Anpassung von vermehrung (also der nächsten Version) erstellt werden
  • Ortsangaben aller Herkünfte, sobald sie auf einem neuen Gerät oder Browser anmelden

Ausserdem würden sie Änderungen von Ortsangaben nicht mehr synchronisieren. Will heissen: Die Ortsangaben, die sie sehen, können (theoretisch bzw. in Einzelfällen) veraltet sein.

Das kann ich nur verhindern, indem ich den Code so anpasse, dass er bei Gärtnern während der Synchronisation alle Ortsangaben, die zuvor auf das Gerät synchronisiert wurden, löscht.

Das Problem hierbei:

  • Es ist aufwändig zu programmieren
  • Nach der Löschung müsste vermehrung die Tatsache speichern, dass die Löschung durchgeführt wurde. Sonst läuft die entsprechende Abfrage bei jeder künftigen Synchronisierung, auch bei Gärtnern bzw. auf Geräten, auf denen diese Daten gar nie synchronisiert wurden
  • Obiges macht die Sache noch aufwändiger zu programmieren
  • ...und dieser komplexe (und damit schwer verständliche und fehlerträchtige) Code, wird in alle Zukunft weiter bestehen und bei jeder künftigen Synchronisierung ausgeführt werden

Um die Komplexität wieder loszuwerden, müsste ich in einer vernünftigen Zeitspanne, z.B. in einem Jahr, diesen Code wieder entfernen.

Das Ganze ist daher nicht sehr appetitlich.

Ausserdem: Ein Gärtner hätte vor der Löschung die Daten exportieren können und hätte sie somit in Excel weiterhin verfügbar.

Darum meine Frage an dich: Ist es nötig, die früher synchronisierten Ortsangaben zu löschen?

Dies klingt ja ziemlich komplex!
Grundsätzlich hatten wir bisher, so viel ich weiss, noch nie ein Problem damit, dass Gärtnereien anhand der Ortsangabe die Stellen aufgesucht und Pflanzenmaterial eigenhändig gesammelt haben. Zudem wird die Datenbank von den Gärtnern fast gar nicht genutzt... Daher würde ich aufgrund der aktuellen Nutzung der Datenbank von dieser grossen Anpassung absehen und dies erst wieder prüfen und in Erwägung ziehen, wenn die Problematik konkreter wird.

@barbalex
Copy link
Owner

Wie oben erwähnt habe ich dieses Feature dann doch noch implementiert. Werde es in einem Jahr wieder entfernen.

Sorry, dass ich verwirrend kommuniziert habe...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants