Antragsgrün 4.2 im Anflug: Designwahl, private Notizen

In wenigen Tagen erscheint Antragsgrün 4.2. Bereits jetzt kann der erste, stabile Release-Kandidat (RC) ausprobiert werden. Darin enthalten sind Funktionen, die schon häufig und auch seit Langem nachgefragt wurden:

Screenshot Farbschema-Einstellungen
Farben und Schriften können nun selbst angepasst werden. (Klicken, um Bild zu vergrößern)

Das Design von Antragsgrün kann nun direkt über das Backend angepasst werden. Eurer Kreativität (oder euren CI-Designregeln) zu Farben und Schriftarten sind damit keine Grenzen mehr gesetzt. Und falls doch mal was schiefläuft: Alle Werte lassen sich wieder auf die Standardeinstellungen zurücksetzen. Seit einigen Monaten bestand darüber hinaus die Möglichkeit, das Seitenlogo pro Veranstaltung neu hochzuladen: Der neue Logo-Picker macht die Anpassungen nun komfortabler als bisher.

Als zweite große Neuerung wird die Möglichkeit eingeführt, dass Nutzer*innen private, also nicht nach außen sichtbare, Notizen zu Anträgen hinterlegen können. Diese Kommentarfunktion orientiert sich dabei an den Textabsätzen und ist vor allem zur Vorbereitung von Live-Diskussionen auf Tagungen nützlich.

Neben diesen beiden großen Neuerungen werden natürlich auch einige Fehler behoben, z.B. der Erstellung aller PDFs in ein ZIP-Paket. Wer sich jetzt bereits an die Vorabversion wagt, kann später natürlich jederzeit zur endgültigen Version von Antragsgrün 4.2 aktualisieren. Weitere Informationen findet ihr unter https://github.com/CatoTH/antragsgruen/releases.

Auf Fehlersuche? Tipps zu ePartool, Antragsgrün, Nextcloud, WordPress & Co.

Wenn dieser Fehler auftaucht, ist guter Rat teuer … oder?

Mittlerweile stehen viele hochwertige Open-Source-Anwendungen für eure Onlineauftritte oder Onlinezusammenarbeit zur Verfügung. Auch wenn sich Entwickler*innen große Mühe geben eine tolle Software zu schreiben, so schleichen sich doch immer wieder Fehler ein. Ebenso können sich im Zusammenspiel zwischen Anwendung und eigenem Server Probleme auftun, die einer Lösung bedürfen. Vor der Lösung steht jedoch die Fehlersuche: Oft lässt sich nicht per Augenschein erkennen, woran es hakt. Im Folgenden geben wir ein paar Tipps, wie ihr euch dem Problem nähert.

Die Log-Datei ist dein Freund!

Glücklicherweise werdet ihr bei der Fehlersuche von der Software aktiv unterstützt. Die meisten Anwendungen und auch die Server selbst legen verschiedene Protokoll-Dateien an. In diesen wird aufgezeichnet, welche Aktionen stattgefunden haben bzw. bei welchen Aktionen unvorhergesehene Ereignisse auftraten. Aus unserer Erfahrung lohnt es sich bei Problemen im ersten Schritt die Log-Dateien der betroffenen Anwendung anzusehen. Die meisten Fehler lassen sich hierüber bereits eingrenzen.

Log-Dateien werden fast immer als Dateien mit der Endung .log angelegt. Es handelt sich dabei aber in der Regel um Textdateien, die sich mit jedem beliebigen Editor öffnen lassen (Notepad, Wordpad, usw.).

In den Logs der Anwendungen wird in der Regel protokolliert, wenn einzelne Funktionen oder Programmbibliotheken eine Aufgabe nicht ausführen konnten. Das könnte z.B. daran liegen, dass Zugriffsrechte nicht korrekt gesetzt waren, benötigte Dateien nicht gefunden wurden, ein Datenbankserver nicht oder nicht schnell genug geantwortet hat, oder Funktionen schlichtweg Fehler hatten (Beispiel: Versuch durch 0 zu teilen). Dennoch können sich die Inhalte der Log-Dateien bisweilen sehr unterscheiden – die Entwickler*innen können sich dafür entscheiden, nicht nur fatale Fehler zu vermerken, sondern auch bereits Warnmeldungen oder auch erfolgreich durchgeführte Aktivitäten. Letzteres kann zwar von Interesse für die Entwickler*innen sein, allerdings im Dauerbetrieb auch mit Datenschutzerfordernissen kollidieren. Daher lassen sich Anwendungen häufig darauf konfigurieren, ob sie sich im Betriebsmodus für „Entwicklung“ (development, debug modus) oder für „Produktion“ befinden.

