Aktionen
Design 4 - Fehler Anregungen Wünsche » Historie » Revision 2
« Zurück |
Revision 2/9
(diff)
| Weiter »
Jan Büren, 10.01.2019 18:23
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
Benutzerinterface¶
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
Finanzbuchhaltung → Dialogbuchen
gl.pl?action=add¶
- Bei "Buchung - Spalte Konto": lange Kontobezeichnungen werden abgeschnitten (besser: auf mehrere Zeilen umbrechen!)
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
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
System → CSV-Import → "alle Profile"
controller.pl?profile.type=***&action=CsvImport%2Fnew¶
- "Spaltenzuordnungen" und "Hilfe zu Spaltennamen" können nicht angeklickt bzw. angezeigt werden
Admininterface¶
Allgemeines¶
Datumsauswahl-Popups¶
- Zu grosse Schrift: Von der Jahreszahl werden nur die ersten 3 Ziffern angezeigt
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
Von Jan Büren vor fast 6 Jahren aktualisiert · 2 Revisionen