I've found that several of the built-in templates need a bit of work
to be useful with our JIRA installation (eg #24), so this allows for admins
to make a site-specific set of defaults easily.
The ```expand``` option is used to specify resource expansion in the
Jira REST API.
It's particularly useful for things like fetching the ```changelog``` of
an Issue.
This PR adds the support to the ```ListIssues``` and ```ViewIssue```
functions of the ```jira.Cli``` struct.
I'm happy to add tests, but there is currently no test suite in the
master branch, so I did not want to bog down the PR with tangential features.
It is valid within JIRA to have issue types with spaces (for example we use
"Pro-Active Task") however the issuetype variable is not escaped prior to
formatting into the uri string.
This fix imports "net/url" and escapes all inclusions of issuetype into uri.
The only other variables formatted into uri are c.endpoint and issue which
shouldn't contain special characters.
TL;DR, this ensures ~/jira.d is present, with 0755 perms.
If ~/jira.d isn't present, we can't write to the cookieFile, which
breaks CmdLogin. This is particularly an issue when using /etc/go-jira.yml
to get an entire team using go-jira easily :)
This fixes this by ensuring the cookieFile dir is present before
writing to it.
This adds the basics of the component API:
* listing of components assigned to a project
* adding new components to a project.
The interface to 'add component' is similar to that of 'labels', as
previously discussed. We can implement remove/update later.
This adjusts the CmdWatch interface as per discussion in
https://github.com/Netflix-Skunkworks/go-jira/pull/26
It also exposes public versions of the c.getOptString and c.getOptBool
utility functions, again as discussed.
The interface to CmdWatch now includes the user to be watched (rather than
depending on the opt[] map. This makes CmdWatch more useful externally.
A '--remove' option has been created, to allow for removal of a given watcher.
This was deliberately not included in the defaults map, as it is specifically only
used for 'watch' command right now. It should be moved up to a default if it becomes
a more common option, I guess (as 'remove is false' isn't a bad default)
This simplifies the interface to voting, as per the discussion in
https://github.com/Netflix-Skunkworks/go-jira/pull/26
Basically, DRY out the logic into a single CmdVote function based
around an 'up' bool. Similarly, make a single CLI command with an
option to do the downvote.
This adds support for voting on issues via CmdVote() and CmdUnvote()
Voting on issues is always done as the logged in user, it appears you
can't case a vote for another user:
https://docs.atlassian.com/jira/REST/latest/#api/2/issue-addVote
This required adding a cli.delete() handler, naturally with no content
(as per RFC2616)
This is ripe for DRY-ing out, but I will leave that for a future PR.
Worth noting is that you cannot vote for your own issues, this results in:
2016-01-13T21:35:41.315Z ERROR [cli.go:184] response status: 404 Not Found
2016-01-13T21:35:41.315Z ERROR [commands.go:439] Unexpected Response From POST:
{snip}
{"errorMessages":["You cannot vote for an issue you have reported."],"errors":{}}
The CLI looks for commands (like 'labels') in the first two positional args. This
is how commands like 'BLOCKER blocks ISSUE' work.
As per @coryb's comments in #21 - this allows us to support set/add/remove in a
consistent way for other types: components for example.
This commit rearranges the command to be as follows:
jira (set/add/remove) labels ISSUE LABELS...
The options to CmdLabels have been reordered accordingly.
GetTemplate and RunTemplate allow external users to access the template system,
and in particular allow them to provide their own Buffer to write the output to.
I've implemented exposed versions calling the private functions, rather than breaking
the internal API. If this isn't a concern, we should remove getTemplate and runTemplate
in a future commit.
This adds 'labels' command, which allows for the setting, addition and removal
of labels on an issue.
'set' action resets the issue labels to the list provided.
'add' action adds the supplied labels to the issue
'remove' action removes the supplied labels from the issue
The API already gracefully handles duplication, removal of non-existant labels, and the
supplying of an empty list of labels (which is useful in the case of 'set')
Eg
jira labels TEST-123 add label1 label2 label3
jira labels TEST-123 remove label1 label2
jira labels TEST-123 set label1 label2 label3
jira labels TEST-123 set # clears any labels on the issue
jira labels TEST-123 add # no-op
jira labels TEST-123 remove # no-op
This mirrors the functionality of the API.
Cory Bennett