Anhand von vier Anwendungen möchten wir euch beispielhaft aufzeigen, wo Log-Dateien zu finden sind:

Antragsgrün: Die Software zur demokratischen Texterstellung führt eine Log-Datei unter /runtime/logs/app.log. Die Einträge sind dabei sehr ausführlich gehalten.

ePartool: Das DBJR-Konsultationswerkzeug führt eine Log-Datei unter /runtime/logs/application.log. Die neuesten Einträge finden sich ganz unten.

Nextcloud: Die populäre Open-Source-Plattform für Dateiaustausch und Zusammenarbeit führt zwei unterschiedliche Log-Dateien. Während die Datei /data/updater.log nur über Installationsvorgänge Buch führt, ist die Datei /data/nextcloud.log für den täglichen Betrieb gedacht. Nextcloud beinhaltet zudem eine Zugriffsmöglichkeit auf diese Log-Datei über das Admin-Backend. Hier kann man auch einstellen, welche Art von Fehlern oder Problemhinweisen protokolliert werden sollen.

WordPress: In der Standardinstallation führt das CMS keine Log-Datei. Durch zwei Einträge in der Datei wp-config.php kann das Loggen aber aktiviert werden:

define('WP_DEBUG', true);

define('WP_DEBUG_LOG', true);

Weitere Informationen finden sich unter https://codex.wordpress.org/Debugging_in_WordPress.

Wenn man Log-Dateien über das administrative Backend betrachten und auswerten möchte, muss zudem ein Plugin installiert werden, z.B. der »Error Log Monitor« [https://de.wordpress.org/plugins/error-log-monitor/]

Weitere Log-Dateien

Gelegentlich helfen die Log-Dateien der Anwendungen aber nicht weiter. Das kann daran liegen, dass die Anwendung auf Probleme stößt, die außerhalb ihrer eigenen Analysemöglichkeit liegen. Im Extremfall wäre das bei einem Hardware-Defekt der Fall: Ob alle Kabel richtig stecken oder ob der Servercomputer selbst richtig rechnet, kann eine Anwendung kaum erkennen. Auf Log-Dateien der Betriebssystem-Ebene hat man jedoch in der Regel als Mieter*in eines Webhostings keinen Zugriff. Professionelle Provider stellen durch Überwachungsprogramme sicher, dass diese Art von Fehlern von ihnen selbst zeitnah entdeckt werden.

Zwischen dem Betriebssystem und Anwendungen wie den vier oben genannten liegt allerdings noch die installierte Web-Server-Software. Ein Web-Server ist meist als Sammelbegriff mehrerer Programme zu verstehen und beinhaltet neben dem eigentlichen Web-Server-Programmen wie Apache oder Nginx auch die PHP-Programmiersprache oder eine Datenbank). Diese alle führen ebenfalls Log-Dateien.

Welche Log-Datei hilft wann:

Web-Server: Hier werden der Zeitpunkt und die Herkunft der Zugriffe (IP-Adressen), Größe der abgerufenen Dateien und Statusmeldungen zu den einzelnen Verbindung geloggt. So lässt sich schnell herausfinden, ob es zeitgleich übermäßig viele Zugriffe gab (und daher der Server sehr langsam wurde) oder ob bestimmte Dateien nicht gefunden wurden (die bekannte Statusmeldung 404). Probleme im internen Programmablauf, die nicht die Zugriffe betreffen, werden meistens in einer separaten Log-Datei protokolliert.

PHP: Programmierfehler sind häufig kleine Tippfehler, wie eine vergessene Klammer zum Abschluss einer Funktion oder ein Buchstabendreher. Wenn der PHP-Interpreter nicht versteht, was er zu tun hat, können diese Fehler entweder geloggt oder direkt angezeigt werden. Letzteres hilft zwar, Fehler schnell zu finden, verrät aber Externen auch viel über mögliche Angriffspunkte. Bei PHP-Skripten kann man auch ohne viel Programmiererfahrung das Anzeigen von Fehlern aktivieren, indem man in die ersten Zeilen (nach dem Startkennzeichen <?php) folgende Befehle ergänzt:

error_reporting(E_ALL);
ini_set('display_errors', '1');

Voraussetzung dafür, dass nun konkrete Fehlermeldungen angezeigt werden, ist, dass der Server grundsätzlich dazu konfiguriert ist. Bei den meisten Providern lässt sich das im Administrationsmenü aktivieren und wieder deaktivieren. Bei direktem Server-Zugang und Schreibrechten auf die php.ini-Einstellungsdatei lässt sich dies durch display_errors = on aktivieren.

Datenbank: Da es verschiedene weit verbreitete Datenbanken gibt, fällt die Erkenntnismöglichkeit hier sehr unterschiedlich aus. General lässt sich über die Log-Datei herausfinden, ob der Service korrekt gestartet wurde, ob es gescheiterte Zugriffsversuche gab (z.B. wenn die Zugangspasswörter in der zugreifenden Anwendung falsch abgespeichert waren). Möglicherweise kann man über die Statusmitteilungen auch herausfinden, ob Datenbank-Anfragen ineffizient gestellt wurden und daher sehr lange zur Beantwortung brauchten oder gar komplett scheiterten. Dies könnte z.B. der Fall sein, wenn Suchindizes nach größeren Datenveränderungen nicht neu angelegt wurden oder durch zu viele parallel Schreibvorgänge versucht wurden. Auch der Ursprung von fehlerhafte Zeichenausgabe (Umlaute oder falsche Symbole) könnte hier liegen: Die Kette der Zeichenkodierung muss von der Datenbankablage über die Verbindung und Verarbeitung bei der Anwendung bis hin zum Browser bei den Nutzer*innen durchgehend richtig sein.

Der Einfluss von Fehler-Logs auf die Rechenzeit

Das Erstellen von Log-Dateien benötigt immer etwas Rechenzeit. Diese fällt umso größer aus, wenn man sich auf einem höheren Software-Level befindet (System → Server-Software → Anwendung). Daher lohnt es sich bei viel frequentierten Internet-Angeboten, im stabilen Betrieb das Logging durch die Anwendungen soweit wie möglich zu reduzieren.

Was ist eigentlich … ein »Cronjob«?

Wenn man neue Website-Anwendungen oder Online-Portale einrichtet, findet sich in der Installationsanleitung häufig auch der Hinweis, dass ein »Cronjob« einzurichten sei. Aber worum handelt es sich dabei eigentlich?

Cronjobs beinhalten Aufgaben, die regelmäßig oder zu bestimmten Zeitpunkten stattfinden sollen. Ein Beispiel wäre ein automatischer Versand von E-Mails zur Erinnerung an Fristen oder tägliche Zusammenfassungen eines Forums. Diese Mails werden in der Regel nicht jedes Mal von einem Menschen zusammengestellt, sondern von der Server-Software.

Gebraucht werden diese wiederkehrenden Aufgaben vor allem auf Systemen, die rund um die Uhr laufen: Backups werden automatisiert angelegt oder bestimmte Systembereinigungen können so regelmäßig zu weniger frequentierten Zeiten (meist nachts) ablaufen. Das Entkoppeln von Momenten hoher Systemlast und Hintergrundaufgaben, die auch zu anderen Zeitpunkten stattfinden können, stellt den neben termingebundenen Aufgaben einen weiteren großen Vorteil von Cronjobs dar – ein typisches Beispiel wäre die Aktualisierung eines Inhaltsindexes für die Suchfunktion: Diese muss nicht exakt in dem Moment geschehen, wenn ein neuer Artikel in die Datenbank eingetragen wird, sondern darf meist auch einige Minuten später erst erfolgen.

Auf Arbeitsplatzrechnern oder Notebooks hingegen sind Cronjobs seltener anzutreffen. Oft werden wiederkehrende Aufgaben wie die Suche nach neuen Antivirus-Signaturen einfach jedes Mal bei Systemstart durchgeführt.

Für einen Cronjob benötigt man die Aufgaben, die erledigt werden sollen, niedergeschrieben in einem Programmskript. Skripte in einer Programmiersprache wie PHP, die gerade bei Website-Anwendungen sehr beliebt ist, kann aber von einem Server nicht direkt verstanden werden, sondern muss von einem »Interpreter« übersetzt werden. Welcher das ist, muss beim Einrichten eines Cronjobs ebenfalls angegeben werden. Und schließlich sind die Zeitangaben für das Ausführen wichtig – hier gibt es eine Fülle von Möglichkeiten (siehe Grafik).

Dieser Cronjob läuft jeden Morgen um 7:00 Uhr.

