Hallo,
Ich bin neu hier, habe diese Woche meine erste Gladys-Installation durchgeführt und tapse daher noch bei einigen Dingen im Dunkeln. Meine Installation ist also auf dem neuesten Stand, ich habe das bereitgestellte Image für den RPI verwendet.
Um anzufangen, habe ich ein Problem mit etwas ganz Einfachem: dem Kalender.
Ich habe ihn in meinem Gladys-Konto eingerichtet, kein Problem (Kategorie « Andere », da mein Caldav-Server selbst gehostet wird).
Ich habe ein zweites Benutzerkonto erstellt, es ist unmöglich, ihm denselben Server zuzuordnen. Ich mache ihn zum Administrator, dann kann ich die Konfiguration fortsetzen.
Wenn ich dieses zweite Konto mit einem zweiten Benutzer mit caldav verbinde, funktioniert es. Allerdings kann ich ihm nicht dasselbe Konto wie mir einrichten (schade, da wir ein gemeinsames Konto haben, das genau dazu dient, unsere Kalender zu teilen).
Vielen Dank im Voraus, wenn ihr einen Tipp habt, und herzlichen Glückwunsch zu all der bereits geleisteten Arbeit!
Hallo @pap, willkommen,
Ja, das ist ein Fall, den ich nicht vorhergesehen hatte. Es muss Konflikte in der Datenbank geben. Ich versuche, das Problem zu reproduzieren und so schnell wie möglich zu beheben.
Übrigens, welchen Dienst nutzt du, um deinen Kalender zu hosten?
Danke für deine Antwort.
Ich verwende Radicale.
Willkommen im Forum @pap und vielen Dank für dein Feedback, das hilft uns weiter! ![]()
@bertrandda Mal sehen, ob die Lösung darin besteht, den Kalender zweimal zu synchronisieren (vielleicht), oder ob man in Gladys cross-user-Kalender erstellen sollte?
Dazu habe ich kürzlich einen Vorschlag gemacht, um genau solche Konflikte zu vermeiden:
Kalender und Dashboards zwischen Nutzern teilen zu können, wäre tatsächlich super…
Bei der Reproduktion gibt es tatsächlich bestimmte Eindeutigkeitsbeschränkungen bei Feldern, die Probleme verursachen.
Ja, das Teilen von Kalendern intern in Gladys ist eine gute Lösung.
Später möchte ich das Eindeutigkeitsproblem trotzdem beheben, denn stellen Sie sich eine Familie vor, die eine gemeinsame Nextcloud-Instanz (oder iCloud, Google… ich habe den Eindruck, dass das mit Radicale nicht möglich ist) verwendet. Wenn sie die Freigaben direkt im Nextcloud-Kalender konfigurieren, werden die externen IDs wahrscheinlich bei den Synchronisationen dieselben sein.
Egal was passiert, in beiden Fällen ist Entwicklung erforderlich. Die interne Freigabe in Gladys sollte keine Probleme verursachen, aber die Behebung der Eindeutigkeit wird kompliziert. Bei den Selectoren bin ich mit dir einer Meinung, Pierre-Gilles. Aber hier gibt es auch die externe ID und wir stoßen auf dieselben Probleme, die hier erwähnt wurden Gladys V4 - Affichage de capteurs dans l'interface - #11 par pierre-gilles, wenn wir die Beschränkungen entfernen möchten. Zum Beispiel möchte ich die Eindeutigkeitsbeschränkung für t_calendar.external_id entfernen, die selbst zwischen mehreren Benutzern nicht notwendig ist, denn wenn wir einen Kalender abrufen, geben wir seinen Benutzer an. Wenn wir wirklich eine wollen, können wir sie auf die Kombination aus externer ID und Benutzer-ID setzen.
Ich stimme zu, dass das ein Problem ist!
Um die Beschränkung auf external_id zu entfernen, muss man schauen, weil wenn man anfängt, mehrbenutzerfähige Kalender zu machen, könnte das nicht mehr der Fall sein! (Ein Kalender könnte im Besitz der ganzen Familie sein)
Ich wäre eher dafür, etwas zur external_id hinzuzufügen, das sie noch eindeutiger macht (notfalls den Benutzerauswahl desjenigen, der den Kalender hinzufügt, in die externe ID einfügen).
Ja, das wird sicherlich die Fehlerfälle reduzieren, aber im speziellen Fall des Kalender-Sharing auf der Seite des Kalender-Hosters denke ich, dass das passieren kann. Naja, wir werden es später sehen, zunächst einmal machen wir das Teilen möglich, ich habe einen PR begonnen Add internal calendar sharing by bertrandda · Pull Request #1337 · GladysAssistant/Gladys · GitHub
Fertig, der PR ist bereit, wenn ihr testen wollt
hallo,
wie geht man vor, um zu testen?
entschuldigung, ich kenne mich nicht so gut mit github und so aus ![]()
Um eine PR funktional zu testen, wird das hier von Pierre-Gilles erklärt: Review des PR - J'ai besoin de vous!. Allerdings kannst du das nicht direkt auf deinem RPI machen.
Es gibt eine Diskussion, die in der PR begonnen hat, also werden sicherlich Änderungen kommen.
ok danke für deine Antwort.
Ich habe meine Antwort auf die PR gesetzt!
Zur Information, wir diskutieren über die Art des Teilens:
- Entweder teilen wir einen Kalender mit der gesamten Instanz (im Modus „geteilter Kalender: ja/nein“)
- Oder wir schlagen vor, einen Kalender nur bestimmten Personen der Instanz zu teilen
Beide Optionen sind möglich, aber Option 2 ist auf vielen Ebenen doch etwas komplexer (wie läuft das mit den Szenen?).
Siehe meine 2 Nachrichten auf Github
Ich poste hier das, was wir uns auf Github gesagt haben.
Für das Archiv gehen wir auf „geteilt/privat“ und nicht auf die Benutzerfreundlichkeit, die wenig nützlich/komplex umzusetzen ist, ohne viel zu bringen ![]()
Siehe Github-Diskussion: Add internal calendar sharing by bertrandda · Pull Request #1337 · GladysAssistant/Gladys · GitHub
Zur Information, ich habe gerade die Kalenderfreigabe-Verwaltung in eine Gladys-Instanz gemerged ![]()
Ihr könnt @bertrandda für die gesamte Arbeit danken ![]()
In der UI sieht es so aus:
Der PR ist hier verfügbar:

