Ich fände TAGS unter Events auch super, allerdings aus einem anderen Grund:

Derzeit planen wir unsere Gottesdienste mit Google Tabellen. Dabei nutzen wir verschiedene Farben für verschiedene "Arten" von Gottesdienst.

Normaler Gottesdienst mit interner Predigt Gottesdienst mit Gastprediger Gottesdienst mit Predigtreihe Zeugnisgottesdienst usw.

Durch die Farben wird es sehr übersichtlich, wann was stattfindet. Das hilft uns bei der Planung. In CT vermisse ich eine ähnliche Option. TAGS wären evtl. eine gute Hilfe, dass nicht jeder Sonntag völlig gleich aussieht.

Derzeit sehe ich in CT nur zwei Möglichkeiten. Entweder über "Weitere Infos zum Event" einen (kleinen) Hinweis eintragen oder einen "Dienst" erfinden, der denn eine eigene Spalte bekommt. Letzteres wäre schon sehr verbogen, da man ja keine Personen sondern Gottesdienst-Typen zuweist. "Weitere Infos" ist halt eher klein und unscheinbar.

Also +1 für TAGS. Noch besser wäre es, wenn sich zB die Hintergrundfarbe der Zelles des Tags einstellen ließe. 🙂

@thommyb Dafür voten 😉

@kneukirch Der Haken ist, daß CT zwar weiß, daß keine Berechtigung vorliegt (='du darfst nicht'), aber nicht an welcher Stelle der Fehler vorkommt.
(Ich nehme an, die Anmeldemaske wird Standardroutinen aufrufen, die dann selber nicht wissen, woher der Aufruf kommt.)

Man könnte die Fehlermeldungen ändern, Tools/Werkzeuge > Übersetzungen > error.forbidden.view
Falls man's ändert, sollte vermutlich die Meldung "Du darfst das Objekt "{model}[{id}]" nicht sehen." so stehenbleiben und nur eine Ergänzung erfolgen, also hintendran " Bist du eingeloggt?" anhängen.
Oder auch "Du hast keine Berechtigungen das Objekt "{model}[{id}] zu sehen oder bist nicht eingeloggt."

Aber ob das wirklich SInn macht?

@michaelg sagte in [CCal] Alle Räume buchen:

Bei der Raumbuchung in CCal gibt es im Dropdown Menü die Kategorie. Z.B. --Raum--
Wenn ich nun alle Einheiten einer Kategorie buchen möchte, fände ich es richtig praktisch, wenn ich --xxxxx-- Auswähle und mir dann alle Ressourcen dieser Kategorie unten eingetragen werden.

Ja das wäre äusserst praktisch, denn momentan muss man

a) Bei Anfragen jede einzelne Ressource anwählen
b) der Verwalter (ich) muss jede Ressource als einzelne Anfrage bearbeiten

@hw-arche-winti in deinem ersten Beitrag oben, rechts auf die drei Punkte und dann auf bearbeiten.

Im Dialogfeld "Abwesenheiten bearbeiten" heißt das Bestätigungsfeld "Abwesenheit eintragen". Hier wäre ein "Speichern"-Button (im einheitlichen Dunkelblau) besser.
Screenshot 2023-03-28 131219.jpg

@rstaudinger man kann nur Leute einladen, die den Kalender auch sehen können.

Das halte ich auch für eine unglückliche Einschränkung. Manche machen einen Workaround über einen Event wo sie die einzuladenden Personen dann in einen Dienst eintragen ...

+1

@henric-resa ja ... so wie ich den anderen Vorschlag sehr gut und wichtig fand, so finde ich das hier auch eine gute Idee.

Mindestens beim Kopieren hätte ich ohnehin erwartet, dass nur die gewünschten Rollen des Originals aktiviert werden.

@andy danke

Hallo @thommyb

Vielen Dank für deinen Hinweis. Es stimmt, dass die Informationen auch auf der CCLI-Website verfügbar sind. Allerdings wäre es für die Benutzer von ChurchTools praktischer und zeitsparender, wenn diese Details direkt in der Web-UI verfügbar wären. So könnten sie die automatischen Meldungen schneller und einfacher überprüfen, ohne sich auf einer externen Website anmelden und navigieren zu müssen.

Mein Vorschlag zielt darauf ab, den Arbeitsablauf für ChurchTools-Benutzer zu optimieren und die Benutzerfreundlichkeit der Software zu erhöhen. Ich hoffe, dass das ChurchTools-Team diesen Vorschlag in Betracht zieht, um die CCLI-Auto-Reporting-Funktion noch effizienter zu gestalten.

Nochmals vielen Dank für deine Antwort und einen regen Austausch im Forum!

Beste Grüße,
Markus

@fschrempf sagte in Email an Gruppen ohne in ChurchTools eingeloggt sein zu müssen:

Das ist sehr interessant. Verstehe ich das richtig, dass Korga sich die Daten über die API in die eigene Datenbank holt und dann eine Art Mailinglisten-System damit implementiert?

Ja, genau. Ich fand es nicht so einfach, Informationen über bestehende Software für Mailinglisten zu finden und habe es deshalb selbst implementiert. Korga ist kein E-Mail-Server, sondern verbindet sich über IMAP mit einem catchall Postfach, wie man es bei Strato, IONOS und anderen Hostern einrichten kann.

Ich verstehe nicht ganz wie die Frage gemeint ist. Man legt die Verteiler in Korga an und die Mitglieder der Verteiler werden in ChurchTools über die Mitglieder der Gruppe verwaltet. Wo sollte da noch eine Drittanwendung ins Spiel kommen?

Korga ist besagte Drittanwendung. Man kann E-Mail-Verteiler nicht über die ChurchTools-Oberfläche erstellen.

Ich persönlich würde selbst hosten. Aber tatsächlich steht Korga da in Konkurrenz mit meiner eigenen Idee. Ich habe vor die E-Mail Verteiler in der selbsgeschriebenen Python/Django-App (momentan nur Frontend), die wir als Cloud-Portal nutzen umzusetzen. Ich will dort die Möglichkeit einbauen, dass man für auswählbare CT Gruppen eine Verteiler-Adresse anlegt und entweder das Handling der Mails dann direkt in die App einbauen oder eine Synchronisation mit einem Mailinglisten-System (MailMan3 oder Sympa) einzurichten.

Das ist eine sehr interessante Idee. In euer Cloud Portal könntest du Korga aber trotzdem einbinden. Entweder als JavaScript Komponente (das Frontend von Korga basiert auf Vue.js/Typescript) oder indem du REST API von Korga verwendest. Mehr dazu schreibe ich dir privat, das sprengt sonst den Rahmen dieses Forums.

Ich würde mir wünschen, dass der Chat prominenter auf der Startseite erscheint.
Warum? -> intuitive Bedienung
Use Case -> eine Person (typ. Gemeindemitglied oder Interessent) registriert sich für irgend eine Gruppe wozu auch ein Chat existiert.
Wenn man ChurchTools nicht kennt und den Weg bis zum Login und zur Startseite geschafft hat findet kaum einer den Chat im Profil-Drop-Down. Dasselbe gilt für die Bewerbung der App.
Ich finde es auch wenig zielführend im öffentlichen Wiki erst mal eine CT Anleitung hinterlegen zu müssen...

ec8cb00f-123d-40fc-a8f5-e9a6e8387aad-image.png