Cronjobs werden tabellarisch in einer Crontab-Datei abgespeichert. Bei Webhosting-Providern ist häufig eine grafische Benutzeroberfläche vorhanden, um die Jobs einzutragen und zu verwalten. Leider sind dabei oft Begrenzungen vorgegeben, z.B. dass mindestens zwei Stunden zwischen der Ausführung eines Cronjobs liegen muss. Für Web-Anwendungen, die häufiger solche Hintergrundaufgaben benötigen, kann man den Cronjob dann ggf. mehrfach anlegen: Während der erste z.B. zu allen ungeraden Stunden ausgeführt würde, wäre Cronjob 2 für alle geraden Stunden zuständig.

Gelegentlich sind Cronjobs mit Zugriffstokens abgesichert, d.h. nur wenn man eine Art Passwort mit übermittelt, wird der Cronjob ausgeführt. Dieses Verfahren setzen wir u.a. im ePartool ein, um sicherzustellen, dass ein Cronjob nicht missbräuchlich zum Spam-Mail-Versenden fehlgeleitet werden kann.

Tipp: Nextcloud komfortabler verwalten mit »OCC Web«

Nextcloud ist ein datenschutzbewusster Gegenentwurf zu den großen Cloudanbietern und bietet vielfältige Möglichkeiten für Dateiaustausch und Onlinezusammenarbeit. Diese selbst betriebene Cloud ist dabei ausgesprochen genügsam: Sogar auf einfachen, gemieteten Webhosting-Paketen kann Nextcloud eingerichtet und mit Freund*innen und Kolleg*innen genutzt werden – sogar noch parallel zu einer bestehenden Website. Zusätzlich Kosten für den Betrieb können so vermieden werden.

Wer so eine kleine Nextcloud-Instanz betreibt, kann damit ohne Weiteres mit 20-50 gleichzeitig aktiven Nutzer*innen zurechtkommen: Die meisten Funktionen und Erweiterungs-Apps funktionieren ganz wunderbar. Einschränkungen treten im Betrieb am ehesten in Erscheinung, wenn mehrere Personen zeitgleich mit derselben Datei arbeiten oder auf aufwändige Funktionen zugreifen. In solchen Fällen geht nichts kaputt, aber es kann passieren, dass Nextcloud Dateien zu konservativ vor einem Löschversuch schützt.

Während die Nutzung von Nextcloud auf einfachen Webhosting-Paketen gut möglich ist, sind hier vor allem die administrativen Funktionen eingeschränkt: Auf einem „richtigen“ Server kann das Nextcloud-eigene Konfigurationswerkzeug OCC benutzt werden; kostengünstige Shared-Hostings erlauben jedoch meist keinen SSH- und damit keinen Befehlszeilen-Zugriff. Das erschwert Wartungsarbeiten, insbesondere wenn nach einer Versionsaktualisierung bestimmte Datenbank-Aktionen oder Neuindizierungen empfohlen werden oder zentrale Aufgaben für mehrere Nutzer*innen anstehen. Diese Aufgaben per Hand direkt in der Datenbank oder in diversen Installationsverzeichnissen zu erledigen ist unkomfortabel, technisch anspruchsvoll und fehleranfällig. Bisher gab es dazu aber keinen anderen Weg.

Das Wehklagen der Admins wurde von den Nextcloud-Entwickler*innen jedoch ernst genommen: Seit wenigen Tagen existiert ein Plug-in (in Nextcloud-Sprache: „App“), das die Befehlszeileneingabe direkt im Backend nachrüstet: Ein Admin kann sich also ins Backend einloggen und die notwendigen OCC-Befehle hierüber eingeben. Auch ist diese „OCC Web“ genannte Erweiterung recht hilfsbereit und zeigt nach Drücken der ENTER-Taste alle verfügbaren Befehle und deren Bedeutung an. Auch Wartungsfunktionen für andere installierte NC-Apps stehen bereit.

Befehlsübersicht von OCC_Web

Als Admin sollte man sich bei allen Vorteilen von »OCC Web« dennoch überlegen, ob man diese Erweiterung nur anlassbezogen oder dauerhaft einrichtet. Möglicherweise tun sich über die administrativen Funktionen Angriffsvektoren für Bots oder Schädlinge auf, die die Nextcloud-Instanz übers Web erreichen können. Generelle gilt, dass jede installierte App stellt ein mögliches Einfalltor darstellt, vor allem wenn sie sich noch recht jung in Entwicklung befindet. Daher könnte es sinnvoll sein, OCC Web nur im konkreten Bedarfsfall zu installieren und danach wieder herauszunehmen – in Nextcloud eine Sache von wenigen Sekunden.

Und wofür steht nun eigentlich das Kürzel »OCC«? „OCC“ wurde bereits eingeführt, als sich das Nextcloud-Projekt noch nicht von OwnCloud abgetrennt hatte. Daher bedeutet die Abkürzung OCC vermutlich „OwnCloud Configuration“ und wurde in Nextcloud so beibehalten.

Barcamptools.eu – Verbesserungen im Januar 2019

Von unserer letzten großen Updaterunde der Barcamptools im Herbst waren noch ein paar Restaufgaben übrig, die erst jetzt fertiggestellt werden konnten. Diese möchten wir euch im Folgenden kurz vorstellen.

Bei der Verwaltung eines Barcamps findet sich unter dem Menüpunkt »Design und Layout« seit Langem auch ein Logo-Generator. Aufgrund der rasanten Browser-Entwicklung der letzten Jahre funktionierte dieser Generator jedoch zuletzt nur noch im Safari-Browser und dann in gar keinem Browser mehr zuverlässig. Nun haben wir den Editor modernisiert, so dass er wieder für alle zur Verfügung steht. Natürlich mit dabei: Das markante Erkennungszeichen der „Barcamp-Flamme“.

Der modernisierte Logo-Generator in Aktion

Was noch neu ist:

Wenn die Benachrichtigungsfunktion (wir haben sie zur besseren Verständlichkeit entsprechend umbenannt) im Barcamp aktiviert ist, wird man jetzt auch über neue Session-Vorschläge informiert.

Das Einloggen erinnert sich nun daran, von welcher Seite aus man den Login aufgerufen hat, so dass ihr euch ohne Neuorientierung auf der gewünschten Seite weiter bewegen könnt. Dies ist insbesondere hilfreich bei Barcamps, die nicht in der öffentlichen Liste erscheinen.

Zu barcamptools.eu →

Antragsgrün-Tipp: Werbebox ausblenden

Die Antragsgrün-Werbebox auf der Startseite…

Eine Open-Source-Software wie Antragsgrün lässt jederzeit Veränderungen an der Programmierung zu. Gelegentlich sind aber Funktionen auch bereits eingebaut, selbst wenn sie für die Außenwelt nicht gut dokumentiert sind. Eine solche Option möchten wir euch heute vorstellen.

Nach der Einrichtung von Antragsgrün findet sich auf der Startseite der neuen Installation eine kleine „Werbebox“, die neuen Interessierten den Weg zum eigenen Antragsgrün erleichtern soll. Der Hinweistext ist allerdings noch für die ursprüngliche Zielgruppe von Partei-Aktiven formuliert und ist daher für andere Zielgruppen, gerade in der Jugendarbeit, eher verwirrend.

…lässt sich durch einen Datenbank-Kniff schnell deaktivieren.

Die Box lässt sich leider nicht über die Einstellungen im Backend unsichtbar schalten. Über einen kleinen Eintrag in der dazugehörigen (MySQL-)Datenbank funktioniert das dennoch. Und das geht so: Ruft die Datenbankadministration bei eurem Server/Provider auf. Oftmals ist das z.B. das Werkzeug PHPMyAdmin. Ihr müsst in der Antragsgrün-Datenbank die Tabelle »site« suchen und dort im Feld „settings“ den Wert von „showAntragsgruenAd“ von „true“ auf „false“ setzen. Im Screenshot anbei seht ihr, wie das Datenbankfeld korrekt formuliert ist.

Tipp: Medien-Uploadproblem nach Neuinstallation des ePartools beheben

Leider hat sich in den letzten Versionen des ePartools ein Fehler eingeschlichen, der nur bei Neuinstallationen auftreten kann. Der Fehler wirkt auf den ersten Blick fatal, doch die Abhilfe ist sehr einfach. Updates von bestehenden Installationen sind von dem Problem generell nicht betroffen.

Worum geht’s: Das ePartool richtet selbsttätig für jede Beteiligungsrunde einen eigenen Medienordner ein, um darin Grafiken und Dokumente abzulegen. Diese Ordner werden aufsteigend durchnummeriert ab der Zahl „1“. Unglücklicherweise scheint der Installer das Anlegen für die allererste Beteiligungsrunde in manchen Server-Settings zu „vergessen“. Das Problem macht sich erst dann durch eine Fehlerseite bemerkbar, wenn ihr euer erstes Bild oder Dokument hochladen wollt – das Bearbeiten von Artikeln und Beiträgen funktioniert jedoch.

