Trac-Ticket-Abfragen
Table of Contents
Zusätzlich zu Berichten bietet Trac benutzerdefinierte Ticketabfragen an, die zum Auflisten von Tickets entspechend angegebener Kriterien verwendet werden.
Um eine benutzerdefinierte Abfrage vorzubreiten und auszuführen, wechseln Sie in der Navigationsleiste zu Tickets anzeigen und wählen den Verweis Individuelle Abfrage.
Filter
Wenn Sie die Abfrageseite das erste Mal besuchen, wird Ihnen der Standard-Filter Sie betreffende Tickets anzeigen:
- Falls Sie angemeldet sind, dann werden alle offenen Tickets, die angezeigt werden, Ihnen zugewiesene Tickets öffnen.
- Falls Sie nicht angemeldet sind, jedoch einen Namen oder eine E-Mail-Adresse in den Benutzer-Einstellungen angegeben haben, dann werden Ihnen alle offenen Tickets angezeigt, deren Kopie-Liste Ihre E-Mail-Adresse (oder, bei fehlender E-Mail-Adresse, Ihren Namen) enthält.
- Ohne Anmeldung und ohne Angaben zu Name und E-Mail-Adresse in den Benutzer-Einstellungen werden alle offenen Vorgänge angezeigt.
Vorhandene Filter können durch Anklicken der Minus-Schaltfläche links daneben entfernt werden. Aus den Auswahllisten am Ende des Filterkastens ('UND'-Bedingungen links, 'ODER'-Bedingungen rechts) lassen sich neue Filter hinzufügen. Filter mit Eingabefeld oder Auswahlliste der Optionen können mehrfach hinzugefügt werden, um diese Kriterien mit oder zu verknüpfen.
Sie können die Felder direkt unterhalb des Filterkastens nutzen, um die Ergebnisse nach einem Feld zu gruppieren oder die vollständige Beschreibung zu jedem Ticket anzuzeigen.
Nachdem Sie Ihre Filter bearbeitet haben, klicken Sie die Schaltfläche Aktualisieren zum Anpassen Ihrer Ergebnisse.
Tickets durchgehen
Ein Klick auf eines der Abfrageergebnisse bringt Sie zu diesem Ticket. Sie können sich durch die Ergebnisse bewegen, indem Sie die Verweise nächstes Ticket oder vorheriges Ticket direkt unterhalb der Hauptnavigationsleiste anklicken, oder Sie wählen den Verweis Zurück zur Abfrage um zur Abfrageseite zurückzukehren.
Sie können ruhig jedes der Tickets bearbeiten und nach dem Abspeichern Ihrer Änderungen den Durchgang durch die Ergebnisse mit den Verweisen !nächstes/vorheriges/Zurück zur Abfrage fortsetzen. Wenn Sie zur Abfrage zurückkehren, werden alle bearbeiteten Tickets mit kursivem Text dargestellt. Falls eines der Tickets so verändert wurde, dass es den Abfragekriterien nicht mehr entspricht , dann wird der Text grau. Schließlich wird ein neues Ticket, das den Abfragekriterien entspricht, fett dargestellt.
Durch nochmaliges Anklicken der Schaltfläche Aktualisieren können die Abfrageergebnisse wiederum angepaßt und diese Statuskennzeichen gelöscht werden.
Abfragen speichern
Trac bietet Ihnen an, die Abfrage als benannte Abfrage abzuspeichern, die vom Bericht-Modul aus erreichbar ist. Um eine Abfrage zu speichern, stellen Sie sicher, dass die Ansicht Aktualisiert haben, und klicken Sie dann die Schaltfläche Abfrage speichern, die unterhalb der Ergebnisse angezeigt wird. Sie können Verweise auf Abfragen auch wie nachfolgend beschrieben in Wiki-Text ablegen.
Anmerkung: Eine Art, Abfragen wie die folgenden einfach aufzubauen, ist die, Abfragen im Modul für benutzerdefinierte Berichte zu erstellen, zu testen und nach Fertigstellung Abfrage speichern zu klicken. Dies baut den Abfrageausdruck für Sie auf. Sie müssen nur noch überflüssige Zeilenumbrüche entfernen.
Mit Trac-Verweisen
Sie möchten vielleicht einige Abfragen speichern, um später mit ihnen weiter arbeiten zu können. Dies können Sie tun, indem Sie von einer Wikiseite aus einen Verweis auf die Abfrage anlegen.
[query:status=new|assigned|reopened&version=1.0 Offene Tickets für 1.0]
was folgendermaßen dargestellt wird:
Hier wird eine sehr einfache Abfrage-Sprache verwendet, um die Kriterien zu festzulegen (siehe Abfragesprache).
Alternativ dazu können Sie den Abfrageausdruck einer Abfrage kopieren und diesen einschließlich des vorangestellten Fragezeichens ? in den Verweis im Wiki einfügen:
[query:?status=new&status=assigned&status=reopened&group=owner Zugewiesene Tickets, gruppiert nach Verantwortlichen]
was folgendermaßen dargestellt wird:
Mit dem [[TicketQuery]]-Makro
Das TicketQuery-Makro erlaubt Ihnen die Darstellung von Tickets, die bestimmte Kriterien erfüllen, über all dort, wo die Verwendung von Wiki-Formatierung möglich ist.
Beispiel:
[[TicketQuery(version=0.6|0.7&resolution=duplicate)]]
Dies wird folgendermaßen dargestellt:
- #181
- Wiki preview injects new lines
- #204
- request for colour legend (or something similar) for ticket groups in reports
- #226
- Ticket Dependencies
- #239
- Link to diff of specifik wiki change instead of the page itself
- #351
- All ticket modifications should be tracked in timeline
- #413
- Installing on Windows, drive other than C:
- #450
- Diffviewer should try to convert the text into utf-8.
- #475
- merging of similar tickets
- #519
- Python process sometimes hangs on Windows Server 2003
- #529
- IE 5-6 over HTTPS broken downloads
Ebenso wie die query: Verweise im Wiki, so wird auch bei diesem Makro ein Abfrageausdruck erwartet, der entsprechend der Regeln der einfachen Ticket-Abfragesprache gestaltet ist.
Eine verdichtete Darstellung ohne Ticket-Beschreibungen ist ebenfalls verfügbar:
[[TicketQuery(version=0.6|0.7&resolution=duplicate, compact)]]
Dies wird folgendermaßen dargestellt:
Falls Sie schließlich nur die Anzahl der Fehler, welche die Abfrage erfüllen, erhalten möchten, nutzen Sie den Parameter count.
[[TicketQuery(version=0.6|0.7&resolution=duplicate, count)]]
Dies wird folgendermaßen dargestellt:
10
Anpassung der Darstellung als Tabelle
Sie können die Spalten in der Tabellen-Darstellung (format=table) mithilfe von col≤Feld>-Ausdrücken auch anpassen; mehrere Felder und ihre Darstellungsreihenfolge können Sie durch senkrechte Trennstriche (|) zwischen den Spalten bestimmen:
[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter)]]
Dies wird folgendermaßen dargestellt:
Results (1 - 3 of 8904)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #10702 | invalid | I can't send any form. | mparchet@… | |
| #10701 | cantfix | UnicodeEncodeError: 'ascii' codec can't encode characters in position 2-4: ordinal not in range(128) | admin | |
| #10700 | cantfix | UnicodeDecodeError after upgrade | anonymous |
Tabellenbreit durchgängige Zeilen
Im Format table können Sie auch tabellenbreit durchgängige Zeilen mit rows≤Feld> wie folgend einrichten:
[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter,rows=description)]]
Dies wird folgendermaßen dargestellt:
Results (1 - 3 of 8904)
| Ticket | Resolution | Summary | Owner | Reporter | |||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| #10702 | invalid | I can't send any form. | mparchet@… | ||||||||||||||||||||||||||||||||||||||||
| Description |
Hello, For some time I can't send any forms with firefox 12.0 for mac os x lion because the form's send button has no effect. Here is an example. https://support.microsoft.com/contactus/emailcontact.aspx?scid=sw;fr;1517&ws=SalesandLicensing Can you fix this bug quickly. Best regards Battant |
||||||||||||||||||||||||||||||||||||||||||
| #10701 | cantfix | UnicodeEncodeError: 'ascii' codec can't encode characters in position 2-4: ordinal not in range(128) | admin | ||||||||||||||||||||||||||||||||||||||||
| Description |
How to ReproduceWhile doing a GET operation on /report/10, Trac issued an internal error. (please provide additional details here) Request parameters: {'ACCEPTED': u'accepted',
'ASSIGNED': u'assigned',
'BILLABLE': u'1',
'CLOSED': u'closed',
'ENDDATE': u'2000000000000000',
'NEW': u'new',
'REOPENED': u'reopened',
'STARTDATE': u'0',
'UNBILLABLE': u'1',
'id': u'10'}
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5 System Information
Enabled Plugins
Python TracebackTraceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/Trac-0.12.3-py2.7.egg/trac/web/main.py", line 522, in _dispatch_request
dispatcher.dispatch(req)
File "/usr/local/lib/python2.7/dist-packages/Trac-0.12.3-py2.7.egg/trac/web/main.py", line 243, in dispatch
resp = chosen_handler.process_request(req)
File "/usr/local/lib/python2.7/dist-packages/Trac-0.12.3-py2.7.egg/trac/ticket/report.py", line 118, in process_request
template, data, content_type = self._render_view(req, id)
File "/usr/local/lib/python2.7/dist-packages/Trac-0.12.3-py2.7.egg/trac/ticket/report.py", line 532, in _render_view
if resource.realm.upper()+'_VIEW' not in req.perm(resource):
File "/usr/local/lib/python2.7/dist-packages/Trac-0.12.3-py2.7.egg/trac/perm.py", line 553, in has_permission
return self._has_permission(action, resource)
File "/usr/local/lib/python2.7/dist-packages/Trac-0.12.3-py2.7.egg/trac/perm.py", line 567, in _has_permission
check_permission(action, perm.username, resource, perm)
File "/usr/local/lib/python2.7/dist-packages/Trac-0.12.3-py2.7.egg/trac/perm.py", line 454, in check_permission
perm)
File "/usr/local/lib/python2.7/dist-packages/timingandestimationplugin-1.2.7b-py2.7.egg/timingandestimationplugin/ticket_policy.py", line 23, in check_permission
rtn = self.check_ticket_access(perm, resource, username)
File "/usr/local/lib/python2.7/dist-packages/timingandestimationplugin-1.2.7b-py2.7.egg/timingandestimationplugin/ticket_policy.py", line 61, in check_ticket_access
self.log.warning("Internal: TandE ticket_policy failed to find a ticket for %s : error: %s" % (res, e))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 2-4: ordinal not in range(128)
|
||||||||||||||||||||||||||||||||||||||||||
| #10700 | cantfix | UnicodeDecodeError after upgrade | anonymous | ||||||||||||||||||||||||||||||||||||||||
| Description |
Hello, I just upgraded trac to trac-0.12.3-3.el6.noarch, the newest package from epel repository for centos. After upgrade I saw this error: Trac detected an internal error: UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position 69: invalid continuation byte Python Traceback Most recent call last: File "/usr/lib/python2.6/site-packages/trac/web/main.py", line 525, in _dispatch_request dispatcher.dispatch(req) File "/usr/lib/python2.6/site-packages/trac/web/main.py", line 246, in dispatch resp = chosen_handler.process_request(req) File "/usr/lib/python2.6/site-packages/trac/wiki/web_ui.py", line 117, in process_request page = WikiPage(self.env, pagename) File "/usr/lib/python2.6/site-packages/trac/wiki/model.py", line 44, in __init__ self._fetch(name, version, db) File "/usr/lib/python2.6/site-packages/trac/wiki/model.py", line 67, in _fetch row = cursor.fetchone() File "/usr/lib/python2.6/site-packages/trac/db/mysql_backend.py", line 43, in fetchone return row and self._convert_row(row) or None File "/usr/lib/python2.6/site-packages/trac/db/mysql_backend.py", line 40, in _convert_row for v in row]) File "/usr/lib64/python2.6/encodings/utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) System Information: User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20100101 Firefox/11.0
Enabled Plugins:
I'm using trac with http, mod_python and mysql backend. I think there is any strange character in the database. Therefore I created a mysqldump and then a hexdump. # grep --colour=auto -iE "\ c4\ [0-9a-f][0-9a-f]" trac.hex 00039070 3d 3d 3d 20 c4 8c 65 73 6b 79 20 3d 3d 3d 5c 6e |=== ..esky ===\n| 00039080 c4 8c 65 c5 a1 74 69 6e 61 20 76 20 6b c3 b3 64 |..e..tina v k..d| 00039160 48 72 76 61 74 73 6b 69 20 2d 20 c4 8d c4 87 c5 |Hrvatski - .....| 00039170 be c5 a1 c4 91 20 c4 8c c4 86 c5 bd c5 a0 c4 90 |..... ..........| 000394d0 64 61 20 61 72 c4 ab 20 73 74 72 c4 81 64 c4 81 |da ar.. str..d..| 00039520 c5 a1 6b 6f 73 20 72 61 69 64 c4 97 73 3f 20 c4 |..kos raid..s? .| 00039530 85 c4 8d c4 99 c4 97 c4 af c5 a1 c5 b3 c5 ab c5 |................| 00039540 be 20 c4 84 c4 8c c4 98 c4 96 c4 ae c5 a0 c5 b2 |. ..............| 000397b0 63 68 6e c4 85 c4 87 20 77 20 74 c4 99 20 c5 82 |chn.... w t.. ..| 00039800 69 65 6e 6e c4 85 20 70 72 7a 65 6b 75 6b 61 2e |ienn.. przekuka.| 000399d0 6b 6f 73 20 c4 8d 69 6e 6a 65 6e 69 63 69 20 64 |kos ..injenici d| 00039a40 6b 61 66 65 63 20 70 75 c5 a1 c4 8d 61 20 76 6f |kafec pu....a vo| 00039c30 e1 bb 87 74 20 63 c5 a9 6e 67 20 c4 91 c6 b0 e1 |...t c..ng .....| Some grepping leads to the point that I only have these characters within the language descriptions of trac. I compared this grep output to the original mysqldump. After that I started searching for an according debug mechanism to get detailed output in the trac log, but all I found was: default_charset = iso-8859-15 Could that be the problem? It would be really nice if you could give me an idea how to solve this issue. greetings Andi |
||||||||||||||||||||||||||||||||||||||||||
Abfragesprache
query:-Trac-Verweise und das [[TicketQuery]]-Makro nutzen beide eine “Abfragesprache“ geringen Umfangs, um Abfragefilter zu definieren. Grundsätzlich sind die einzelnen Filter durch Et-Zeichen (&) getrennt. Jeder Filter besteht weiterhin aus dem Ticketfeldnamen, einem Operator und einem oder mehreren Werten. Mehrere Werte werden durch senkrechte Trennstriche (|) getrennt, was bedeutet, dass der Filter auf jeden dieser Werte prüft. Um die Zeichen & oder | in einen Wert aufzunehmen, maskieren Sie das Zeichen mithilfe eines umgekehrten Schrägstrichs (\).
Die verfügbaren Operatoren sind:
| = | der Feldinhalt entspricht exakt einem der Werte |
| ~= | der Feldinhalt enthält einen oder mehrere der Werte |
| ^= | der Feldinhalt beginnt mit einem der Werte |
| $= | der Feldinhalt endet mit einem der Werte |
Jeder dieser Operatoren kann auch negiert werden:
| != | der Feldinhalt entspricht keinem der Werte |
| !~= | der Feldinhalt enthält keinen der Werte |
| !^= | der Feldinhalt beginnt mit keinem der Werte |
| !$= | der Feldinhalt endet mit keinem der Werte |
Die Datenfelder created und modified (Anm.d.Übersetzers: Erstellungszeitpunkt bzw. Zeitpunkt der letzten Ticketänderung) können mit dem =-Operator dadurch eingegrenzt werden, dass ein Wert mit zwei durch zwei Punkte (..) getrennten Datumsangaben eingesetzt wird. Beide Enden des Zeitbereichs können leer gelassen werden, gleichbedeutend damit, dass die entsprechende Grenze des Bereichs offen ist. Der Datumsübersetzer kennt einige natürliche Zeitdefinitionen wie "vor drei Wochen", "letzten Monat", und "jetzt" (Anm.d.Übersetzers: jeweils in der englisch-sprachigen Schreibweise, also "3 weeks ago", "last month" und "now"), ebenso Datumsangaben im Bugzilla-Stil wie "1d", "2w", "3m" oder "4y" für 1 Tag, 2 Wochen, 3 Monate und 4 Jahre. Leerzeichen in Datumsangaben können weggelassen werden, um das Auskommentieren von Abfrageausdrücken vermeiden zu können.
| created=2007-01-01..2008-01-01 | Suche nach Tickets, die im Jahr 2007 erstellt wurden |
| created=lastmonth..thismonth | Suche nach Tickets, die während des letzten Monats erstellt wurden |
| modified=1weekago.. | Suche nach Tickets, die in der vergangenen Woche verändert wurden sind |
| modified=..30daysago | Suche nach Tickets, die während der letzten 30 Tage unverändert geblieben sind |
Leseempfehlungen: TracTickets, TracReports, TracGuide
