Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Mylyn/JIRA Connector"

m
m
Line 1: Line 1:
 
[[Category:Mylar]]  
 
[[Category:Mylar]]  
 +
* [[Mylar FAQ#JIRA_Connector | JIRA Connector FAQ]]
 +
* [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=Mylar&component=Jira&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit  Open task in Bugzilla]
  
== 2006-10-13 Planning Session ==
+
=== Priority JIRA web service API needs ===
  
[https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=Mylar&component=Jira&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit  Open task in Bugzilla]
+
* Retrieving available workflow actions and operations (based on issue type, status, current user etc)
 +
* Retrieving available actions for each comment (edit, delete, change visibility etc) and required metadata (i.e. list of values for selecting who can see comment)
  
== JIRA web service API needs ==
+
* Retrieving, adding and removing attachments for given issue trough the SOAP/XML-RPC API
* Service to get RPC api version (need to call this before calling anything else) - could be added to the existing getServerInfo service
+
** Attachment names/ids/etc should be present on the Issue object
** We actually need to support RPC plugin versions, not Jira versions.  Currently we just guess the rpc version based on the Jira version
+
 
* Adding and removing attachments.
+
* Retrieving, adding and removing dependencies, links and subtasks trough the SOAP/XML-RPC API
** Attachment names/ids should be present on the issue object
+
** Links, etc should be present on the Issue object
* Retrieving and adding votes.
+
 
 +
* Custom fields should be available on the Issue object
 +
 
 +
* Update time tracking info trough SOAP/XML-RPC API
 +
 
 +
* Retrieving and adding votes trough SOAP API
 
** Number of votes and whether or not the current user has voted should be present on the issue object
 
** Number of votes and whether or not the current user has voted should be present on the issue object
* Watching (CC) status of the issue given the current user (should be present on the issue)
+
 
 +
* Watch/CC status of the issue given the current user (should be present on the issue)
 
* Watch/unwatch an issue during an update by setting/unsetting the watched flag on the issue (allows us to reassign an issue, but continue to watch it with one call)
 
* Watch/unwatch an issue during an update by setting/unsetting the watched flag on the issue (allows us to reassign an issue, but continue to watch it with one call)
* Retrieving workflow actions and submitting the corresponding operations (based on an issue type, project and current status)
+
 
 +
* Retrieve issue history trough SOAP/XML-RPC API
 +
 
 +
=== Other JIRA web service API needs ===
 +
 
 +
* Service to get wiki macro details (for rich text editing and autocompletion)
 +
** Is it a block macro
 +
** Does it have parameters, if so, what values are possible
 +
 
 +
* Service to get RPC api version (need to call this before calling anything else) - could be added to the existing getServerInfo service
 +
** We actually need to support RPC plugin versions, not Jira versions.  Currently we just guess the rpc version based on the Jira version
 +
 
 
* Retrieving screen layouts given issue type, project and action (for editing custom fields on workflow transition)
 
* Retrieving screen layouts given issue type, project and action (for editing custom fields on workflow transition)
 +
 
* Submitting query/filter and only getting keys back (not issues+comments).
 
* Submitting query/filter and only getting keys back (not issues+comments).
 +
 
* Service to get issue summaries (everything but the comments) given a set of issue keys (for populating search results page at a time)
 
* Service to get issue summaries (everything but the comments) given a set of issue keys (for populating search results page at a time)
 +
 
* Service to get all server configuration at once (Projects/Components/Versions)
 
* Service to get all server configuration at once (Projects/Components/Versions)
 +
 
* Service to get server "customization" settings (is voting enabled, attachments allowed, etc...) - currently admin only
 
* Service to get server "customization" settings (is voting enabled, attachments allowed, etc...) - currently admin only
* This is needed to disable operations that are not enabled on the server
+
** This is needed to disable operations that are not enabled on the server
 +
 
 
* Service to get all 'meta' information at once (issue types, issue statuses, ProjectCategory, etc) - any configurable objects that apply across projects
 
* Service to get all 'meta' information at once (issue types, issue statuses, ProjectCategory, etc) - any configurable objects that apply across projects
 +
 
* Project object should say what category it belongs to (if any)
 
* Project object should say what category it belongs to (if any)
 +
 
* Service to search for issues - model this after the core services search method? ie. object based query
 
* Service to search for issues - model this after the core services search method? ie. object based query
 +
 
** Allow searching by voting and watch status (I don't think these are currently stored in the GenericValue object, so aren't indexed by Lucene)
 
** Allow searching by voting and watch status (I don't think these are currently stored in the GenericValue object, so aren't indexed by Lucene)
 
** Allow searches to be saved as named queries
 
** Allow searches to be saved as named queries
 +
 
* Service to search for users - like the issue search, just return IDs and let the caller get the details
 
* Service to search for users - like the issue search, just return IDs and let the caller get the details
 
* Service to search for groups
 
* Service to search for groups
* Service to get wiki macro details (for rick text editing)
+
 
** Is it a block macro
+
** Does it have parameters, if so, what values are possible
+
* Custom fields should be available on the Issue object
+
* Issue links should be available on the Issue object
+
* Service to add/remove issue links (could be done while saving the issue if they are present on that object)
+
 
* Provide all services in wrapped doc/literal format to be WS-I compliant.  Some toolkits such as XFire only support Doc/Literal web services
 
* Provide all services in wrapped doc/literal format to be WS-I compliant.  Some toolkits such as XFire only support Doc/Literal web services

Revision as of 13:41, 3 May 2007

Priority JIRA web service API needs

  • Retrieving available workflow actions and operations (based on issue type, status, current user etc)
  • Retrieving available actions for each comment (edit, delete, change visibility etc) and required metadata (i.e. list of values for selecting who can see comment)
  • Retrieving, adding and removing attachments for given issue trough the SOAP/XML-RPC API
    • Attachment names/ids/etc should be present on the Issue object
  • Retrieving, adding and removing dependencies, links and subtasks trough the SOAP/XML-RPC API
    • Links, etc should be present on the Issue object
  • Custom fields should be available on the Issue object
  • Update time tracking info trough SOAP/XML-RPC API
  • Retrieving and adding votes trough SOAP API
    • Number of votes and whether or not the current user has voted should be present on the issue object
  • Watch/CC status of the issue given the current user (should be present on the issue)
  • Watch/unwatch an issue during an update by setting/unsetting the watched flag on the issue (allows us to reassign an issue, but continue to watch it with one call)
  • Retrieve issue history trough SOAP/XML-RPC API

Other JIRA web service API needs

  • Service to get wiki macro details (for rich text editing and autocompletion)
    • Is it a block macro
    • Does it have parameters, if so, what values are possible
  • Service to get RPC api version (need to call this before calling anything else) - could be added to the existing getServerInfo service
    • We actually need to support RPC plugin versions, not Jira versions. Currently we just guess the rpc version based on the Jira version
  • Retrieving screen layouts given issue type, project and action (for editing custom fields on workflow transition)
  • Submitting query/filter and only getting keys back (not issues+comments).
  • Service to get issue summaries (everything but the comments) given a set of issue keys (for populating search results page at a time)
  • Service to get all server configuration at once (Projects/Components/Versions)
  • Service to get server "customization" settings (is voting enabled, attachments allowed, etc...) - currently admin only
    • This is needed to disable operations that are not enabled on the server
  • Service to get all 'meta' information at once (issue types, issue statuses, ProjectCategory, etc) - any configurable objects that apply across projects
  • Project object should say what category it belongs to (if any)
  • Service to search for issues - model this after the core services search method? ie. object based query
    • Allow searching by voting and watch status (I don't think these are currently stored in the GenericValue object, so aren't indexed by Lucene)
    • Allow searches to be saved as named queries
  • Service to search for users - like the issue search, just return IDs and let the caller get the details
  • Service to search for groups
  • Provide all services in wrapped doc/literal format to be WS-I compliant. Some toolkits such as XFire only support Doc/Literal web services

Back to the top