Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate adding query support #11

Open
dmranck opened this issue Mar 1, 2017 · 3 comments
Open

Investigate adding query support #11

dmranck opened this issue Mar 1, 2017 · 3 comments

Comments

@dmranck
Copy link
Owner

dmranck commented Mar 1, 2017

Investigate adding support for querying tickets in a project based on certain parameters. For example, return all open tickets, or return all tickets assigned to a specific user.

@dmranck dmranck changed the title Investigate adding query support to ticketutil Investigate adding query support Mar 1, 2017
@dmranck
Copy link
Owner Author

dmranck commented May 25, 2018

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

@dmranck
Copy link
Owner Author

dmranck commented May 30, 2018

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 methods that are very consistent across the tools, hiding the differences and complexities of the APIs from the user and giving them one consistent way to interact with the tools.

I also feel this is slightly outside the core scope of ticketutil, which is a Create, Read, Update, Delete tool. Even within these 4 main operations, there's a lot of work to be done.

If there's a strong justification for adding this feature, I would just want to make sure it's done as consistently as possible. While I would prefer the search(**kwargs) route [1], I don't think this is practical with all the different query fields, groupings, comparison operators, etc. If we went the "jql" route [2], we'd just need to clearly document this for each tool, which does put some complexity back in the hands of the user, unfortunately...

[1] We could possibly do something general like search(**kwargs) and each module would know how to translate those kwargs into specific valid query but that way we might lose a lot of searching abilities e.g. how to specify AND, OR between specific parts of the query, grouping of parts of the query etc.
[2] The user would have to know how exactly to formulate the query based on which ticketing system they're using e.g. jql for jira

@dmranck
Copy link
Owner Author

dmranck commented Jan 30, 2019

My initial high level view of how this would work would be a function that accepts a jql query string or something similar in bugzilla and then returns the list of tickets returned from that query.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant