Qualitätssicherung bzgl. Base
Bugreports
Übersicht von Bugreports zu Base in Bugzilla - sortiert nach dem Status
Erklärungen der verschiedenen "Status"-Arten s. Status
- Status "ASSIGNED"
- Status "NEEDINFO"
- Status "NEW"
- Status "PLEASETEST"
- Status "REOPENED"
- Status "UNCONFIRMED"
- Status "VERIFIED"
Übersicht von Bugreports zu Base in Bugzilla - sortiert nach "Wie wurde der Bug abgearbeitet" ("Resolution")
- FIXED: der Bug wurde behoben/gefixt.
- INVALID: The problem described is not a bug.
- WONTFIX: The problem described is a bug which will never be fixed.
- DUPLICATE: The problem is a duplicate of an existing bug. When a bug is marked as a DUPLICATE, you will see which bug it is a duplicate of, next to the resolution.
- WORKSFORME:
- WORKSFORME bedeutet:
- Alle Versuche, diesen Fehler zu reproduzieren, waren vergeblich.
- Das Durchsehen des Codes ergab keine Anhaltspunkte dafür, warum das beschriebene Verhalten auftreten würde.
- Wenn es später wieder Hinweise geben sollte, dass doch ein Bug vorliegt, kann der Bugreport wieder geöffnet werden.
- WORKSFORME bedeutet:
Bugs im Modul Report-Builder
Der Report-Builder ist mit ca. 30 Bug-Meldungen in Bugzilla verzeichnet:
Noch unerledigt
<rss max="40">https://bugs.documentfoundation.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PLEASETEST&component=Database&product=LibreOffice&query_format=advanced&resolution=---&short_desc=Report%20Builder&short_desc_type=allwordssubstr&title=Bug%20List&ctype=atom</rss> Liste in Bugzilla öffnen
Gefixt
<rss max="40">https://bugs.documentfoundation.org/buglist.cgi?component=Database&product=LibreOffice&query_format=advanced&resolution=FIXED&resolution=DUPLICATE&short_desc=Report%20Builder&short_desc_type=allwordssubstr&title=Bug%20List&ctype=atom</rss> Liste in Bugzilla öffnen
Datenbank mit Bugs
Einige Bugs lassen sich für Ungeübte nur schwerlich nachvollziehen. Ich (Robert) habe daher eine Datenbank mit kleinem Datenbestand und den verschiedensten Berichten erstellt, wobei bei den Berichten immer vermerkt ist, auf welchen Bug sie sich beziehen.
Einige Berichte zeigen auch nur, wie es eigentlich richtig sein müsste. Oder es werden Funktionen vorgestellt, die nach der GUI irgendwas bewirken sollen, bei denen aber unklar ist, was sie überhaupt bewirken.
Link zu der Datenbank: http://robert.familiegrosskopf.de/download/ReportBuilder_all_bugs.odb
Die Datenbank ist komplett in Englisch verfasst. Für einige Bugs muss auch in der GUI die englische Sprache (USA) eingestellt sein, damit die Bugs auffallen.
Verbesserungsvorschläge
Farbliche Darstellung in Tabellenkontrollfeldern in Formularen
In Bugzilla eingestellte Verbesserungsvorschläge:
tdf#45508
Kommentar von Robert:
Es geht um die Tabellenkontrollfelder in Formularen. Das steckt hinter dem Begriff tablecontrol. Diese Tabellenkontrollfelder lassen für die Spalten eine sehr begrenzte Schriftformatierung zu - z.B. die rote Farbe für negative Währungsbeträge. Ansonsten wird das Schriftformat für das gesamte Tabellenkontrollfeld festgelegt. Auch eine Hintergrundfarbe bezieht sich auf das gesamte Feld.
Bisher ist es also weder möglich, in Spalten unterschiedliche Farben oder Schriften zu verwenden (z.B. Spalten, die nur zum Lesen gedacht sind in anderer Farbgebung), noch ist es möglich, in Zeilen unterschiedliche Farben und Schriften zu verwenden.
Die bedingte Formatierung würden die findigen Leute daraus per Makro erstellen. Das ist nicht das Problem. Die Eigenschaft selbst existiert zur Zeit nicht, so dass so etwas auch nicht per Makro angesprochen werden kann.
Die Einstellungen gehen nur an einer Stelle, nämlich bei den Eigenschaften des Tabellenkontrollfeldes. Dort gibt es bisher keine solche Einstellmöglichkeit, und sie existiert, soviel ich weiß, auch nicht in den Beschreibungen zu diesem Feld.
Manchmal bieten ja Formularfelder mehr als die GUI bereitstellt. Das kann man dann per Makro rausholen. So habe ich beständig per Makro Felder auf unsichtbar geschaltet - die Einstellung ist in der GUI aber unter LO mittlerweile möglich. Sie existierte vorher schon lange, konnte aber eben nur per Makro angesprochen werden. In diesem Fall dürfte das nicht so einfach sein, weil eben die Eigenschaft selbst nicht existiert.
Einmal banal gesagt: es geht so ungefähr um das, was phpMyAdmin kann seit ich es kenne: Zeilen dadurch voneinander abgrenzen, dass sie wechselseitig in unterschiedlichen Farbgebungen erscheinen. Zusätzlich Zeilen eine andere Farbe zuweisen können - geschieht bei phpMyAdmin über einen Mausklick, könnte hier z.B. in Abhängigkeit vom Datensatzmarkierer geschehen.
Irgendeine Konkurrenz interessiert mich hier erst einmal nicht, wenn ich merke, dass ich bestimmte Eigenschaften gut gebrauchen könnte. Aber wenn es eine einfach Konkurrenz unter Linux sein soll: http://kexi-project.org/screenshots.html. Dort sind genau diese Bilder zu sehen: Zeilen abwechselnd farbig, aktuelle ausgewählte Zeile mit zusätzlicher Farbgebung.
Kommentar von Rainer:
Die derzeitige Anfrage hat nur wenig Erfolgsaussicht, weil der Wunsch zu vage und eingeschränkt ist. M.E geht es um etwas ähnliches wie die "Bedingte Formatierung" in CALC, wenn dem so ist, sollte die Anfrage auch so heißen.br>Außerdem sollten schon mal ein paar rudimentäre Gedanken zur Verwirklichung vorgestellt werden. In welchen Menüs sollte wie welche Einstellmöglichkeit gewählt werden, greift man auf das Vorlagenkonzept zurück, wird eine Format-Kopierfunktion benötigt, braucht man das auch Zellenweise? Gibt es schon Ansätze, die man ggf. einfach übertragen oder erweitern könnte? Was kann die Konkurrenz?
Wenngleich alles, was an die alten OOo-Specs. erinnert, bei vielen Entwicklern anscheinend Krätze hervorruft, halte ich es schon für sinnvoll, den Gedanken zu Ende zu entwickeln, wie es beispielsweise André Schnabel hier <User:Andreschnabel/Spec Calc grid lines on colored background> mal gemacht hat.
Kommentar von Christian:
Formatierungsmöglichkeiten für die Tabellenansichten gibt es, aber nur für die Tabelle im Ganzen, nicht aber für bestimmte Zeilen oder gar Zellen.
Antwort auf "Die derzeitige Anfrage hat nur wenig Erfolgsaussicht": Nun ja, mir persönlich würde es schon ausreichen, wenn man per Makro die Eigenschaften ändern kann, also die Grundlagen für bedingte Formatierung geschaffen werden und habe deswegen bewusst nicht "conditional formatting" geschrieben.
Ich denke bedingte Formatierung (gibt es auch im Report Builder) auf allen Formularelementen, die Daten anzeigen, wäre dann der logische nächste Schritt.
Trotzdem gebe ich dir vollkommen Recht, hier muss genauer definiert werden.
Programmierer:
Rainer: Ich habe von Datenbanken praktisch keine Ahnung, kann deshalb wenig beitragen (Stand: 18.03.2012)
Sicherheit der Dateneingabe für Fremdbenutzer erhöhen
Robert:
In Base-Foren kommt immer wieder die Frage, wie Datenbanken denn vor (unbeabsichtigten) Änderungen geschützt werden können. In der momentanen Auslegung von Base ist dies nahezu gar nicht möglich; bewusste Änderungen auszuschließen geht von vornherein nicht, da Base an keiner Stelle einen Passwortschutz hat, wie dieser z.B. für einzelne Calc-Tabellen möglich ist. Base ist in der momentanen Fassung eigentlich nur als private Einzelplatzversion gedacht - Schutzmechanismen werden vollständig der dahinterliegenden Datenbank überlassen.
Die folgenden Punkte sollten möglich sein:
- Tabellen sollten so eingestellt werden können, dass sie nicht im Bearbeitungsmodus starten. Hierfür ist Menüpunkt im TableDesign vorzusehen.
- Tabellen sollten vor Änderungen der Felder über die GUI geschützt werden können. Dies ginge über einen Passwortschutz der einzelnen Tabellen.
- Tabellen sollten unsichtbar geschaltet werden können und dennoch für die Eingabe von Daten über Formulare und Abfragen zur Verfügung stehen. Zur Zeit schließt die fehlende Sichtbarkeit von Tabellen (Datenbank → Extras → Tabellenfilter) eine weitere Verfügbarkeit der Tabellen in anderen Modulen aus.
- Abfragen, Formulare und Berichte sollten mit Passworten vor Veränderungen gesichert werden können.
- Die Sichtbarkeit einzelner Container (für Tabellen, Abfragen, Berichte) sollte ausschaltbar sein, so dass nur eine Ansicht der Formulare schaltbar ist.
Weitergehende Forderungen waren z.B. das Unterbinden der Möglichkeit, neue Datenbanken zu gründen (vermutlich, um Daten von einer Datenbank zur anderen zu kopieren ...). Wie so etwas überhaupt möglich sein sollte, entzieht sich meiner Phantasie.
Konzept für Abarbeitung von Bugs, die Base betreffen (Entwurfsstadium)
Allgemeines
- Protokollierung des Konzeptes:
- Diskussion von Ideen:
- Zunächst "Andiskutieren" auf der deutschsprachigen discuss-ML
- Diskussionsergebnis auf der internationalen discuss-ML posten
- Feststellung von Bugs und Erstellung von Bugreports* Abarbeitung von Bugreports* Direkte Kommunikation mit Programmierern
- Internationale Dokumentation-ML:
- <documentation@global.libreoffice.org>
- Internationale Dokumentation-ML bei Bederf einschalten, d.h. Beitrag posten.
- Kommunikationsweg:
- Einigung nötig, auf welchem Kommunikationsweg kommuniziert werdeb soll: deutsche discuss-ML, internationale QA-ML und per PM.
- Kommunikation mit Programmierern:
- Klären, ob Robert bereit ist, in direkter Kommunikation mit Programmierern zu treten - quasi als der "Power-Base-User" mit sehr umfangreichen Kenntnissen bzgl. Base?
- LO-Hilfe:
- LO-Hilfe bzgl. "Report Builder" ergänzen
- Ansprechpartner: David Nelson und András Timar
- Teammitglieder:
- Jochen Sch.: Initiator und Koordinator; Base-User (Windows)
- Klaus-Jürgen W.: Zuhörer, Mitleser, Hinlanger und Abgeber von Zwischenkommentaren
- Robert G.: Power-User (Linux); "Base-Spezialist".
- Jochen Sch.: Initiator und Koordinator; Base-User (Windows)
Spezielle Themen
Report Builder
Dokumente bzgl. geplanter Funktionen:
- <https://wiki.openoffice.org/wiki/SUN_Report_Builder>
- <https://wiki.openoffice.org/wiki/SUN_Report_Builder/Documentation>
- <https://www.openoffice.org/dba/specifications/index.html>
- Kommentar 1 von Robert G: Da waren wohl wirklich mehr Möglichkeiten geplant, als letztlich durchgeführt worden sind. Natürlich gibt es auch noch Erweiterungen(z.B. Grafiken ...) aber auch versuchte Erweiterungen, die so gar nicht vorgesehen waren und auch momentan keine Funktion haben (Rücksetzung der Seitenzahl beim Beginn einer neuen Gruppe). Wie kann ich jetzt am geschicktesten damit verfahren? Ist das jetzt eine Dokumentationsfrage - müssen auch die nicht funktionierenden Elemente weiter dokumentiert werden - oder ist das eine Entwicklungsfrage - haben die fehlenden Elemente tatsächlich einmal existiert, sind im Code hinterlegt - nur es fehlt die Verbindung zu einer Einstellmöglichkeit. Für mich war die Lektüre dieser Spezifikationen nach anfänglicher Euphorie (beinahe 50 Seiten zum Report-Builder) doch eher recht ernüchternd. Da ist das Handbuch Base mit seinem Kapitel mit brauchbaren Informationen versorgt.
- Kommentar 2 von Robert G.: Status dieses Dokumentes ist "draft". Ich mit meinen mangelhaften Englischkenntnissen musste erst einmal nachsehen: Ist also ein Entwurf. Da stehen dann auch so schöne Vorstellungen wie "Sub report" drin, die sogar mit einem Button direkt auf der Oberfläche vertreten sind. Ich habe mir bei einigen Funktionen schon gedacht, dass so etwas eigentlich nur mit einem Sub-Report gehen kann. Es gibt also tolle Gedanken, was das Ding leisten soll. Es leistet auch bereits sehr viel, könnte aber noch verbessert werden. Leider ist irgendwann einiges auf der Strecke geblieben, so dass die Benutzeroberfläche Ungereimtheiten wie unbelegte Funktionen aufweist, die Ocke Janssen damals geplant hatte.
Notizen von Robert G.: http://robert.familiegrosskopf.de/download/ReportDesigner_withComments.odt
Base-Programmierer
Bitte die Base-Programierer nicht direkt anmailen. Die Korrespondenz erfolgt über Bugzilla bzw. in Bugzilla werden die Base-Programmierer ins CC gesetzt.
Auflistung der Base-Programmierer:
- Axel
- Lionel
- Thorsten