Problem/Motivation

When answering several issues a day it would be nice to have a generic stock response method.

Stock response contain both templates for comment as well as macros capable to change the issue state.

By providing an open structure to edit or add stock responses this could help all d.o projects by providing each project to add their own templates and macros.

One good example is http://drupal.org/node/1280562 which contains drupal core specific Stock Responses. Currently only the D8CI-DOCS gates.

Proposed resolution

Current version

Use the drupal.org book structure for managing the Template and Macro stock responses.

We define a top level page.

Every childpage is considered Stock Response page. The structure is laid out by definition list DL/DT/DD tags.

The sandbox project dreditor_clemens implements this.

The patch adds macro's capable to read and manipulate the issue state like tags, comment, status.

It can insert project or issue references within the comment.

It provides for a browser cache with stock responses.

Remaining tasks

It depends on
#1136342: It's impossible to run unit tests due to return statement
#1345614: Merging toggle buttons to a more consistent UX

A better demo video as the demo from http://www.youtube.com/watch?v=vpyZu9467yc is a little speedy.

User interface changes

Another row above the issue comment which can take a lot of space depending on how many top level items are defined.

API changes

Drupal.storage.cache : we need caches for all triage pages
Drupal.dreditor.macro : Provide for templates and macros
Drupal.dreditor.triage : The whole management for the issue comment regarding Stock Response

A tests/ directory for qunit tests.

Comments

clemens.tolboom’s picture

Component: Documentation » Code
FileSize
1.32 KB

[Edit]
Please watch my http://drupal.org/sandbox/clemenstolboom/1125712

[Edit]
The attached patch makes a ajax request to http://drupal.org/node/467548 childpages of http://drupal.org/node/1120672 to get to our definition list.

It is not ready yet but it works a little ;)

Things to solve:

- caching of the dd items into local storage
- make it a tree of items so a duplicate has more reasons
- better ui ? The list appears now above the 'Create triage message'

clemens.tolboom’s picture

Status: Active » Needs review
FileSize
26.61 KB

See also #651834: Git applications queue support for more ideas.

This is how it works right now.

clemens.tolboom’s picture

This patch now uses http://drupal.org/node/1118110 as it's source document.

It is now possible to have several reasons for each issue Status.

When there is no DD in the source document for a particular DT the link is not active.

See the attached screenshot of this particular issue ;)

clemens.tolboom’s picture

FileSize
3.32 KB

Added a banner to get this up to speed.

Powered by dreditor (triage patch) and Triage transitions

clemens.tolboom’s picture

Title: Help issue triage » dreditor for issue triage and project application

Changed the title to make it more attractive for irc

sun’s picture

Title: dreditor for issue triage and project application » Help issue triage
FileSize
7.12 KB

Heh. Ok, that's quite a creative solution. ;)

Thanks for working on it!

Considerations on this topic, in random order:

  1. Parsing a full HTML document without any kind of caching and also no source control doesn't really work for me.
  2. Users likely want to be able to customize the transition templates. I'm personally using some more templates that aren't contained in the "official" list.
  3. I'd expect templates to be associated with actual issue status transitions. Dreditor is able to read the current status, and it's able to observe a new status value. I'd expect tailored template suggestions to the actual transition I'm performing.

    In other words, this feature should integrate more deeply and intelligently with my user workflow/actions, instead of simply exposing a list of everything.

  4. When multiple transition templates are available, I'd like to see them grouped in categories. That is, because git/projectapplications related templates don't make sense elsewhere aso.

    Zendesk solves this by using :: in labels; i.e., Project applications::Missing .info file, leading to:

    macro-categories.png

  5. Some of the templates need custom values to be inserted somewhere in the text (e.g., duplicate of ...) - in a second/later step, it would make sense to allow certain transitions to invoke a widget to enter values for template variables.

btw, Zendesk calls this "macros" instead of templates. Not sure whichever is a more proper term...

clemens.tolboom’s picture

FileSize
4.48 KB

@sun remarks:

1. Caching and source control
Caching See #2 (how store settings)
Source control? What do you mean by that?

2. It's possible to have multiple sources but I need UI feedback to make this nicer.
The new patch has now two sources for triage. So it's possible to have more.

But for that I need to know how to store settings ... it's in dreditor somewhere?

