stock-replies: Make stockreplies dataset configurable
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad Greasemonkey Scripts |
New
|
Undecided
|
Unassigned | ||
Bug Description
The stockreplies script hardcodes the standard replies xml to http://
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-
| summary: |
- Make stockreplies xml file configurable + Make stockreplies dataset configurable |
| summary: |
- Make stockreplies dataset configurable + stock-replies: Make stockreplies dataset configurable |
| Bryce Harrington (bryce) wrote | #1 |
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.