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.
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.