Strichliste: Bug Reports und Feature Requests

Hier sammeln wir bekannte Fehler und Verbesserungsvorschläge, die uns das Leben mit Strichliste in Zukunft leichter machen.

Bitte auch die GitHub Issue Tracker zu Strichliste und Strichliste-Web beachten!

Aktuell stehen die seltener genutzten Knöpfe zum Aufladen an prominentester Stelle in der GUI, während erst darunter die Knöpfe zum Bezahlen angeordnet sind. Da beide ähnliche Beschriftungen aufweisen, sind sie auch noch leicht zu verwechseln, erst recht für Personen mit Rot/Grün-Schwäche. Daher wird eine Optimierung angestrebt, um versehentliches Betätigen der falschen Knöpfe zu verhindern.

Vorübergehend wurden die Knöpfe mit vordefinierten Summen zum Aufladen ausgeblendet.

Nach einer Idee von mehreren Personen, aufgenommen von Breti.

Die Liste der Transaktionen sollte eine Saldo-Spalte anzeigen, damit man besser nachvollziehen kann, zu welchem Kontostand eine Transaktion geführt hat.

Nach einer Idee von OlRi, aufgenommen von Breti.

Nachts sollte an alle Benutzer mit Buchungen des Vortags eine Mail versandt werden, die die Buchungen und den aktuellen Kontostand zeigt. Hierdurch können Fehlbuchungen aller Art schnell identifiziert werden.

Erfordert die Erfassung von E-Mail-Adressen zu den Nutzern und somit die Anpassung der Maske zum Erstellen von Benutzern sowie eine neue Maske zum Ändern der E-Mail-Adresse.

Aufgenommen von Breti, nach einer Idee des Mainframe (Hackspace OL).

Notizen:

• User-Entität muss um email(optional) erweitert werden
• User-Create API muss um email erweitert werden
• Automatischen Job (Zeitpunkt des Versendens über settings), evtl mit perl
• UI: Zusätzliches Feld E-Mail
• UI: Ändern des Nutzers (E-Mail ändern)

Benutzeraccounts mit ausgeglichenem Kontostand (0 EUR) sollten gelöscht werden können. Details sind zu klären. Es müssen Vorkehrungen getroffen werden, um Manipulationen zu verhindern bzw. im Nachhinein noch nachvollziehen zu können.

Aufgenommen von Breti.

Notizen:

• Um im Nachhinein nachvollziehen zu können, kann man ein Soft-Delete machen, also ein Flag in der Datenbank setzen (deleted=true oder deleted=„2015-11-21 12:35:44“). Dann sollte es von der API nicht mehr ausgeliefert werden und wird in der Weboberfläche nicht mehr angezeigt
• /delete api (auf server)
• Delete-Button in UI einblenden wenn nicht Mitglied (extra Anforderung) und Betrag auf 0

Wenn die Stammdaten um eine E-Mail-Adresse ergänzt werden (s.o.) oder Accounts gelöscht werden können (s.o.), so muss sichergestellt werden, dass diese Änderungen nicht bei Benutzern möglich sind, die vom LDAP hereinsynchronisiert wurden - bei diesen Benutzern soll das LDAP führendes System bleiben.

Lösungsmöglichkeiten:

• Einführung eines external_user Flags (nur per API setzbar), das jegliche Editierung am Benutzer unterbindet
• Einführung von can_edit und can_delete Flags (nur per API setzbar), die die Editierung am Benutzer im Detail steuerbar machen
• Einführung von Gruppen („local“, „ldap“, …), die einem Benutzer per API zugeordnet werden können (nur eine Gruppe zur Zeit, Standard für lokal über strichliste-web angelegte Benutzer ist „local“), und Konfigurierbarkeit der Möglichkeiten der Benutzer einer Gruppe über eine strichliste-web Konfigurationsdatei

Aufgenommen von Breti.

Benutzerkonten über PINs zu schützen erhöht den Aufwand beträchtlich, insbesondere für die Administration. Es würden Prozesse für das Rücksetzen von PINs erforderlich, und Benutzer würden bei vergessener PIN vermutlich auf eine Zahlung an der Strichliste vorbei zurückgreifen.

Ein Zugriff aus dem Internet ist aufgrund der Architektur der Software (JavaScript im Browser, Zugriff von dort direkt auf HTTPS API) schwer zu realisieren und die Notwendigkeit dafür ist auch nicht erkennbar - sowohl zum Aufladen als auch zum Bezahlen ist schließlich die physikalische Anwesenheit im Hackerspace erforderlich. Lediglich für den Kassenwart oder Vorstand wäre das Einsehen der Statistik ggf. hilfreich.