Close the issue with a reference to the committed changeset

[GoogleCodeExporter]

It would be nice, if the issue status would be set to 'fixed', when a fix
is commited.
The issue comment could read 'Issue fixed by r52: _commit comment_'.

(I have seen a proposal for an option to differntiate between 'fixing' and
'adding to' an issue.
In this case the status could remain anchanged, but maybe the comment would
be added to the issue.)

Original issue reported on code.google.com by moo...@wwwendt.de on 9 Sep 2008 at 6:17

[GoogleCodeExporter]

This will be difficult to address unless there is an API for the Google Code 
issue 
tracker. It could be done today via standard form submission but it needs 
further 
investigation into how to authenticate the user.

Original comment by azizatif on 9 Sep 2008 at 7:25

• Changed title: Close the issue with a reference to the committed changeset
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

This would be really useful, if it were at all possible.

Original comment by universe...@gmail.com on 14 Sep 2008 at 11:56

[GoogleCodeExporter]

it would be extremely useful indeed, but it will most likely be quite hard to
implement...

Original comment by bgmei...@gmail.com on 15 Sep 2008 at 6:43

[GoogleCodeExporter]

For now, this issue seems impossible to address due to the timing at which an 
IBugTraqProvider plug-in like Gurtle is involved. The revision number of the 
commit 
is not known until the commit is made, which may be long after Gurtle's issue 
browsing and selection dialog has been discarded and the plug-in unloaded. So 
even 
if Google's project hosting provides a Web service-ish interface to the issue 
tracking system, the difficulty of implementation will shift to the current 
level of 
extensibility afforded by TortoiseSVN. It is conceivable to invoke Gurlte once 
more 
via a post-commit client-side hook (TortoiseSVN docs § 5.29.7) but that makes 
for, 
at best, a clumsy solution that requires too much setup and configuration from 
the 
user. It would be best if a plug-in could subscribe to client-side hooks as 
events, 
but until that happens, it's best to close this issue. It can always be visited 
again and re-opened if such extensibility becomes available.

Original comment by azizatif on 16 Sep 2008 at 7:59

• Changed state: WontFix
• Added labels: Component-Logic

[GoogleCodeExporter]

Also note the following issue:
http://code.google.com/p/support/issues/detail?id=148

Original comment by tortoisesvn on 7 Oct 2008 at 10:02

[GoogleCodeExporter]

@tortoisesvn. Yep, I've got that issue starred since a while. :) Even if an API 
is 
published, it remains a chicken-or-egg problem as described in comment #4 
because 
TortoiseSVN doesn't involve the plug-in at post-commit-time.

Original comment by azizatif on 7 Oct 2008 at 11:08

[GoogleCodeExporter]

Well, implementing the post-commit event for the plugin would be my job :)

Original comment by tortoisesvn on 7 Oct 2008 at 11:10

[GoogleCodeExporter]

Added an issue for this:
http://issues.tortoisesvn.net/index.php?do=details&task_id=428

Original comment by tortoisesvn on 11 Oct 2008 at 8:30

[GoogleCodeExporter]

WillFix :) now that IBugTraqProvider2 has OnCommitFinished. See also issue #20.

- How to authenticate with the Google Account?
- If and where to save Google Account credentials locally?
- How to submit the actual closing of the issue using HTML FORM POST?

Original comment by azizatif on 11 Nov 2008 at 5:16

• Changed state: New
• Added labels: Component-UI

[GoogleCodeExporter]

Here are some interim notes (for review/feedback) based on research regarding 
how to
solve this issue.

Authenticating and logging-in with a Gmail account is rather simple. One needs 
to
simply issue an HTTP GET for the following URL:

https://www.google.com/accounts/ServiceLoginAuth?service=mail&Email=USERNAME&Pas
swd=PASSWORD