3. How is this current working in dreditor?
My ideas are related to this current state ... dim items not related to current state, assign to, etc.
Where is this in dreditor code?

4. Is this mere UI or context based?
I want to add config settings to filter out / dim categories based on 'whatever'

5. macros
Sounds ok to me ... a macro is at least not a .tpl.php

Anyway ... I want this patch useable asap for the project application issues.

Known issues are:
- toggle is not working properly ... needs get fixed asap
- caching is not done
- no config

I would like to have a workable first then do 'config' and 'caching' in different tickets although it doesn't sound to complicated.

What do you think how to implement this feature quickest?

clemens.tolboom’s picture

Component: Code » Documentation

Added definition list DL bug #1120618: CSS misses layout of nested definition lists to help displaying http://drupal.org/node/1119350 correctly.

clemens.tolboom’s picture

FileSize
5.38 KB

Current version:
- moved triage items into separate div
- using storage but having issues with global storage (is this due to greasemonkey?) ... using local storage

Known issues:
- toggle is not working yet
- the code is placed somewhat in the wrong place (Drupal.behaviors.dreditorCommitMessage)
- there is no user customization. My guess is global storage is prohibited by greasemonkey which means we need a real firefox plugin. What do you think?

the attached patch needs review

Powered by dreditor (triage patch) and Triage transitions

clemens.tolboom’s picture

Status: Needs review » Needs work

Blast and testing ...

+++ b/dreditor.user.js
@@ -1389,6 +1389,149 @@ Drupal.behaviors.dreditorCommitMessage = function (context) {
+        local_1119350 : {
+	      url : './local-nodes/1119350.html',
+          description : 'Local Project Application'

Whitespace

Powered by Dreditor.

The code contains whitespace problems. The code contains whitespace problems. Please use http://drupal.org/project/coder to check your code.

Powered by dreditor (triage patch) and Triage transitions

clemens.tolboom’s picture

Status: Needs work » Needs review
FileSize
6.85 KB

The attached patch:

- cache implemented: local cache is working fine ... 'local' means site bound
- banner replaced with a source link

Known issues:

- toggle is not working yet
- the code is placed somewhat in the wrong place (Drupal.behaviors.dreditorCommitMessage)

Features still needed:

- auto discovery through http://drupal.org/node/1120672 by grabbing it's child pages

- setting status (and other issue values)
-- develop a macro language suitable for d.o page structures
--- is a @fieldname(new-value) and @old-fieldname a good start?

clemens.tolboom’s picture

I moved this over to http://drupal.org/sandbox/clemenstolboom/1125712 which makes it way easier to follow all features in a working state.

Please take over the good parts asap ;)

clemens.tolboom’s picture

Component: Code » Documentation
Status: Needs review » Postponed

As I have now a sandbox we can best test over there first and then mergeback into dreditor.git

clemens.tolboom’s picture

clemens.tolboom’s picture

Component: Documentation » Code
Status: Postponed » Active

Should I add a patch here (It's functional without #1136342: It's impossible to run unit tests due to return statement)
or
expect people to use my sandbox version http://drupal.org/sandbox/clemenstolboom/1125712 which is runable?

clemens.tolboom’s picture

Title: Help issue triage » Issue state management and Stock Responses
Status: Active » Needs review
FileSize
88.13 KB

Attached the latest version. Features are:
- Settings issue fields like status, tags, comment
- Getting issue fields
- Getting prompts for duplicate_issue, duplicate_project, depends_on_issue, blocks_issue

the attached patch needs review

Powered by Dreditor (triage sandbox) and Triage transitions

+++ b/dreditor.user.jsundefined
@@ -565,6 +565,35 @@ Drupal.storage.unserialize = function (val) {
+Drupal.storage.cache = {
+  set : function(id, cacheTable) {

Added cache support

+++ b/dreditor.user.jsundefined
@@ -614,6 +643,256 @@ Drupal.dreditor.form.form.prototype = {
+Drupal.dreditor.macro = {

Added macro

+++ b/dreditor.user.jsundefined
@@ -1455,9 +1734,244 @@ Drupal.behaviors.dreditorCommitMessage = function (context) {
 
+Drupal.dreditor.triage = {

Added triage UI

Powered by Dreditor.

clemens.tolboom’s picture

sun’s picture

Sorry, didn't have time to look into the code yet.

However, I did wonder about the macro/token syntax, and asked myself why we're not using a syntax like tokens in D7 core?

Aside from that, the UI/UX still looks a bit confusing/clumsy to me...? Can we attempt to do something along the lines of #6? :)

clemens.tolboom’s picture

For the macro's we need get/set/old/query constructs. I skipped that at first and did my own construct as I was afraid of token clashes. But on second thought ...

Tokens are (D7) just [$type:$name] for get/old constructs and [$type:$name _VALUE_] for set and [$type:$name ?] for query.

Get/oldGet [issue:tags] [issue:comment] [issue:oldTags]
Set [issue:status 3] [issue:tags -D8CI]
Query [issue:reference] [project:reference]

Regarding the UI/UX

I hate mouse move so for me the current UI is fine (one big blob) but we can do both I guess. I'll try to consult bohjan.

sun’s picture

oh, I didn't really think of the token-with-actual-value, so I take that back. The token syntax is only suitable for replacement tokens, not really for specifying values.

The next best thing that comes to mind is, actually, pure JSON - along the lines of:

When: {project:"drupal",issue:{status:"active"}}
Do: {issue:{status:"duplicate"}}

However, guess I have to look into this some more first...

clemens.tolboom’s picture

The puzzle I solved with the @oldX() construct like (taken from http://drupal.org/node/1118110)

Fixed @status(2) @oldStatus(active) @oldStatus(needs review)

is to indicate Fixed is only relevant for 'Active' or 'needs review' issues (a state transition). It is easy to parse by using 'old' for current state. My guess is the setters are easier to read compared to json as they are separated as strings.

A query like (taken from Stock response on http://drupal.org/node/1118110)
Depends on @depends_on_issue(?) would be better readable with a token construct like

This issue is blocked by [issue:reference Please give the depends on issue #]
clemens.tolboom’s picture

I just tried to start fixing my sandbox #1280412: Tags are inserted multiple times and first added a test for that.

@sun: Please have a look at my test for macro's in action at http://drupalcode.org/sandbox/clemenstolboom/1125712.git/blob_plain/refs... or visit http://drupalcode.org/sandbox/clemenstolboom/1125712.git/blob_plain/refs...

There is a lot of effort done in the tests. I'd opt for leaving macros as is and focus on template for token.

About macro versus template
- templates are what is inserted into the issue comment
- macros are manipulating the issue state. (I know comment is part of the state)
What do you think?

clemens.tolboom’s picture

Apart from the macro construct I think this is now ready for review :-)

See #1141242: The query macro @field(?) seems a little duplicate

[edit]The image below is the current state.

dreditor-triage-20110921- 112723.png

[edit] end of image

clemens.tolboom’s picture

The attached patch has 3 chunks

#1 is for my unit tests ... see #1136342: It's impossible to run unit tests due to return statement
#2 is the triage patch
#3 is for my unit tests to have the buttons visible

See http://drupal.org/project/1125712/git-instructions or run the unit tests straight from http://drupalcode.org/sandbox/clemenstolboom/1125712.git/tree/refs/heads...

For open issues see http://drupal.org/project/issues/1125712

clemens.tolboom’s picture

Issue summary: View changes

Changed the whole text and added the demo video.

clemens.tolboom’s picture

Issue summary: View changes

Implemented the Issue Template

clemens.tolboom’s picture

Issue summary: View changes

Added link to D8CI-DOCS gates as an useful example

clemens.tolboom’s picture

Issue summary: View changes

Fixed close tag on link

clemens.tolboom’s picture

Issue summary: View changes

Updated issue summary.

clemens.tolboom’s picture

Latest version

clemens.tolboom’s picture

Issue summary: View changes

Added image

clemens.tolboom’s picture

Issue summary: View changes

Update image

clemens.tolboom’s picture

Title: Issue state management and Stock Responses » Issue Macros and Templates
FileSize
41.13 KB

The sandbox is active. It contains #1345614: Merging toggle buttons to a more consistent UX which is bad. Anyway it looks like this
==== image begin
dreditor-triage-20111214.png
==== image end

helmo’s picture

Status: Needs review » Needs work

I've just done a rebase of this branch based on master.

It's now known as dreditor-1115636-rebased, but needs work to get it functional again.

helmo’s picture

Issue summary: View changes

Updated issue summary.

helmo’s picture

Status: Needs work » Closed (duplicate)