Der Fehler ist jedoch schnell behoben. Am besten loggt ihr euch auf dem Server per SFTP ein und erstellt folgenden Ordner mit dem Namen „1“:

epartool-ordner/www/media/consultations/1/

Problem gelöst! Wir werden den Fehler in der nächsten Version des ePartool-Installers beheben. Vor der Winterpause wird jedoch aus Kapazitätsgründen keine neue Version mehr erscheinen.

Barcamptools 2.6: Mehr Kontrolle über eure Daten!

Im Einführungsjahr der DSGVO haben wir unsere Tools noch weiter darauf hin überprüft, euch die volle Kontrolle über eure Daten zu gewährleisten. Ein paar sinnvolle Funktionen hierzu haben wir nun in den »Camper«, die Software hinter barcamptools.eu eingebaut.

Konto löschen

Wenn ihr meint, dass ihr euer Barcamptools-Konto nicht mehr benötigt, so könnt ihr dies jetzt auch selbst löschen. Dazu klickt ihr oben in der Menüleiste auf euren Namen und könnt dann im Profil-Editor die Funktion zum Löschen auswählen.

Achtung: Ihr könnt dies nur tun, wenn ihr bei keinem aktiven Barcamp mehr registriert seid (d.h. das Enddatum aller Barcamps, bei denen ihr registriert wart, muss in der Vergangenheit liegen).

Wenn euer Konto dann gelöscht ist, hat dies folgende Auswirkungen:

  • Die Profildaten werden gelöscht.
  • Passwort und E-Mail werden gelöscht. Ihr könnt euch dann logischerweise nicht mehr einloggen.
  • Die Sessionvorschläge selbst bleiben erhalten, jedoch wird darunter kein Name mehr angezeigt.
  • Kommentare zu Sessionvorschlägen bleiben erhalten, als Autor*in wird aber „Nutzer*in gelöscht“ ausgegeben.
  • Auf öffentlichen Teilnehmendenlisten von alten Barcamps werdet ihr nicht mehr erscheinen.

Opt-In für Teilnehmendenlisten

Standardmäßig wird nun niemand mehr ohne Einverständnis auf öffentlichen Teilnehmendenlisten angezeigt. Ein Einverständnis hierzu wird nun bei der Registrierung zu einem Barcamp abgefragt:

(Ihr seht dieses Feld auch im Formular-Editor, könnt es aber nicht löschen).

Als Benutzer*in könnt ihr dieses Einverständnis pro Barcamp bearbeiten, indem ihr auf die Veranstaltungen klickt und dann unten in der rechten Seitenleiste auf „Meine Daten“.

Damit habt ihr also jetzt die volle Kontrolle darüber, ob ihr auf der Teilnehmerliste erscheinen wollt.

Achtung: Dies bedeutet allerdings auch, dass alle bestehenden TN-Listen nun leer sind, da wir dieses Einverständnis bislang nicht eingeholt haben.

Optimierung der Teilnehmerliste

Im Zuge des Opt-Ins für die Teilnehmenden haben wir auch die Teilnehmerliste etwas optimiert. So gibt es jetzt nur noch eine TN-Liste für das gesamte Barcamp und nicht separat für jede Veranstaltung.

Weiterhin haben wir die Profilbilder dort entfernt, da diese eh kaum genutzt wurden. Stattdessen wird nun der Name und die Organisation angezeigt, was ggf. sowieso hilfreicher ist.

Zudem gibt es nun auch eine Teilnehmerliste für Barcamps im Ticket-Modus.

Änderungen bei den Sessions

Im Bereich der Sessions wurden ein paar kleinere Veränderungen durchgeführt:

  • Die Sessionvorschläge können nun auch nach Titel sortiert werden.
  • Sessionvorschläge werden nicht mehr per Markdown formatiert. Dies wurde einerseits nur selten genutzt und andererseits gab es damit Probleme, den Gender-*-Stern zu nutzen.
  • Im Sessioneditor gibt es bei Zeitslots jetzt auch noch :15 und :45 als Vorgabe. Ihr könnt aber generell jede Zahl dort reinschreiben.

Ihr wollt loslegen mit den Barcamptools? Zur aktuellen Version geht es hier entlang.

Antragsgrün 4.1.1: Accounts löschen und weiteres Finetuning

Update | https://pixabay.com/de/service/license/

