Provided by: libjira-client-automated-perl_1.60-1_all bug

NAME

       JIRA::Client::Automated - A JIRA REST Client for automated scripts

VERSION

       version 1.6

SYNOPSIS

           use JIRA::Client::Automated;

           my $jira = JIRA::Client::Automated->new($url, $user, $password);

           # If your JIRA instance does not use username/password for authorization
           my $jira = JIRA::Client::Automated->new($url);

           my $jira_ua = $jira->ua(); # to add in a proxy

           $jira->trace(1); # enable tracing of requests and responses

           # The simplest way to create an issue
           my $issue = $jira->create_issue($project, $type, $summary, $description);

           # The simplest way to create a subtask
           my $subtask = $jira->create_subtask($project, $summary, $description, $parent_key);

           # A complex but flexible way to create a new issue, story, task or subtask
           # if you know Jira issue hash structure well.
           my $issue = $jira->create({
               # Jira issue 'fields' hash
               project     => {
                   key => $project,
               },
               issuetype   => {
                   name => $type,      # "Bug", "Task", "Sub-task", etc.
               },
               summary     => $summary,
               description => $description,
               parent      => {        # only required for a subtask
                   key => $parent_key,
               },
               ...
           });

           my $search_results = $jira->search_issues($jql, 1, 100); # query should be a single string of JQL
           my @issues = $jira->all_search_results($jql, 1000); # query should be a single string of JQL

           my $issue = $jira->get_issue($key);

           $jira->update_issue($key, $update_hash); # update_hash is { field => value, ... }
           $jira->create_comment($key, $text);
           $jira->attach_file_to_issue($key, $filename);

           $jira->transition_issue($key, $transition, $transition_hash); # transition_hash is { field => value, ... }

           $jira->close_issue($key, $resolve, $comment); # resolve is the resolution value
           $jira->delete_issue($key);

           $jira->add_issue_watchers($key, $watcher1, ......);
           $jira->add_issue_labels($key, $label1, ......);

DESCRIPTION

       JIRA::Client::Automated is an adapter between any automated system and JIRA's REST API.
       This module is explicitly designed to easily create and close issues within a JIRA
       instance via automated scripts.

       For example, if you run nightly batch jobs, you can use JIRA::Client::Automated to have
       those jobs automatically create issues in JIRA for you when the script runs into errors.
       You can attach error log files to the issues and then they'll be waiting in someone's open
       issues list when they arrive at work the next day.

       If you want to avoid creating the same issue more than once you can search JIRA for it
       first, only creating it if it doesn't exist. If it does already exist you can add a
       comment or a new error log to that issue.

WORKING WITH JIRA 6 Atlassian has made a very complete REST API for recent (> 5.0) versions of

       JIRA. By virtue of being complete it is also somewhat large and a little complex for the
       beginner. Reading their tutorials is *highly* recommended before you start making hashes
       to update or transition issues.
       <https://developer.atlassian.com/display/JIRADEV/JIRA+REST+APIs>

       This module was designed for the JIRA 5.2.11 REST API, as of March 2013, but it works fine
       with JIRA 6.0 as well. Your mileage may vary with future versions.

JIRA ISSUE HASH FORMAT

       When you work with an issue in JIRA's REST API, it gives you a JSON file that follows this
       spec:

       <https://developer.atlassian.com/display/JIRADEV/The+Shape+of+an+Issue+in+JIRA+REST+APIs>

       JIRA::Client::Automated tries to be nice to you and not make you deal directly with JSON.
       When you create a new issue, you can pass in just the pieces you want and "create_issue"
       will transform them to JSON for you. The same for closing and deleting issues.

       Updating and transitioning issues is more complex.  Each JIRA installation will have
       different fields available for each issue type and transition screen and only you will
       know what they are. So in those cases you'll need to pass in an "update_hash" which will
       be transformed to the proper JSON by the method.

       An update_hash looks like this:

           { field1 => value, field2 => value2, ...}

       For example:

           {
               host_id => "example.com",
               { resolution => { name => "Resolved" } }
           }

       If you do not read JIRA's documentation about their JSON format you will hurt yourself
       banging your head against your desk in frustration the first few times you try to use
       "update_issue". Please RTFM.

       Note that even though JIRA requires JSON, JIRA::Client::Automated will helpfully translate
       it to and from regular hashes for you. You only pass hashes to JIRA::Client::Automated,
       not direct JSON.

       I recommend connecting to your JIRA server and calling "get_issue" with a key you know
       exists and then dump the result. That'll get you started.

