You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a QPP Engineer, so that I can interact with existing tickets in Jira, I would like FCLI be able to read a ticket from Jira and present it to me.
A possible implementation could be to have FCLI accept a ticket id and return the result, possibly in JSON format. It may be nice to be able to specify which fields to return.
Initially, my thinking was that one would send FCLI a ticket id for a "read" function and have a separate function to perform searches. The read function would accept a ticket id and return many (most) of the fields; the search function would accept a series of criteria and return ticket ids or some subset of fields.
Now, I'm thinking that they're actually one function. A ticket "read" could be a search where the ticket id == (some value) and the list of fields is (most of the fields).
To simplify and or permit expressive searching, perhaps we allow arbitrary JQL.
This is unlike allowing arbitrary SQL because:
JQL doesn't have the ability to write or update -- it can only read
requests are performed with the user's access level -- one can't "trick" the system into returning anything that the user wouldn't otherwise be able to access
when you perform a search in Jira, the resulting URL (hence, GET) includes the URL-encoded JQL -- we wouldn't be doing anything that Jira doesn't already do
The text was updated successfully, but these errors were encountered:
As a QPP Engineer, so that I can interact with existing tickets in Jira, I would like FCLI be able to read a ticket from Jira and present it to me.
A possible implementation could be to have FCLI accept a ticket id and return the result, possibly in JSON format. It may be nice to be able to specify which fields to return.
Initially, my thinking was that one would send FCLI a ticket id for a "read" function and have a separate function to perform searches. The read function would accept a ticket id and return many (most) of the fields; the search function would accept a series of criteria and return ticket ids or some subset of fields.
Now, I'm thinking that they're actually one function. A ticket "read" could be a search where the ticket id == (some value) and the list of fields is (most of the fields).
To simplify and or permit expressive searching, perhaps we allow arbitrary JQL.
This is unlike allowing arbitrary SQL because:
The text was updated successfully, but these errors were encountered: