GNOME Bugzilla – Bug 330321
[XML-RPC] createBug: Allow to reject stack traces
Last modified: 2006-11-05 20:56:50 UTC
When posting bugs via XML-RPC, createBug always creates a bug. I want to rename the function to something else and: 1. Parse the stacktrace 2. Check the stacktrace against known fixed stacktraces 3. Give an error message back to the user Not sure what error message. I think we need some predefined error codes as well (for i18n). Possibly: 1. Bug has been fixed - upgrade your stuff. 2. Custom message provided by a developer. 3. ?!?
That would require support by bug-buddy because it entails showing feedback to the user.
I am going to pretend the original bug was filed. E.g. if it is a dupe of bug 163163, pretend that bug has just been created.
B-B shows the bug number and an URL to it if I am not mistaken. That would fake the user and possibly confuse if he/she reads the report. I'd call it a temporary solution.
Created attachment 76030 [details] [review] Patch v1 Adding the current version of the patch for reference. Hopefully I can commit it this evening if everything goes ok. $ cvs diff | diffstat Bugzilla/DB/Schema.pm | 16 + Bugzilla/GNOME.pm | 121 +++++++++++ Bugzilla/RPC.pm | 36 +++ Bugzilla/Template/Plugin/GNOME.pm | 64 +++++ checksetup.pl | 4 dupfinder/find-traces.pl | 72 ------ dupfinder/simple-dup-finder.cgi | 6 edittraces.cgi | 229 +++++++++++++++++++++ template/en/custom/pages/admin.html.tmpl | 2 template/en/custom/traces/confirm-delete.html.tmpl | 44 ++++ template/en/custom/traces/list.html.tmpl | 77 +++++++ template/en/custom/traces/show.html.tmpl | 122 +++++++++++ template/en/default/global/messages.html.tmpl | 9 template/en/default/global/user-error.html.tmpl | 2 14 files changed, 729 insertions(+), 75 deletions(-)
Something close to above was committed. I'm going to update bugzilla-test first, then b.g.o later in the evening.
How it works: The patch adds a new table to the database called 'traces': +---------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------------+--------------+------+-----+---------+-------+ | hash | varchar(32) | NO | PRI | | | | dupe_of | mediumint(9) | NO | MUL | | | | product_id | mediumint(9) | NO | | | | | user_id | mediumint(9) | NO | | | | | version | varchar(64) | YES | | NULL | | | gnome_version | varchar(64) | YES | | NULL | | | trace | mediumtext | YES | | NULL | | +---------------+--------------+------+-----+---------+-------+ hash: this is a md5 as hex of the functions found in the backtrace. Note that the hash is UNIQUE! Meaning: you cannot reject a strack trace in 2 products. Either all products or just one. dupe_of: is a bug number. This is the 'original bug' (the one that should curently have status 'FIXED'). product_id: either the product_id that MUST match, or NULL if any product is valid user_id: User id who added or last modified the 'stack trace' (row) version: Products version or NULL if stack trace will be rejected in every product version gnome_version: Same as version, but for GNOME version. Note: Bug-Buddy might not always be able to gather the GNOME Version! trace: The back trace (not just the functions). Added just for reference. The changes: Bugzilla/DB/Schema.pm: Adds the table to the schema checksetup.pl: Ensures table is created in the database Adds 'edittraces' group Bugzilla/GNOME.pm: dupfinder/find-traces.pl: Moved get_traces_from_string into Bugzilla::GNOME. Adds a 'get_traces_info' (used directly from templates.. although I'm going to change that). Bugzilla/Template/Plugin/GNOME.pm: I'll remove this soon. Makes the Bugzilla::GNOME accessible to templates using as 'GNOME'. This for get_traces_info function. Bugzilla/RPC.pm: This actually 'rejects' stack traces. Just before it would create the bug (so after creating the user in the database, etc) it runs get_traces_from_string on the description. If it can find some functions it checks if those functions are in the traces table. It already checks if product_id/version/gnome_version is null. After that it returns the dupe_of to 'bug-buddy'. Bug-Buddy will think that the user just created that bug. template/en/default/global/messages.html.tmpl: Adds some messages about traces being added/removed/deleted. template/en/custom/traces/show.html.tmpl Shows a specific stack trace. Can actually either 'edit' an existing one, or add a new one. dupfinder/simple-dup-finder.cgi: Just some fixes. I am planning to have a custom_functions argument. This way I can make a link to let people see which bugs would be matched using the stack trace they gave. template/en/custom/pages/admin.html.tmpl: Adds 'edittraces.cgi' link to people in the edittraces group. edittraces.cgi: Allows adding/editing/removing stack traces to reject. template/en/custom/traces/confirm-delete.html.tmpl: Before deleting a stack trace, this templates does a 'Are you sure'? template/en/custom/traces/list.html.tmpl: Shows the main edittraces.cgi page; form to add a new one + list of the stack traces (with ability to remove/edit each of them). template/en/default/global/user-error.html.tmpl: Let auth_failure error know about the edittraces group Things I should do: * Show Admin in the header if people only have the edittraces group. * If original bug is still open, perhaps add new stacktrace or something. Manual work: * Ensure admins have edittraces group * Hand out edittraces + bless edittraces to a few trusted people WARNING: Due to this being very new, not enough warning messages in the UI, etc: DO NOT hand out edittraces even if you can!!! I want to instruct each person first.
I've updated bugzilla.gnome.org.