@davidschilling sagte in Version 3.74:

Das heißt, dass jetzt in eigentlich allen Eingabefeldern in ChurchTools auch Emojis genutzt werden können. Also über die Eingabe der Tastatur.

AH! Sehr schön!
Ich wunderte mich, weil ich viel chatte (tolles Feature!) und da schon immer Emojis nutzen konnte. Aber gut, wenn es nun überall geht.

Wir haben gestern auch eine neue App Version rausgebracht. Darin haben wir auch noch weitere Probleme gelöst die es mit der Sperre gab.

Kannst du kurz erläutern, was genau?
(ich vermute mal, die Fehlermeldung wurde überarbeitet)
Im Playstore werden mir nur neuen Funktionen am Chat (Antworten, Anzeige Beitritte/Bilder/... und Markdown) angezeigt.

Die Lösung es in ChurchTools zu deaktivieren ist für Admins gedacht die denken was wir an der Stelle getan haben reicht nicht.

😲
Das verstehe ich nicht.
Wenn es mir nicht reichen würde, dass man nur bei aktivierter Displaysperre in ChurchWeb "reinkommt" ... wie kann ich das Sicherheitsniveau dadurch erhöhen, dass ich diese Abfrage deaktiviere?

Ich würde nach wie vor nicht wollen, dass jemand aus meiner Gemeinde die ChurchTools App nutzt ohne eine Displaysperre eingerichtet zu haben. Das zeigt, dass es generell an Sicherheitsvertsändnis fehlt und dann sollte man da ansetzen.

Ich finde, das Sicherheitsverständnis daran festzumachen, greift zu kurz.... allein schon, weil ja selbst die ChurchTools-App einen "freien" Bereich hat. (Das erkennt an, dass man durchaus Dinge auf dem Handy haben kann, die auch ohne Displaysperre sicher sind)
Dann fällt spontan noch die Diskrepanz zum Zugang via Browser auf: Da gibt's außer einem wöchentlichen (?) Tokenverfall überhaupt keine Absicherung - wer seinen Rechner ohne Benutzer/PW als Admin und voller PW-Speicherung betreibt, wirft dieselben Daten quasi "auf die Straße".
... erst Recht, wenn dieser Browser auf seinem (ungesicherten) Handy läuft.

Meist, wenn es einige Releases gibt die nicht so groß sind liegt das daran, dass im Hintergrund an größeren Sachen gearbeitet wird, die nicht mal schnell in einer Version fertig werden.

Da bin ich sicher. 😁 😁
Ich weiß, dass es immer etwas heikel ist, konkrete Termine & Features zu nennen, aber es würde doch deutlich beruhigen, wenn man ein klein wenig wüsste, woran so grob gearbeitet wird.
... besonders, wenn es um FRs geht, die seit > 5 Jahren da herumliegen und relativ hoch gevotet sind.
So sitze ich immer wieder neu auf Kohlen und bin immer wieder neu enttäuscht, wenn es nicht kommt - obwohl ihr vielleicht schon längst beschlossen habt, das nicht zu machen ... oder, dass es in 14 Tagen kommt.

Gruß

Simon

@davidschilling Liebe Grüße von unserem Pfarramtssekretariat: Die neue Suchleiste ist total super - ein echter Zeitsparer 🙂

@bwl21
Spiegelei hin, Rührei her, wir halten also fest: Der alte WYSIWYG-Editor setzt ein DIV (ob gewollt oder nicht), und dieses macht nun bei meinem konkreten Beispiel bei der Umwandlung zu MD erst mal Darstellungsprobleme. Ob bei @Herr-O noch andere Dinge eine Rolle spielen, sehen wir evtl. noch.

Was die Erwartungen angeht, da ist es mir als Anwender herzlich egal, ob meine Beschreibung nun als Absatz oder als Division zu bezeichnen ist. Ich denke, es ist schon klar geworden, was ich meine. Aber ich erwarte eigentlich schon, dass solche "banalen" Dinge aufgefangen werden. Man kommt ja von einem Editor, den man kennt, und dessen "Macken" (ich nenne es mal so, auch wenn es technisch bestimmt falsch ausgedrückt ist) bekannt sind (<div>statt <p>).
Insofern habe ich deinen Versuch,

tiefer zu graben, um die Erwartungen realistischer zu bekommen,

(noch) nicht wirklich verstanden...
Das einzige Style, das in meinem Beispiel inline geliefert wird, ist <strong>. Und das wird ja auch korrekt umgesetzt, Schriftgrößen habe ich nicht verändert.
Ich stimme überein, wenn es darum geht, copy&paste Texte, die evtl. viele Inline-Styles aus anderen Anwendungen enthalten, zu konvertieren, dass es da sicher nie 1:1 gehen wird. Aber Texte, die im alten Wiki-Editor geschrieben wurden, die sollten wenigstens nahezu zu 100% korrekt umgesetzt werden.

