kbenzie / git-issue Goto Github PK

From github.py:

TODO: Currently only 'closed' and 'reopned' events are
supported due to limitations of other services, requires
changes in the comment line interface and IssueEvent. GitHub
has a lot of event types.

Add a generic way to represent additional event types so the full context of
issues can be seen with git issue show <number>.

Assignee should be kbenzie.

Currently labels and milestones do not support the create, read, update, delete
life cycle, this requires visiting the services website. Add support for the
following commands:

• git issue label {create,edit,show,list,delete}
• git issue milestone {create,edit,show,list,delete}

This issue should have the GitHub Support milestone.

Implement git issue list for
GitLab.

Currently the {create,edit,close,reopen} commands do not any information on
successfully completion. To find out the issue number of an newly created issue
the user must invoke git issue list. Upon success these commands should output
a message of the form:

<action> issue <number>: <url>

Add colour to <action> as seen in git issue show <number>.

Implement git issue {edit,close,reopen} for
GitLab.

Update the issue body.

Update labels, add question.

Remove question label.

List issues using the GitHub API.

Implement git issue comment for
GitLab.

Similar to git log --oneline it should be possible to display a shorthand list
of issue with git issue list --oneline just displaying issue numbers,
labels/milestones, and titles.

Currently there is not mechanism to remove the milestone or all labels if they
are set. The command line should look something like:

$ git issue edit <number> -l none -s none

Each service will likely have to implement this differently so should special
case receiving 'none' for labels and milestone in their
<Service>Issue.edit() implementation.

Currently comments can only be created, add support for editing/delete comments.
Selection of the comment to edit/delete should be performed using pick with a
short preview of the comment.

• git issue comment <number> {edit,delete}

Similar to git show --summary <ref> if should be possible to display a summary
of an issue with git issue show --summary <number> displaying the same as each
entry of git issue list.

If issue.<service>.url set for a service it is not utilised correctly and will
result in an error. This should be fixed.

Whilst it is possible to edit most/all other parameters set when creating an
issue, instead Gogs uses different routes to manipulate issue
labels.

Relates to #8.

The following warning is being reported using arrow version 0.14.5 and should be fixed.

warning: The .get() parsing method without a format string will parse more strictly in version 0.15.0.See https://github.com/crsmithdev/arrow/issues/612 for more details.

When attempting to create an issue on GitLab API v4 the following output is
produced and the issue is not created on inspection of the web interface. 200
is a very strange status code for a failure, git-issue expects 201 on
success since it's creating a resource.

$ git issue create
error: 200 OK

When performing a user search for benie on GitHub pick throws a
UnicodeEncodeError, this can be fixed by ensuring that all content passed to
it is correctly encoded.

When a GitLab issue does not have a milestone this shows up as none in git issue list and git issue show whilst with other services nothing is shown.
This is likely due to GitLab returning the string "none" in the milestone
field of the issue get response.

Currently GitLabIssueComment.url() is not implemented, this is due to not
knowing what the URL returned should be, otherwise comments are created as
expected but the git issue comment command fails with a NotImplementedError.

Implement git issue create for
GitLab.

A Gogs issue which was closed by being mentioned in a commit message is not longer able to be displayed giving the following error message.

$ git issue show 3
Traceback (most recent call last):
  File "/Users/benie/.local/bin/git-issue", line 11, in <module>
    load_entry_point('git-issue==0.3.8', 'console_scripts', 'git-issue')()
  File "/Users/benie/.local/lib/python/site-packages/git_issue/cli.py", line 507, in main
    command(get_service(), **args)
  File "/Users/benie/.local/lib/python/site-packages/git_issue/cli.py", line 355, in show
    items += issue.events()
  File "/Users/benie/.local/lib/python/site-packages/git_issue/gogs.py", line 219, in events
    'closed': 'closed'}[state], event))
KeyError: <git_issue.gogs.GogsIssueState object at 0x1114ce510>

The following error occurred on a GitLab repo.

git issue comment error: invalid issue state: all
                  ^
         <tab> pressed here

This should result in a completion list, not an error message.

The git issue browse command supports the --url to print the issues URL
instead of opening it in the browser but this option is not documented in the
manpage.

JIRA handles issue states quite differently, so far all backend support open
and closed states but JIRA can have many different states and possible
different parameters when transitioning between states which may or may not be
required.

One solution could be to add a new command:

$ git issue transition <state>

The transition command, when invoked, would prompt the user to input any
required parameters as defined by the JIRA transition screen associated with the
<state>. This has the downside of loosing out on command line completions for
the parameters.

A second approach could be to shoehorn the state transitions into the git issue {edit,close,reopen} commands. States which can be transitioned to but could be
augmented using choices given to the user with pick as is already done
to disambiguate user searches. This has the downside of not being a one-to-one
match of transitions available for an issue and possibly counter-intuitive
command names.

Third approach would be to assess GitHub projects and GitLab
boards for any commonalities between the services which might be
more instructive when implementing JIRA support.

Currently git issue list has a single filter, the issue state. Whilst this is
helpful most API's provide many more options for filtering issues and those
API's which don't filtering can be emulated easily.

Filtering should include:

• assignee
• labels
• milestone

This issue only has a title
And a body

It is possible to comment on an issue using:

$ git issue comment <issue>

It is not possible to then edit or delete that comment like:

$ git issue comment <issue> edit <comment>
$ git issue comment <issue> delete <comment>

Currently git-issue only supports storing API tokens or passwords in plain
text in .gitconfig files, this depends on the host system being trusted and
secure which is not always the case.

[Mutt][mutt] supports two kinds of config options, key = value which is stored
in plane text, and key = command | which invokes a command to get the value.
This approach is very flexible as it allows the user to choose their preferred
way of storing access tokens.

Add support to git-issue for invoking a command to get the value of
git-config options following the git style for running shell commands:

[issue "Service"]
token = !gpg --decrypt /path/to/encrypted/token

Whilst invoking a command is intended for improving security of token's any
git-issue config option should support the command syntax.

This issue should have the wontfix label.