catoth / antragsgruen Goto Github PK

Analog zu den Änderungsanträgen

Es sollte möglich sein, TOPs zu definieren, Anträge zu bestimmten TOPs zu stellen und als Admin Anträge anderen TOPs zuzuweisen.

.

Wenn ich die index.php in antragsgruen/html aufrufe erhalte ich den Fehler: Fehler 310 (net::ERR_TOO_MANY_REDIRECTS): Zu viele Umleitungen.

Ein Löschen der Cookies, anderer Browser usw. ändern nichts an der Fehlermeldung.

Version ist v2. Master habe ich nicht getestet.

Es sollte möglich sein, einen bestehenden Antrag zu klonen, so dass alle Angaben außer dem Antragstext (AntragstellerInnen, Kontaktdaten, Beschlussdatum, ...) übernommen werden und man direkt auf die Seite gelangt, wo man mit denselben Angaben einen Antragstext bzw. eine Änderung eingeben kann.

Momentan ist es noch nicht möglich, irgendwo Tabellen, Abbildungen oder dergleichen einzufügen. Beim Antragstext selbst wird das wohl auch so bleiben, weil das sonst bei der Berechnung der Änderungen in Änderungsanträgen zu kompliziert wird. Bei der Begründung des Antragstexts fällt diese Einschränkung weg, was sich insofern ganz gut trifft, als sich dort auch häufiger Tabellen etc. vorkommen. Insofern würde sich anbieten, dort auch mehr Textformatierungen zuzulassen.

Aktuell fehlt noch eine "Passwort zurücksetzen"-Funktion.

Funktioniert nicht z.B. bei der LV-Hessen-Variante ("Weiter" führt zu nichts)

Wenn Antragsgrün auch für das Einreichen von Bewerbungen eingesetzt werden soll, müssen auch Bilder als Teil eines "Antrags" bzw. einer Bewerbung möglich sein.

Siehe protected/runtime/application.log

Wenn ich den Init-Datensatz über SQL-Befehle oder Import einfügen will, erhalte ich folgenden Fehler:
#1452 - Cannot add or update a child row: a foreign key constraint fails (protekto_antragsgruen.veranstaltung, CONSTRAINT fk_veranstaltung_veranstaltungsreihe1 FOREIGN KEY (veranstaltungsreihe_id) REFERENCES veranstaltungsreihe (id) ON DELETE NO ACTION O)

Das scheint ein innoDB Problem zu sein... Meine eigenen Kenntnisse sind aber begrenzt, so dass ich da absolut nicht weiterkomme

Die Funktion "Ich lege diesen Antrag für eine andere AntragstellerIn an (Admin-Funktion)" taucht in einigen Konstellationen nicht auf.

Das strikte Modell Titel - Antragstext - Begründung ist oft nicht passend, weder von der Nomenklautur her, noch von der genauen Aufteilung. Es sollen stattdessen nun beliebige Abschnitte festgelegt werden können, auch mehr als die zwei bzw. drei (inkl. Titel).

Beim Eintragen vieler Anträge hintereinander ist es zu umständlich, bei jedem ÄA die Liste der UnterstützerInnen jeweils in jedes Feld einzeln einzutragen. Stattdessen sollte lieber ein großes Textfeld her, in das man das einfach hinein copy/pasten kann.

Wenn ein Gremium einen Antrag einreicht, muss neben dem Namen auch das Beschlussdatum eingetragen werden.

nt.

Die möglichen Antragstypen sollten nicht mehr durch den Programmcode vorgegeben werden (was zu uneleganten Ausweichlösungen geführt hat), sondern pro Veranstaltung durch den Veranstaltungsadmin vorgegeben werden können.

In besagter Datei sind die Links auf die Icons, hier exemplarisch
<link rel="icon" type="image/png" href="/favicon-196x196.png" sizes="196x196">
so gesetzt das er im "Wurzelverzeichnis" sucht. Der Ordnerstruktur entnehme ich aber wenn ich das in ein Unterverzeichnis packe bspw. example.com/antragsgruen dann sucht er die Icons in example.com statt in example.com/antragsgruen/html.
Mein Vorschlag entweder in:
<link rel="icon" type="image/png" href="html/favicon-196x196.png" sizes="196x196"> oder
<link rel="icon" type="image/png" href="favicon-196x196.png" sizes="196x196"> oder ganz neu in
<link rel="icon" type="image/png" href="/img/favicon-196x196.png" sizes="196x196"> ändern und die Bilder entsprechend auslagern.

Der Editor erzeugt [URL=http://...], Decode erwartet allerdings die URL in Anführungszeichen, damit es auch dargestellt wird.

Für Stati wie z.B. Informationen fehlen

Die Felder organisation, telefon und email sollten aus der Tabelle person raus und stattdessen in antrag_unterstuetzerInnen bzw. aenderungsantrag_unterstuetzerInnen gespeichert werden.

Der Impressum Link zeigt auf html/infos/impressum, dort gibts weder eine "default" seite noch exisitiert der Ordner. Wäre gut wenigstens ein Grundgerüst dort zu haben.

Oft wird bei Änderungen mehr umgebener Text dargestellt, als nötig oder sinnvoll.

Es sollte möglich sein, die Anträge nach verschiedenen Kriterien zu filtern. Vor allem nach AntragstellerIn und Titel, sobald es TOPs gibt auch nach TOPs, am besten nach allen Feldern. (Im BGS-Antragstool ist das eine Admin-Funktion; es spricht aus meiner Sicht nichts dagegen, das für alle zur Verfügung zu stellen.)

Einfügungen sollten im PDF am besten nicht nur grün unterstrichen, sondern außerdem noch fett anzeigt werden, um die Textstelle beim s/w-Ausdruck besser kenntlich zu machen.

Einstellungsmöglichkeit: Wenn ein Antrag einmal gestellt ist, darf er nicht mehr verändert werden - auch nicht von den Admins.

Der Betrieb sollte auf Servern ohne E-Mail-Versandmöglichkeit erleichtert werden. Insb. das Anlegen von Accounts / Ändern von Passwörtern.

Ist aktuell verwirrend, "Name" vs. "Gremienname"

Die Normalisierung des Texts dadurch vorzunehmen, dass man ihn in BBCode umwandelt, war wohl insgesamt eine eher schlechte Idee. Sinnvoller wäre eine möglichst strikt normalisiertes Subset von HTML mit nur den allernötigsten Tags und klarer Definition, wann Leerzeichen bzw. -zeilen vorkommen sollen und wo nicht.

Es scheint oft noch Formatierungsprobleme zu geben, wenn Anträge per Copy/Paste ins Antragstool kopiert werden. Hier brauche ich noch ein paar Beispiel-Dokumente, anhand derer ich es testen kann. Zu testen ist insb., ob sich das Problem innerhalb des WYSIWYG-Editors beheben lässt oder nicht; falls nicht, müsste eine separate Eingabemaske her, die den eingefügten HTML-Text zunächst an den Server schickt, wo man den HTML-Text flexibler in die interne Repräsentation umwandeln kann.

Bei Satzungsänderungen u.ä. ist es wünschenswert, daß die Änderung im Änderungsmodus dargestellt wird, mit Durchstreichen etc., obwohl es sich um einen eigenständigen Antrag und nicht um einen Änderungsantrag handelt. Dazu sollte es möglich sein, den bestehenden Satzungstext o.ä. einzugeben und dann den Antrag so zu stellen und darzustellen, wie Änderungsanträge gestellt und dargestellt werden; der Antrag sollte dennoch als eigenständiger Antrag behandelt werden. Es wäre zu überlegen, wie dann hierzu Änderungsanträge gestellt und dargestellt werden sollten.

Wenn die Antragsnummer eine gewisse Länge überschreitet, wird sie in dem Kästchen oben rechts im PDF nicht mehr bzw. nicht mehr vollständig dargestellt.

Beim Versuch einer lokalen Installation (Xampp) kommt es zu folgender Fehlermeldung:

PHP error
Declaration of AntragsgruenController::createUrl() should be compatible with CController::createUrl($route, $params = Array, $ampersand = '&')

C:\xampp\htdocs\testweise\protected\components\AntragsgruenController.php(7)

01 <?php
02 /**
03 * AntragsgruenController is the customized base controller class.
04 * All controller classes for this application should extend from this base class.
05 /
06 class AntragsgruenController extends CController
07 {
08 public $layout='//layouts/column1';
09 public $menu=array();
10 public $breadcrumbs=array();
11 public $multimenu = null;
12 public $menus_html = null;
13 public $breadcrumbs_topname = null;
14 public $text_comments = true;
15 public $shrink_cols = false;
16
17 /* @var null|Veranstaltung */
18 public $veranstaltung = null;
19

Liegt das an einem Konfigurationsfehler meinerseits oder am Package?

Separate Termine für den Antragsschluss und den Änderungsantragsschluss.

• Die "Zeile"-Spalte kann weg, sobald die Zeilennummer im Antragskürzel mit enthalten ist.
• Beim Textfeld sollte die Änderung kompakter dargestellt werden; je nach technischer Möglichkeit entweder mit farblich gekennzeichneten Änderungen oder einfach nur die neue Fassung des Textes.

Im PDF wird, insbesondere am oberen Rand, viel Platz auf dem Blatt nicht genutzt; für die Papierverschickung wäre ein platzsparenderes Format wünschenswert.

Da die häufigen kleineren Änderungen gelegentlich auch unerwünschte Seiteneffekte haben, ist es sinnvoll, im Rahmen der größeren Überarbeitung von Antragsgrün auch soweit möglich Acceptance- und Unit-Tests einzuführen. Als Framework bietet sich Codeception (http://codeception.com/) an, da es das Yii2-Framework unterstützt.

Dort heisst es:

Kontext:
...

Es sollte eine Zuständigkeit für Anträge festlegbar sein (nach der dann auch gefiltert werden kann). Am besten zwei getrennte Felder, einmal allgemeine Zuständigkeit (z.B. in der Antragskommission), einmal, wer grade konkret am Ball ist, also den nächsten Schritt machen müßte, um die Behandlung des Antrags voranzubringen. Sollte aus einer konfigurierbaren Liste aussuchbar sein.

Änderungsanträge sollten zu beliebigen Textstellen gestellt werden können, unabhängig von Absatzgrenzen

Bei Änderungsanträgen sollte es die Möglichkeit geben, neben der unmittelbaren Textänderung auch abstraktere Vorschläge als Teil des Antragstexts anzugeben, z.B. "Tausche Absatz 4 und 7", oder "Ersetze alle Vorkommnisse von X durch Y.".

Statt Anträge nur in PDF und HTML-Exportieren zu können, sollte auch ein OpenOffice-Export im .odt-Format her. Anlog könnte natürlich analog zum Excel-Export auch ein .ods-Export her, das ist aber wohl nicht ganz so dringend.

Die automatisch vergebenen Antragsnummern sollten flexibler konfigurierbar sein; insbesondere sollte es möglich sein, das 'Ä' in der Nummerierung von Änderungsanträgen rauszulassen sowie eine feste Ziffernzahl vorzugeben, die vorne mit Nullen aufgefüllt wird.

"E-Mail-Angabe erzwingen" gibt es bereits als Einstellung als Backend, Telefon aber noch nicht. In manchen Policy-Templates ist das außerdem noch hart kodiert, ohne die Einstellung zu überprüfen.

Es sind noch nicht alle Stati vorhanden, die ein Antrag haben kann. Sobald ich eine Liste bekomme, kann ich das nachtragen.

In den Tabs am rechten Rand, in denen die Antragsnummern stehen, sollten auch die AntragstellerInnen stehen.

Gelegentlich verschiebt sich der Text immer noch etwas, wenn man mit der Maus über einen Änderungsantrag fährt (bei der Antragsansicht). Das soll soweit möglich behoben werden.

Es sollte nicht möglich sein, zwei Anträgen dieselbe Nummer zuzuweisen. (Die Nummer FR-04-002 wurde auf der BDK in Hamburg sowohl einem Antrag als auch einem Änderungsantrag zugewiesen.)

Da Version 2 des Yii-Frameworks nun erschienen ist, sollte das bei der nächsten großen Version dann auch mit eingesetzt werden. Der Umstieg ist leider nicht-trivial und erfordert größere Änderungen.

Irgendeine Möglichkeit finden, wie man Satzungsänderungsanträge sinnvoll abbilden kann.