Vielleicht wäre aber das hier was für dich 😉

2021-05-23_20h33_30.png

@matthiasdupont
Ich würde eher formulieren: "Liegt daran, dass die neueste App-Version fordert, dass ...." (ein Gerätepasswort war ziemlich sicher vorher auch schon nicht eingerichtet und es kam trotzdem zu keiner Fehlermeldung).

Außerdem:

wird das sehr unterschiedlich gemeldet (je nachdem, was das eigene Betriebssystem so denkt), ist nur dadurch zu vermeiden, dass man für sein Mobilgerät den "Schutz" (z.B. mit einer PIN) aktiviert und in der Folge bei jeder Nutzung des Geräts (egal, ob man CT oder deren schutzwürdige Sektion nutzen möchte) es entsperren muss. Nicht zuletzt: Hat nichts mit der hier beschriebenen Version 3.72.1 zu tun - hängt von der App-Version ab und die wurde schon

(nur mal, als Reader's Digest aus den diversen Threads)
😅

@hbuerger sagte in Version 3.72:

Also, dann wäre ich persönlich eher dafür den Changelog leserlich in der App drin zu haben zum selber nachschauen. Damit würden wir mehr Leute erreichen als nur über das Forum

Ich finde auch ein Changelog in der App, wie es @hbuerger vorschlägt gut, aber zusätzlich als Popup, das nach der Installation einer neuen Version, beim ersten Start automatisch angezeigt wird, mit der Option "beim nächsten Start nicht wieder anzeigen". Einen Menüpunkt " Was ist neu" um das Changelog noch mal nachlesen zu können sollte es natürlich auch geben. Diese Variante hat den Vorteil das alle Nutzer die automatisches Update eingestellt haben sofort über die Änderungen/Neuigkeiten informiert werden!

@jziegeler wunderbar 👍

@davidschilling 👍 klappt

@jziegeler Danke.
Ja, das mit den Entwicklungszyklen kenne ich aus meinem Arbeitsumfeld (bei uns auf der sind die noch viel länger) und auch dass Grundlagenarbeit oft eine Menge Sprints "reifen", die niemand sieht.
Aber mir ging es auch nicht um FRs aus diesem Jahr ... z.B. der WebChat (drückt mich am meisten) ist von März 2020 - da hattest du ein wenig geteasert.😅
Andere (die mich interessieren würden) sind schon seit 2018 in der Pipeline ....

Wie gesagt: Das soll echt kein Angriff sein ... aber ein wenig gezwackt hat das schon.😅

@sitobias Die Beziehung bleibt sichtbar, aber das Kind ist dann nur mit der Option "beliebige weitere Person..." mit anmeldbar. Hintergrund ist, dass die Kinder erstens irgendwann eine eigene E-Mail-Adresse haben und zweitens zunehmend an Veranstaltungen/Freizeiten etc. unabhängig von den Eltern teilnehmen und sich selbst anmelden wollen.

@DJSudermann

Maybe

Den Eventfilter finde ich auch eine super Sache.

Mir fehlt aber, dass man da zusätzlich nach dem Dienst filtern kann, in dem jemand an beim entsprechenden Event eingeteilt ist/war.

Ist sowas noch geplant?

@MatthiasT dann einmal bitte mit genaueren Infos an den Support wenden.

Diesen Menüpunkt findet dort jeder Nutzer, halt nur mit seinen E-Mails, die er verschickt hat, also macht die Platzierung dort durchaus Sinn, auch wenn sie vielleicht nicht optimal ist. Dass der Admin dort alle Systemmails und so weiter sieht, könnte man auf jeden Fall optimieren ...

ok, wer lesen kann... und so

"In der Rechteverwaltung werden uns nun orange Häkchen angezeigt, die klarmachen, dass bereits Rechte vom Gruppentyp Diakonat gesetzt sind und diese bis zur 1. untergeordneten Gruppe bereits gelten. Wir können nun für die 2. Ebene noch zusätzlich Rechte setzen." aus dem Blog...

Mir ist grad erst beim zweiten Mal lesen aufgefallen, dass es um die Ebenen geht. Nachdem wir immer alle Ebenen berechtigen hatte ich das nicht kapiert. Aber nachdem die Funktion jetzt eh da ist, wäre das vielleicht eine Idee, es auch für meinen beschriebenen Anwendungsfall zu verwenden 😉