stock-replies: Make stockreplies dataset configurable

Bug #845203 reported by Bryce Harrington
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad Greasemonkey Scripts
New
Undecided
Unassigned

Bug Description

The stockreplies script hardcodes the standard replies xml to http://people.ubuntu.com/~brian/greasemonkey/bugsquad-replies.xml.

There are many useful standard replies there for bugsquad members, such as replies for samba bugs, firefox, and so on. However, some triagers may focus on specific areas such as just kernel bugs, or just xorg, or just patches. For these users, many of the bugsquad xml replies are not needed, so would be clearer for them if they could be omitted.

At the same time, it would be helpful to be able to specify one's own stock replies via an xml file on a webserver. Currently, if you wish to use your own stock replies on multiple machines, you have to manually copy each reply into the UI, which is time consuming, and hard to deploy updates to. If you can link the replies from an xml on your own website or whatever, this becomes easier.

Currently, I personally achieve this by forking the launchpad-gm-scripts bzr and patch in my own xml URL. That's sufficient for my own purposes, but obviously won't work for those using the firefox package or who aren't as comfortable with hacking javascript.

Bryce Harrington (bryce)
summary: - Make stockreplies xml file configurable
+ Make stockreplies dataset configurable
Bryce Harrington (bryce)
summary: - Make stockreplies dataset configurable
+ stock-replies: Make stockreplies dataset configurable
Revision history for this message
Bryce Harrington (bryce) wrote :

I've landed a rewritten version of the stock-replies script, however this is still an issue.

Instead of loading from an .xml file it loads from a .js file. But changing the .js file still requires going into the script and editing it.

(Actually it's a bit worse, because before the .xml file would be loaded at runtime (I think), but now the .js only reloads when the script recompiles. So if the text in the remote .js file changes, you have to make a code change to the greasemonkey script in order to force it to reload. This workflow is awkward, but I'm not sure how to improve it.)

Making it easier for users to select which .js file to use would be very handy. An idea towards this would be to allow *all* of the .js files to be loaded, each as an item in a list or tree data structure (rather than the single 'responses' global variable.) Then add a UI element to allow picking which one to use.

Even better would be to allow the user to select multiple data sets simultaneously. So for instance, they may have one set for "Standard" replies appropriate for their team, and multiple replies specific to different groups of packages, such as "Mysql", "X.org", etc.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.