The e-mail address and password go in the "Email" and "Passwd" query parameters,
respectively. Unfortunately, since service is "mail", non-Gmail accounts cannot 
be
authenticated this way and so that still needs further investigation.

A successful authentication returns an opaque security token in a cookie and 
this has
to be maintained and returned with subsequent requests.

The easiest way to update an issue is to use the bulk-editing facility, even if 
only
one issue needs updating. First an HTTP GET needs to be issued to:

http://code.google.com/p/PROJECT/issues/bulkedit?ids=ISSUES

Here the "ids" query string parameter can have a comma-separated like of issue
numbers. For a single issue, though, it can be just the issue number. Within the
returned HTML response lies a token, which appears to be a GUID. The token can 
be
retrieved by sniffing all INPUT tags of type hidden and grabbing the value of 
the one
where the name reads "token". This token is needed for the update.

Finally, for the update of the issue, an HTTP POST must be sent to:

http://code.google.com/p/PROJECT/issues/bulkedit.do

The Content-Type of the POST must be "multipart/form-data" otherwise the 
transaction
ends in 400 (Bad Request). The minimum form data that appears to be needed for 
the
update is:

can = "1"
start = "0"
num = "100"
q = BLANK
sort = BLANK
colspec = BLANK
issue_ids = ISSUE
token = TOKEN
comment = "Fixed in REVISION."
status = "Fixed"

Literal values are shown in quotes. BLANK means the field must be present but 
has no
value. Leaving these fields out completely returns a 400 (Bad Request) 
response. The
rest is explain below:

  - ISSUE is the issue number, 
  - TOKEN is the token scraped from bulk-edit HTML earlier 
  - REVISION is the commit revision number to put in the comment.

That's it for now.

Original comment by azizatif on 13 Nov 2008 at 11:57

[GoogleCodeExporter]

Attaching Python (IronPython, actually) script to serve as a proof-of-concept 
of 
notes in comment #10 above.

Original comment by azizatif on 14 Nov 2008 at 12:24

Attachments:

• TestUpdateIssue.py

[GoogleCodeExporter]

Someone posted a python script to the svn dev mailing list:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=982455

The script can be found here:
http://cgi.sfu.ca/~jdbates/tmp/google/200812100/google-issue-post-commit

File also attached, just in case the webpage goes 404...

Maybe the script is useful to see how others do this.

Original comment by tortoisesvn on 10 Dec 2008 at 8:30

Attachments:

• google-issue-post-commit

[GoogleCodeExporter]

I checked out the google-issue-post-commit script and it's pretty similar in 
nature 
to the TestUpdateIssue.py I posted earlier as part of comment #11. The login 
method 
seems a bit different and may allow for non-Gmail accounts to be authenticated, 
but 
I have to test this. It will definitely help when it comes to addressing this 
issue, 
though both remain vulnerable (to changes in server-side form processing) until 
an 
API is published. Thanks anyway for sharing the script.

Original comment by azizatif on 11 Dec 2008 at 7:12

[GoogleCodeExporter]

Original comment by azizatif on 9 Apr 2009 at 8:24

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by azizatif on 12 Apr 2009 at 9:17

• Changed state: Started

[GoogleCodeExporter]

Original comment by azizatif on 12 Apr 2009 at 1:23

[GoogleCodeExporter]

Implemented in r172.

Original comment by azizatif on 9 May 2009 at 11:29

• Changed state: Fixed

[GoogleCodeExporter]

Re-opened this issue to address it differently now that GCPH has an official 
API for 
the issue tracker:
http://code.google.com/p/support/wiki/IssueTrackerAPI

Original comment by azizatif on 22 Jan 2010 at 5:35

• Changed state: Started

[GoogleCodeExporter]

Original comment by azizatif on 22 Jan 2010 at 5:36

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

Here's a C# library for accessing the issue tracker API:
http://code.google.com/p/google-code-issue-tracker/

Original comment by tortoisesvn on 19 Mar 2010 at 10:14