Design 4 - Fehler Anregungen Wünsche » Historie » Revision 2
Revision 1 (Andreas Rudin, 09.01.2019 01:37) → Revision 2/9 (Jan Büren, 10.01.2019 18:23)
h1. Design 4 - Fehler Anregungen Wünsche
Bitte tragt hier alles ein, was euch in Bezug auf das neue Design wichtig ist und was nach Möglichkeit vor dem Release 4.0 noch verändert werden sollte bzw. welche Fehler noch behoben werden müssen.
*Gliederung gemäss Menü im kivitendo von links nach rechts*, zunächst Benutzerinterface, dann Admininterface und zuletzt Allgemeines, das nicht zu einen bestimmten Menüpunkt gehört oder an mehreren Orten auftritt.
Bitte nach Möglichkeit auch die im Browser angezeigte URL eintragen
h2. Benutzerinterface
h3. Stammdaten → Berichte → Artikel
ic.pl?searchitems=article&action=search
* Unter "In Bericht aufnehmen" sind bei "Benutzerdefinierte Variablen" die Texte zu den Buttons nicht auf der gleichen Höhe
h3. Finanzbuchhaltung → Dialogbuchen
gl.pl?action=add
* Bei "Buchung - Spalte Konto": lange Kontobezeichnungen werden abgeschnitten (besser: auf mehrere Zeilen umbrechen!)
h3. Berichte → Kontenübersicht → Konto anklicken → Buchungsliste
ca.pl?action=list&accno=****
* Reihenfolge der Monate ist durcheinander: Januar, Mai, September, Februar, Juni, Oktober ....
* 2 Spalten wären schön, z.B.:
|Periods Vorgewählte Zeiträume|Freier Zeitraum|
||Verschiedenes|
* Button "Buchungsliste" nach oben
* Bei der Jahreszahl wäre Ausklappmenü praktisch
h3. Berichte → Bilanz
rp.pl?report=balance_sheet&action=report
* Buttons bei "SB-Buchungen", "nur EB-Buchungen" sowie "In Bericht aufnehmen" und Schrift daneben nicht auf gleicher Höhe
h3. System → CSV-Import → "alle Profile"
controller.pl?profile.type=***&action=CsvImport%2Fnew
* "Spaltenzuordnungen" und "Hilfe zu Spaltennamen" können nicht angeklickt bzw. angezeigt werden
h2. Admininterface
h2. Allgemeines
h3. Datumsauswahl-Popups
* Zu grosse Schrift: Von der Jahreszahl werden nur die ersten 3 Ziffern angezeigt
h2. Entwicklung/Commits
* Alle Testfälle müssen (wie vorher auch) sauber durchlaufen, evtl müssen hierfür auch Testfälle angepasst werden
* API-Änderungen müssen auch im POD dokumentiert werden. Der POD ist die Straßenkarte des Entwicklers, falls jmd. die Straße ändert, muss die Karte auch stimmig sein
* Symbolische Links wieder herstellen (dispatcher.*)
* Klarer die Commits im js/ Bereich erläutern, dass fühlt sich im ersten Review nicht sauber an
* (optional) die Commits/ den Rebase nochmal im Team neugestalten, sodass logische Zusammenhänge vorranig sind und nicht einfach nur die Verzeichnisstruktur durchlaufen wird. Commit-Message sollten auch klar formuliert sein, sodass man möglichst die Intention des Committers (ohne Code anzuschauen) erkennen kann