In der gestern veröffentlichten Version 4.1.1 von Antragsgrün findet ihr einige Fehlerbehebungen und kleine Verbesserungen:

  • In der Liste der Veranstaltungen erscheint nun die neueste Veranstaltung ganz oben.
  • Ein Klick auf »Änderungen« in der öffentlichen Version eines zusammengeführten Entwurfs öffnet nun immer einen Tooltip mit der Zusammenfassung des Änderungsantrags, einschließlich der Antragstellenden dieses Änderungsantrags.
  • In der tabellarischen Antragsübersicht im Backend werden nun die benutzerdefinierten Statusangaben (Freitextfeld) ebenfalls angezeigt.
  • Bisher war es nicht immer möglich, einmal angelegte Nutzer*innen wieder aus Antragsgrün zu entfernen. Hierfür gibt es nun zwei Wege: Bei der Verwaltung der Liste der zugelassenen Nutzer*innen für eine Veranstaltung, ist es nun möglich diese wieder einzeln zu entfernen. Zudem können Systemadministrator*innen Nutzerkonten nun aus der systemweiten Zugangsliste entfernen.
  • Bugfix: Das Datum des letzten gespeicherten Entwurfs beim Zusammenführen von Anträgen wurde im Safari-Browser nicht korrekt gesetzt.

Wie immer empfehlen wir euch die Neuerungen bequem über den Web-Updater einzuspielen. Das klappt auch diesmal mit wenigen Mausklicks.


Antragsgrün 4.1: Resolutionen, bessere PDFs, Bewerbungen und Verfahrensvorschläge

Vor wenigen Tagen ist Antragsgrün 4.1 erschienen. Die Neuerungen sind diesmal sehr zahlreich, allerdings handelt es sich vor allem um viele kleinteilige Verbesserungen im System.

Neues rund ums Anträge stellen und der Antragsstatus »RESOLUTION«

Im Formular zur Antragseinreichung ist das Beschlussdatum für Organisationen, die einen Antrag stellen, nun optional. Ein zusätzliches optionales Feld, um das Geschlecht von Einzelantragstellenden hinzuzufügen, wurde ergänzt.

Die Differenzialansicht für Änderungsanträge zeigt nun in der Regel die gesamte betroffene Zeile an, anstatt die Zeile nach dem letzten geänderten Wort abzuschneiden. Das erleichtert die Verständlichkeit des Änderungsantrags ein wenig.

Neu eingeführt wurde der Antragsstatus »RESOLUTION« sowie »Resolution(vorläufig)«. So gekennzeichnete Anträge werden auf der Übersichtsseite einer Veranstaltung in einer etwas anderen Ansicht dargestellt (ohne Initator*innen) und haben in der Web- und PDF-Darstellung einen anderen Header als normale Anträge. Eine Resolution beinhaltet weder Änderungen noch Kommentare.

Verbesserte PDFs und Bewerbungen über Antragsgrün

Ein Anwendungsfall von Antragsgrün, über den wir bisher nicht ausführlich berichtet haben, ist die Übermittlung von Bewerbungen, z.B. für Wahlmandate in Organisationen. Zur besseren Unterscheidung zu anderen Anträgen, ist für Bewerbungen eine neue PDF-Vorlage in Antragsgrün hinterlegt. Diese Auswahlfunktion steht jedoch nur zur Verfügung,wenn Antragsgrün nicht auf einem Webhosting, sondern auf einem eigenständigen Server installiert ist (LaTeX-basierte PDF-Erstellung).

Wenn ein hochgeladenes Bild sehr groß ist (größer als 1000×2000 Pixel),wird es verkleinert, um die Speichergröße des PDFs nicht zu sehr anwachsen zu lassen.

Für jeden Abschnitt eines Antragstyps ist es nun möglich, festzulegen, ob der Titel explizit im PDF gedruckt wird oder nicht.

Wenn man verschiedene Antragstypen definiert, kann man nun festlegen, dass bestimmte dieser Typen einen standardisierten Anfang im Titel haben,wie z.B. „Bewerbung: “.

Beim Erstellen eines Antrags zeigt die Bestätigungsseite nun eine Vorschau des erzeugten PDFs an.

Verfahrensvorschläge

Verfahrensvorschläge existieren schon eine Weile in Antragsgrün. Jedoch handelt es sich dabei um eine Funktion, die sehr auf professionelle Konferenz-Settings ausgelegt ist. Da diese Funktionalität oftmals gar nicht benötigt wird, sind Verfahrensvorschläge nun pro Antragstyp optional. Sie sind zudem standardmäßig deaktiviert.

Beim ODS-Export der Liste von Verfahrensvorschlägen besteht nun die Auswahlmöglichkeit, auch die Kommentare einzubinden oder nur öffentlich sichtbare Verfahrensvorschläge einzubeziehen.

Informationsmails über die Verfahrensvorschläge können nun vom/von der Absender*in angepasst werden.

Wenn ein Änderungsantrag durch einen anderen Änderungsantrag obsolet wird, wird diese Änderung auch im Zusammenhang mit dem vorgeschlagenen (obsoleten) Änderungsantrag ausgewiesen.

Administrator*innen können einen Vorschlag als vom/von der Benutzer*in akzeptiert kennzeichnen – das wird protokolliert.

Zudem wurden Fehler behoben, u.a. war es bislang nicht möglich, Admin-Kommentare zur vorgeschlagenen Vorgehensweise zu löschen.

Bessere Nachvollziehbarkeit beim Einarbeiten von Änderungsanträgen

Im Modus »Änderungsanträge einpflegen« (Visualisierungsansicht) zeigt Antragsgrün alle Änderungsanträge direkt in den Antragstext eingebettet an. Diese Ansicht kann nun als PDF exportiert werden, um den Zusammenführungsprozess zu dokumentieren.

Nach der Erstellung des endgültigen Texts kann nun ausgewählt werden, ob die neue Version dieses Antrags als regulärer Antrag oder als(vorläufige) Resolution dargestellt wird (Infos zum neuen Status »Resolution« siehe oben).

Außerdem wurde ein kleiner Fehler behoben, der das Einarbeiten von Änderungsanträgen mit bestimmtem Status verhindert hatte.

Weitere Änderungen und Fehlerbehebungen

Antragsgrün erlaubt schon lange, die Nutzeroberfläche und Meldungen über das Backend anzupassen. Dies ist z.B. für organisationsspezifische Ausdrücke und Formulierungen besonders nützlich. Neu ist nun, dass die übersetzbaren Zeichenketten intern mit einem Kommentar oder einer Beschreibung versehen werden können, um die Anpassung/Handhabung für Kolleg*innen zu erleichtern.

Beider Nutzerregistrierung gibt es nun die Option, eine E-Mail-Bestätigung für die neuen Nutzer*innen anzufordern.

Die Geschwindigkeit der tabellarischen Antragsübersicht im Backend wurde insbesondere für große Einsätze mit über vielen Änderungsanträgen verbessert, indem die Anzahl der einzelnen Datenbankabfragen reduziert werden konnte.

Die Admin-Oberfläche zum Hinzufügen/Entfernen von Unterstützer*innen eines Antrags hat nun die Funktion, die vollständige Liste der Unterstützer*innen in einem Format in die Zwischenablage zu kopieren, das geeignet ist, sie später in das Volltextfeldeinzufügen (um die Unterstützer*innen-Liste einfach von einem Antrag in einen neuen zu übertragen).

Und schließlich wurden Fehler der Vorgängerversion behoben. Dazu gehören z.B.:

  • Zu lange Antragstitel konnten zu fehlerhafter Seitengenerierung führen.
  • Unter bestimmten Umständen schien ein einem Tagesordnungspunkt zugeordneter Antrag auf der Übersichtsseite der Veranstaltung nicht korrekt zugeordnet zu sein.
  • Wenn ein Antragstyp von Grund auf neu erstellt und dabei rechts positionierte Antragsabschnitte hinzugefügt wurden, wechselte das Layout nicht in den zweispaltigen Modus.
  • Der LaTeX-basierte PDF-Export funktionierte nicht, wenn ein eigentlich optionales Bild nicht hochgeladen war.

Updaten? Am besten bald!

Wir empfehlen euch bald auf die neue Antragsgrün-Version zu aktualisieren. Das klappt bequem per Web-Updater. In diesem Zusammenhang möchten wir euch darauf hinweisen, dass Antragsgrün mittlerweile auf die PHP-Version 7.2 optimiert ist. Falls euer Server diese Version bereits unterstützt (bei vielen Providern kann man das im Administrationspanel per Mausklick einstellen), empfehlen wir euch aufgrund von Geschwindigkeits- und Sicherheitsvorteilen diese Aktualisierung ebenfalls.

Wer Antragsgrün neu installieren möchte, erhält die jeweils aktuellste Version über die Entwicklungsseite von Antragsgrün auf Github: https://github.com/CatoTH/antragsgruen/releases/latest