dmranck

Not sure how to generalize this across all 5 tools. Slightly outside the scope of CRUD as well.

More notes: It'd be a nice feature to have, but it's a hard thing to generalize across 5 tools. And I do like how the current implementation of ticketutil contains...

My initial high level view of how this would work would be a function that accepts a [jql](https://confluence.atlassian.com/jiracore/blog/2015/07/search-jira-like-a-boss-with-jql) query string or something [similar](https://blog.wikichoon.com/2014/05/invoking-bugzilla-query-url-from.html) in bugzilla and then returns the list...

Thanks for opening this issue, @mjagelka. When I worked on RedmineTicket, I mostly used my own instance of Redmine in a Docker container: https://hub.docker.com/_/redmine/. All these methods were functionally tested...

All tools support HTTP Basic authentication, while JIRA and RT also support Kerberos authentication. Look into if there are additional kinds of authentication we should be supporting in each tool.

Possibly add authentication classes instead of the current implementation of just accepting a string for kerberos and a tuple for HTTP Basic auth. Auth classes in Requests: http://docs.python-requests.org/en/master/user/authentication/ Previous idea...

Good question, it looks like this is not supported right now. Sprint-related ticket edits seem to be part of a totally different API endpoint from editing standard ticket fields: https://docs.atlassian.com/jira-software/REST/7.3.1/?_ga=2.7458353.264354863.1548882453-1905587877.1537991488#agile/1.0/sprint-moveIssuesToSprint...

Yes, that's on our list of tools to support in the near future. Thanks for the feedback!

@Akasurde If you're interested in adding support for Trac, feel free! It's in our backlog but probably won't be worked on for another month or two.