METHODS

   new
           my $jira = JIRA::Client::Automated->new($url, $user, $password);

       Create a new JIRA::Client::Automated object by passing in the following:

       1. URL for the JIRA server, such as "http://example.atlassian.net/"

       2. Username to use to login to the JIRA server

       3. Password for that user

       All three parameters are required if your JIRA instance uses basic authorization, for
       which JIRA::Client::Automated must connect to the JIRA instance using some username and
       password. You may want to set up a special "auto" or "batch" username to use just for use
       by scripts.

       If you are using Google Account integration, the username and password to use are the ones
       you set up at the very beginning of the registration process and then never used again
       because Google logged you in.

       If you have other ways of authorization, like GSSAPI based authorization, do not provide
       username or password.

           my $jira = JIRA::Client::Automated->new($url);

   ua
           my $ua = $jira->ua();

       Returns the LWP::UserAgent object used to connect to the JIRA instance.  Typically used to
       setup proxies or make other customizations to the UserAgent.  For example:

           my $ua = $jira->ua();
           $ua->env_proxy();
           $ua->ssl_opts(...);
           $ua->conn_cache( LWP::ConnCache->new() );

   trace
           $jira->trace(1);       # enable
           $jira->trace(0);       # disable
           $trace = $jira->trace;

       When tracing is enabled each request and response is logged using carp.

   create
           my $issue = $jira->create({
               # Jira issue 'fields' hash
               project     => {
                   key => $project,
               },
               issuetype   => {
                   name => $type,      # "Bug", "Task", "SubTask", etc.
               },
               summary     => $summary,
               description => $description,
               parent      => {        # only required for a subtask
                   key => $parent_key,
               },
               ...
           });

       Creating a new issue, story, task, subtask, etc.

       Returns a hash containing only the basic information about the new issue, or dies if there
       is an error. The hash looks like:

           {
               id => 24066,
               key => "TEST-57",
               self => "https://example.atlassian.net/rest/api/latest/issue/24066"
           }

       See also
       <https://developer.atlassian.com/display/JIRADEV/JIRA+REST+API+Example+-+Create+Issue>

   create_issue
           my $issue = $jira->create_issue($project, $type, $summary, $description, $fields);

       Creating a new issue requires the project key, type ("Bug", "Task", etc.), and a summary
       and description.

       The optional $fields parameter can be used to pass a reference to a hash of extra fields
       to be set when the issue is created, which avoids the need for a separate "update_issue"
       call. For example:

           $jira->create_issue($project, $type, $summary, $description, {
               labels => [ "foo", "bar" ]
           });

       This method calls "create" and return the same hash reference that it does.

   create_subtask
           my $subtask = $jira->create_subtask($project, $summary, $description, $parent_key);
           # or with optional subtask type
           my $subtask = $jira->create_subtask($project, $summary, $description, $parent_key, 'sub-task');

       Creating a subtask. If your JIRA instance does not call subtasks "Sub-task" or "sub-task",
       then you will need to pass in your subtask type.

       This method calls "create" and return the same hash reference that it does.

   update_issue
           $jira->update_issue($key, $field_update_hash, $update_verb_hash);

       There are two ways to express the updates you want to make to an issue.

       For simple changes you pass $field_update_hash as a reference to a hash of field_name =>
       new_value pairs. For example:

           $jira->update_issue($key, { summary => $new_summary });

       That works for simple fields, but there are some, like comments, that can't be updated in
       this way. For them you need to use $update_verb_hash.

       The $update_verb_hash parameter allow you to express a series of specific operations
       (verbs) to be performed on each field. For example:

           $jira->update_issue($key, undef, {
               labels   => [ { remove => "test" }, { add => "another" } ],
               comments => [ { remove => { id => 10001 } } ]
           });

       The two forms of update can be combined in a single call.

       For more information see:

           https://developer.atlassian.com/display/JIRADEV/JIRA+REST+API+Example+-+Edit+issues
           https://developer.atlassian.com/display/JIRADEV/Updating+an+Issue+via+the+JIRA+REST+APIs

   get_issue
           my $issue = $jira->get_issue($key);

       Returns details for any issue, given its key. This call returns a hash containing the
       information for the issue in JIRA's format. See "JIRA ISSUE HASH FORMAT" for details.

   transition_issue
           $jira->transition_issue($key, $transition);
           $jira->transition_issue($key, $transition, $update_hash);

       Transitioning an issue is what happens when you click the button that says "Resolve Issue"
       or "Start Progress" on it. Doing this from code is harder, but JIRA::Client::Automated
       makes it as easy as possible.

       You pass this method the issue key, the name of the transition or the target status
       (spacing and capitalization matter), and an optional update_hash containing any fields
       that you want to update.

       Specifying The Transition

       The provided $transition name is first matched against the available transitions for the
       $key issue ('Start Progress', 'Close Issue').  If there's no match then the names is
       matched against the available target status names ('Open', 'Closed'). You can use
       whichever is most appropriate.  For example, in your configuration the transition names
       might vary between different kinds of projects but the status names might be the same.  In
       which case scripts that are meant to work across multiple projects might prefer to use the
       status names.

       The $transition parameter can also be specified as a reference to an array of names. In
       this case the first one that matches either a transition name or status name is used.
       This makes it easier for scripts to work across multiple kinds of projects and/or handle
       the migration of names by allowing current and future names to be used, so the later
       change in JIRA config doesn't cause any breakage.

       Specifying Updates

       If you have required fields on the transition screen (such as "Resolution" for the
       "Resolve Issue" screen), you must pass those fields in as part of the update_hash or you
       will get an error from the server. See "JIRA ISSUE HASH FORMAT" for the format of the
       update_hash.

       (Note: it appears that in some obscure cases missing required fields may cause the
       transition to fail without causing an error from the server. For example a field that's
       required but isn't configured to appear on the transition screen.)

       The $update_hash is a combination of the $field_update_hash and $update_verb_hash
       parameters used by the "update_issue" method. Like this:

           $update_hash = {
               fields => $field_update_hash,
               update => $update_verb_hash
           };

       You can use it to express both simple field settings and more complex update operations.
       For example:

           $jira->transition_issue($key, $transition, {
               fields => { summary => $new_summary },
               update => {
                   labels   => [ { remove => "test" }, { add => "another" } ],
                   comments => [ { remove => { id => 10001 } } ]
               }
           });

   close_issue
           $jira->close_issue($key);
           $jira->close_issue($key, $resolve);
           $jira->close_issue($key, $resolve, $comment);
           $jira->close_issue($key, $resolve, $comment, $update_hash);
           $jira->close_issue($key, $resolve, $comment, $update_hash, $operation);

       Pass in the resolution reason and an optional comment to close an issue. Using this method
       requires that the issue is is a status where it can use the "Close Issue" transition (or
       other one, specified by $operation).  If not, you will get an error from the server.

       Resolution ("Fixed", "Won't Fix", etc.) is only required if the issue hasn't already been
       resolved in an earlier transition. If you try to resolve an issue twice, you will get an
       error.

       If you do not supply a comment, the default value is "Issue closed by script".

       The $update_hash can be used to set or edit the values of other fields.

       The $operation parameter can be used to specify the closing transition type. This can be
       useful when your JIRA configuration uses nonstandard or localized transition and status
       names, e.g.

               use utf8;
               $jira->close_issue($key, $resolve, $comment, $update_hash, "Done");

       See "transition_issue" for more details.

       This method is a wrapper for "transition_issue".

   delete_issue
           $jira->delete_issue($key);

       Deleting issues is for testing your JIRA code. In real situations you almost always want
       to close unwanted issues with an "Oops!" resolution instead.

   create_comment
           $jira->create_comment($key, $text);

       You may use any valid JIRA markup in comment text. (This is handy for tables of values
       explaining why something in the database is wrong.) Note that comments are all created by
       the user you used to create your JIRA::Client::Automated object, so you'll see that name
       often.

   search_issues
           my @search_results = $jira->search_issues($jql, 1, 100, $fields);

       You've used JQL before, when you did an "Advanced Search" in the JIRA web interface.
       That's the only way to search via the REST API.

       This is a paged method. Pass in the starting result number and number of results per page
       and it will return issues a page at a time. If you know you want all of the results, you
       can use "all_search_results" instead.

       Optional parameter $fields is the arrayref containing the list of fields to be returned.

       This method returns a hashref containing up to five values:

       1. total => total number of results

       2. start => result number for the first result

       3. max => maximum number of results per page

       4. issues => an arrayref containing the actual found issues

       5. errors => an arrayref containing error messages

       For example, to page through all results $max at a time:

           my (@all_results, @issues);
           do {
               $results = $self->search_issues($jql, $start, $max);
               if ($results->{errors}) {
                   die join "\n", @{$results->{errors}};
               }
               @issues = @{$results->{issues}};
               push @all_results, @issues;
               $start += $max;
           } until (scalar(@issues) < $max);

       (Or just use "all_search_results" instead.)

   all_search_results
           my @issues = $jira->all_search_results($jql, 1000);

       Like "search_issues", but returns all the results as an array of issues.  You can specify
       the maximum number to return, but no matter what, it can't return more than the value of
       jira.search.views.default.max for your JIRA installation.

   get_issue_comments
           $jira->get_issue_comments($key);

       Returns arryref of all comments to the given issue.

   attach_file_to_issue
           $jira->attach_file_to_issue($key, $filename);

       This method does not let you attach a comment to the issue at the same time.  You'll need
       to call "create_comment" for that.

       Watch out for file permissions! If the user running the script does not have permission to
       read the file it is trying to upload, you'll get weird errors.

   make_browse_url
           my $url = $jira->make_browse_url($key);

       A helper method to return the "".../browse/$key"" url for the issue.  It's handy to make
       emails containing lists of bugs easier to create.

       This just appends the key to the URL for the JIRA server so that you can click on it and
       go directly to that issue.

   get_link_types
           my $all_link_types = $jira->get_link_types();

       Get the arrayref of all possible link types.

   link_issues
           $jira->link_issues($from, $to, $type);

       Establish a link of the type named $type from issue key $from to issue key $to .  Returns
       nothing on success; structure containing error messages otherwise.

   add_issue_labels
           $jira->add_issue_labels($issue_key, @labels);

       Adds one more more labels to the specified issue.

   remove_issue_labels
           $jira->remove_issue_labels($issue_key, @labels);

       Removes one more more labels from the specified issue.

   add_issue_watchers
           $jira->add_issue_watchers($key, @watchers);

       Adds watchers to the specified issue. Returns nothing if success; otherwise returns a
       structure containing error message.

   get_issue_watchers
           $jira->get_issue_watchers($key);

       Returns arryref of all watchers of the given issue.

   assign_issue
           $jira->assign_issue($key, $assignee_name);

       Assigns the issue to that person. Returns the key of the issue if it succeeds.

   add_issue_worklog
           $jira->add_issue_worklog($key, $worklog);

       Adds a worklog to the specified issue. Returns nothing if success; otherwise returns a
       structure containing error message.

       Sample worklog: {
           "comment" => "I did some work here.",
           "started" => "2016-05-27T02:32:26.797+0000",
           "timeSpentSeconds" => 12000, }

   get_issue_worklogs
           $jira->get_issue_worklogs($key);

       Returns arryref of all worklogs of the given issue.

FAQ

   Why is there no object for a JIRA issue?
       Because it seemed silly. You could write such an object and give it methods to transition
       itself, close itself, etc., but when you are working with JIRA from batch scripts, you're
       never really working with just one issue at a time.  And when you have a hundred of them,
       it's easier to not objectify them and just use JIRA::Client::Automated as a mediator. That
       said, if this is important to you, I wouldn't say no to a patch offering this option.

BUGS

       Please report bugs or feature requests to the author.

AUTHOR

       Michael Friedman <frimicc@cpan.org>

CREDITS

       Thanks very much to:

       Tim Bunce <timb@cpan.org>
       Dominique Dumont <ddumont@cpan.org>
       Zhuang (John) Li <7humblerocks@gmail.com>
       Ivan E. Panchenko <panchenko@cpan.org>
       José Antonio Perez Testa <japtesta@gmail.com>
       Frank Schophuizen <Frank.Schophuizen@philips.com>
       Zhenyi Zhou <zhenyz@cpan.org>
       Roy Lyons <Roy.Lyons@cmegroup.com>
       Neil Hemingway <hemingway@cpan.org>

COPYRIGHT AND LICENSE

       This software is copyright (c) 2016 by Polyvore, Inc.

       This is free software; you can redistribute it and/or modify it under the same terms as
       the Perl 5 programming language system itself.