Method and Apparatus for Performing Remote Operations in an Issue Tracking Environment

Abstract

Issues are linked to items that are external to the system installation to connect people, teams, and applications, in which users can share issues and search results with each other. Remote issue links connect issue tracking system issues to objects and pages in other instances, such as Web applications. Activity streams show events from all linked applications and third-party applications. In another embodiment, a user is allowed to copy issues from one issue tracking system instance to another. Once an application link is established between the local issue tracking system instance and another, a new issue action, remote copy, appears in a view issue page. The user is prompted to map field values by field names for the issue tracking system's built-in fields and/or to configure default values for required fields. In some embodiments, appropriate permissions are required to set the field value on the target site.

Description

BACKGROUND OF THE INVENTION

1. Technical Field

The invention relates to issue tracking systems. More particularly, the invention relates to performing remote operations in an issue tracking environment.

2. Description of the Background Art

An issue tracking system is a computer software package that manages and maintains lists of issues, as needed by an organization. Issue tracking systems are commonly used, for example, in an organization's customer support call center to create, update, and resolve reported customer issues, or even issues reported by that organization's other employees. An issue tracking system often also contains a knowledge base containing information on each customer, resolutions to common problems, and other such data.

The most common issue tracking system's design is relatively simple. A database is the main storage repository for all data. The data is managed by the business logic layer of the application. This layer gives the underlying raw data more structure and meaning, preparing it for human consumption. The now human readable data are then presented to the support technician by another software application or Web page. The end-user of the issue tracking system can create entirely new issues, read existing issues, add details to existing issues, or resolve an issue. When a user of the system makes a change, the issue tracking system records the action and who made it, and thus maintains a history of the actions taken. Each user of the system may have issues assigned to them, that is, that user is responsible for the proper resolution of that issue. This is generally presented to the user in a list format. The user may have the option of re-assigning an issue to another user, if needed. For security, an issue tracking system authenticates its users before allowing access to the systems.

Issues

Issues can have several aspects to them. Each issue in the system may have an urgency value assigned to it, based on the overall importance of that issue. Critical issues are the most severe and should be resolved in the most expedient way possible, taking precedence over all other issues. Low or zero urgency issues are minor and should be resolved as time permits. Other details of issues include the customer experiencing the issue, whether external or internal, date of submission, detailed descriptions of the problem being experienced, attempted solutions or work-arounds, and other relevant information. As previously noted, each issue maintains a history of each change.

Workflow

An example scenario is presented to demonstrate how a common issue tracking system works:

A customer service technician receives a telephone call, email, or other communication from a customer about a problem. Some applications provide a built-in messaging system and automatic error reporting from exception handling blocks.

The technician verifies that the problem is real, and not just perceived. The technician also ensures that enough information about the problem is obtained from the customer. This information generally includes the environment of the customer, when and how the issue occurs, and all other relevant circumstances.

The technician creates the issue in the system, entering all relevant data, as provided by the customer.

As work is done on that issue, the system is updated with new data by the technician. Any attempt at fixing the problem should be noted in the issue system. Ticket status most likely is changed from open to pending.

After the issue has been fully addressed, it is marked as resolved in the issue tracking system.

If the problem is not fully resolved, the ticket is reopened once the technician receives information about failure of addressing problem from the customer.

One type of issue tracking system is a project tracking environment, such as provided by the JIRA product, offered by Atlassian, which is a proprietary system that is used for bug tracking, issue tracking, and project management. A bug tracking system or defect tracking system is a software application that is designed to help keep track of reported software bugs in software development efforts. It may be regarded as a type of issue tracking system. While there are many known implementations of project tracking systems, JIRA is written in Java and uses the Pico inversion of control container, Apache OFBiz entity engine, and WebWork 1 technology stack; for Remote Procedure Calls (RPC), JIRA supports SOAP, XML-RPC, and REST.

Tracking systems, such as JIRA, are used to capture and organize issues, prioritize and take action on important issues, and allow system users to stay up-to-date with the activity going on around them. Different organizations use such systems to track different kinds of issues. Depending on how an organization is using such system, an issue could represent a software bug, a project task, a helpdesk ticket, a leave request form, etc.

Issues may cross domains, enterprises, or organizations. Unfortunately, state of the art issue tracking systems cannot link issues to items that are external to the system installation, e.g. issues that reside on external applications or system instances.

SUMMARY OF THE INVENTION

An embodiment of the invention links issues to items that are external to the system installation, e.g. issues that reside on external applications or system instances. An embodiment of the invention provides remote issue links that connect issue tracking system issues to objects and pages in other applications, such as Web applications. In another embodiment of the invention, activity streams show events from all linked applications and third-party applications. A remote link API supports contribution to the issue tracking system activity stream.

Another embodiment of the invention allows a user to copy issues from one issue tracking system site to another. In this embodiment of the invention, once an application link is established between the local issue tracking system site and another, a new issue action remote copy appears in a view issue page. The user can limit this action to a particular user group, but by default in a preferred embodiment everyone can use it. The user is prompted to map field values by field names for the issue tracking system's built-in fields and/or to configure default values for required fields. In some embodiments of the invention, appropriate permissions are required to set the field value on the target site.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a screenshot that is displayed when a user accesses an issue in an issue tracking system from a search result or from a dashboard gadget that provides access to issues according to the invention;

FIG. 2 is a screen shot that shows a remote issue link in an issue tracking system according to the invention;

FIG. 3 is a screen shot that shows a user dialog for creating a remote issue link in an issue tracking system according to the invention;

FIG. 4 is a block schematic diagram that shows an issue tracking system making a remote call to another server that is hosting a remote plugin according to the invention;

FIG. 5 is a further block schematic diagram showing an issue tracking system and a remote instance with which a remote issue link is established according to the invention;

FIG. 6 is a block schematic diagram showing an issue tracking system and a remote instance with which a remote issue copy/move operation is implemented according to the invention; and

FIG. 7 is a block schematic diagram that depicts a machine in the exemplary form of a computer system within which a set of instructions for causing the machine to perform any of the herein disclosed methodologies may be executed.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a screenshot that is displayed when a user accesses an issue in an issue tracking system from a search result or from a dashboard gadget that provides access to issues according to the invention. FIG. 1 shows an implementation of the invention in the JIRA product, discussed above, but those skilled in the art will appreciate that the invention may be implemented in many different environments.

Issues are complex. Consider the fields shown in FIG. 1, which are:

• • Project (1): The parent project to which the issue belongs.
  • Key (2): A unique identifier for this issue. The characters to the left of the hyphen represent the project to which this issue belongs.
  • Summary (3): A brief one-line summary of the issue.
  • Type (4): See below for a list of types.
  • Status (5): The stage the issue is currently at in its lifecycle (workflow).

See below for a list of statuses.

• • Priority (6): The importance of the issue in relation to other issues. See below for a list of priorities.
  • Resolution (7): A record of the issue's resolution, if the issue has been resolved or closed. See below for a list of resolutions.
  • Affects Version(s) (if applicable) (8): Project version(s) for which the issue is or was manifesting.
  • Fix Version(s) (if applicable) (9): Project version(s) in which the issue was, or is to be, fixed.
  • Component(s) (if applicable) (10): Project component(s) to which this issue relates.
  • Labels(s) (if applicable) (11): Labels to which this issue relates.
  • Environment (if applicable) (12): The hardware or software environment to which the issue relates.
  • Description (13): A detailed description of the issue.
  • Links (14): A list of links to related issues. Strikethrough text, like this, indicates that an issue has been resolved.
  • Assignee (15): The person to whom the issue is currently assigned.
  • Reporter (16): The person who entered the issue into the system.
  • Votes (17): The number shown in brackets indicates how many votes this issue has.
  • Watchers (18): The number shown in brackets indicates how many people who are watching this issue.
  • Due (if applicable) (19): The date by which this issue is scheduled to be completed.
  • Created (20): The time and date on which this issue was entered into the issue tracking system.
  • Updated (21): The time and date on which this issue was last edited.
  • Resolved (22): The time and date on which this issue was resolved.
  • Estimate (23): The Original Estimate of the total amount of time required to resolve the issue, as estimated when the issue was created.
  • Remaining (24): The Remaining Estimate, i.e. the current estimate of the remaining amount of time required to resolve the issue.
  • Logged (25): The sum of the Time Spent from each of the individual work logs for this issue.

Some of the more important fields, i.e. Type, Priority, Status, and Resolution, are described as follows:

Issue Type

An issue tracking system can be used to track many different types of issues. Some of the more common types of issues are listed below.

• • Bug: A problem which impairs or prevents the functions of the product.
  • Improvement: An enhancement to an existing feature.
  • New Feature: A new feature of the product.
  • Task: A task that needs to be done.
  • Custom Issue: A custom issue type, as defined by an organization if required.

Priority

An issue's priority indicates its relative importance. The default priorities are listed below; note that both the priorities and their meanings can be customized by an administrator to suit an organization.

• • Blocker: Highest priority. Indicates that this issue takes precedence over all others.
  • Critical: Indicates that this issue is causing a problem and requires urgent attention.
  • Major: Indicates that this issue has a significant impact.
  • Minor: Indicates that this issue has a relatively minor impact.
  • Trivial: Lowest priority.

Status

Each issue has a status, which indicates where the issue currently is in its lifecycle (workflow). An issue starts as being Open, generally progresses to Resolved, and then Closed or, depending on circumstances, it may progress to other statuses.

• • Open: This issue is in the initial Open state, ready for the assignee to start work on it.
  • In Progress: This issue is being actively worked on at the moment by the assignee.
  • Resolved: A Resolution has been identified or implemented, and this issue is awaiting verification by the reporter. From here, issues are either Reopened or are Closed.
  • Reopened: This issue was once Resolved or Closed, but is now being re-examined. For example, an issue with a Resolution of Cannot Reproduce is Reopened when more information becomes available and the issue becomes reproducible. From here, issues are either marked In Progress, Resolved or Closed.
  • Closed: This issue is complete.

Resolution

An issue can be resolved in many ways, only one of them being Fixed. Some default resolutions are listed below.

• • Fixed: A fix for this issue has been implemented.
  • Won't Fix: This issue is not to be fixed, e.g. it may no longer be relevant.
  • Duplicate: This issue is a duplicate of an existing issue.
  • Incomplete: There is not enough information to work on this issue.
  • Cannot Reproduce: This issue could not be reproduced at this time, or not enough information was available to reproduce the issue. If more information becomes available, please reopen the issue.

Note that once an issue has been resolved, i.e. the issue's Resolution field is not empty, textual references to that issue show the key in strikethrough text.

Remote Issue Links

An embodiment of the invention links issues to items that are external to the system installation, e.g. issues that reside on external applications or remote instances. Thus, the invention provides a technique that connects people, teams and applications, in which users can share issues and search results with each other. An embodiment of the invention provides remote issue links that connect issue tracking system issues to objects and pages in other instances, such as Web applications. Activity streams show events from all linked applications and third-party applications. The remote link API supports contribution to the issue tracking system activity stream.

The herein disclosed remote issue links invention provides a powerful tool for linking issues to items that are external to an issue tracking system installation, i.e. issues that reside on external instances and applications. An embodiment of the invention uses a Java and REST API to add these links to the issue tracking system. In this way, users can add an issue link from one instance of an issue tracking system issue at one site to an issue on another instance of an issue tracking system or application at another site, including reciprocal links between these issues. Users can search for a page within a separate application from an issue within the issue tracking system and add an issue link to that page. Thus, in an embodiment of the invention users can add an issue link from an issue tracking system issue to any Web page URL, such as a page of documentation, a technical note, or any other page on another Web site.

The herein disclosed remote issue links invention offers a simple but powerful way to integrate an application with an issue tracking system. For example, if there is an object in an application that relates to an issue tracking system ticket, a user can link that object to that issue using such remote issue links. For example, a support ticket is created for an issue raised by a customer in a help desk system, and the bug that causes that issue is being tracked in an issue tracking system. In an embodiment of the invention, a single API call allows a link to be created in that issue pointing to the support ticket. Thus, a user can provide an icon, a title, a summary, even a status icon for the remote object.

FIG. 2 is a screen shot that shows a remote issue link in an issue tracking system according to the invention. In FIG. 2, an exemplary, but non-limiting, example of an issue “relates to” another bug on the same server, “is detailed by” a task on a different server, “links to” a Website, and appears on a “Wiki page.” The view shown in FIG. 2 is provided for purposes of example and those skilled in the art will appreciate the details provided can be expanded or collapsed as necessary to describe all aspects of the issue and to define all remote links.

FIG. 3 is a screen shot that shows a user dialog for creating a remote issue link in an issue tracking system according to the invention. As shown in FIG. 3, a user enters a URL as the destination for the remote issue link and any authorization the may be required. Various REST actions are available to the user, as well as fields into which the user may enter files, content type, comments, and the like. Those skilled in the art will appreciate that, while FIG. 3 shows user creation of remote links via the REST API, the invention may be practiced with other user interfaces, for example remote links may be created using a Web user interface.

TABLE 1
Fields for Remote Issue Links
Field	Required	JSON Key	Description	Impact if blank
GlobalID		globalid	A globally unique identifier which uniquely	You will not be able to
			identifies the remote application and the	update or delete the
			remote object within the remote system. The	link unless you know
			maximum length is 255 characters.	the internal ID of the
				link.
Relationship		relationship	Relationship between the remote object and	“links to” used in Ul
			the JIRA issue. This can be a verb or a
			noun. It is used to group together links in the
			Ul.
Object
URL		object.url	A hyperlink to the object in the remote	N/A
			system.
Title		object.title	The title of the remote object.	N/A
Summary		object.summary	Textual summary of the remote object.	No text in Ul
Icon URL		object.icon.url16×16	A 16 × 16 icon representing the type of the	Default link icon will be
			object in the remote system.	used in Ul
Icon Title		object.icon.title	Text for the tooltip of the main icon	Only Application
			describing the type of the object in the	Name is used in tootip
			remote system. The Icon Title
			and Application Name are combined to form
			the tootip.
Resolved		object.status.resolved	Whether the remote object is “resolved”	Title text will appear in
			(value is “true”) or “unresolved” (value is	normal font in Ul
			“false”). This value will only make sense
			where the remote object is something that is
			resolvable (eg. an issue, support ticket, etc).
			it will not make sense for things like wiki
			pages.
			If Resolved is “true”, the link to the issue will
			have a be in a strikethrough font.
Status Icon		object.status.icon.url16×16	A 16 × 16 icon representing the status of the	No status icon in Ul
URL			remote object.
Status Icon		object.status.icon.title	Textual description of the status for the	Status icon doesn't
Text			tooltip of the the status icon. Not used	have a tooltip
			if Status icon URL is blank.
Field	Remote JIRA Example
Global ID	appLinkId=123&issueId=123
Relationship	duplicates
URL	http://mycompany.com/jira/CWD-111
Title	CWD-111
Summary	Support nested group
Icon URL	http://mycompany.com/jira/bug.png
Icon Title	Bug - A problem which impairs or prevents the functions of the product
Resolved	false
Status Icon URL	https://www.mycompany.com/jira/images/icons/newfeature.gif
Status Icon Text	Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either
	reopened, or are closed.
Application Name	My Company JIRA
Application Type	com.atlassian.jira
indicates data missing or illegible when filed

In an embodiment of the invention, a remote issue link has the following construction:

public RemotelssueLink(Long id,

• • Long issueId,
  • String globalId,
  • String title,
  • String summary,
  • String url,
  • String IconUrl,
  • String iconTitle,
  • String relationship,
  • Boolean resolved,
  • String statusIconUrl,
  • String statusIconTitle,
  • String statusIconLink,
  • String applicationType,
  • String applicationName)

The following details the various elements of the above construction:

getId

public Long getId( )

Returns the id of the link. This is used to refer to a link when updating and deleting.

Returns: the id of the link

getIssueId

public Long getIssueId( )

Returns the id of the issue we are linking with.

Returns: the id of the issue we are linking with

getGloballd

public String getGloballd( )

Returns a String which uniquely identifies the object in the remote application.

This value must be unique across all remote objects in all remote applications. The maximum length of this field is 255 characters. For simplicity, this could simply be the URL.

This value is not displayed in the user interface. Including in this field any values that are needed by a renderer plugin is suggested, for example the application URL and remote object identifier to make REST calls.

For example: “url=http://www.myapplication.com&ticketid=12345”

Returns: a String which uniquely identifies the object in the remote application

getTitle

public String getTitle( )

Returns a String to identify the remote object. This is shown as the text for the URL in the user interface. For example: an issue key, a page title, a helpdesk ticket number

Returns: a String to identify the remote object

getSummary

public String getSummary( )

Returns a summary of the remote object. This is shown after the title in the user interface. For example: an issue summary, a helpdesk ticket title

Returns: a summary of the remote object

getUrl

public String getUrl( )

Returns a url to the object in the remote application. For example: a page URL

Returns: a URL to the object in the remote application

getIconUrl

public String getIconUrl( )

Returns a URL for an icon to represent the remote object. The size of the icon should be 16×16 pixels.

For example: http://mycompany.com/jira/images/icons/bug.png

Returns: a URL for an icon to represent the remote object

getIconTitle

public String geticonTitle( )

Returns the tool tip text for the icon. The applicationName is prepended to this value to form the icon tool tip text.

For example: “Bug—A problem which impairs or prevents the functions of the product”

Returns: the tool tip text for the icon

getRelationship

public String getRelationship( )

Returns a String which describes the relationship between the issue and the remote object.

For example: “relates to”, “is mentioned in”, “links to”. It could even be a simple noun, such as “Test Case”.

Returns: a String which describes the relationship between the issue and the remote object

isResolved

public Boolean isResolved( )

Returns a Boolean to indicate whether the remote object is resolved or not. If the value is true, it is resolved, and if the value is false, it is unresolved. This value only makes sense where the remote object is something that is resolvable, e.g. an issue, support ticket, etc. It does not make sense for things such as wiki pages. In that case, the value should be null. If the value is true, the remote issue link be shown in a strikethrough font in the user interface.

Returns: a Boolean to indicate whether the remote object is resolved or not

getStatusIconUrl

public String getStatusIconUrl( )

Returns a URL for an icon representing the status of the remote object. The size of the icon should be 16×16 pixels. This icon is shown next to the summary in the user interface, and is right justified. This icon does not have to strictly represent a status, and may instead represent some secondary information about the link.

For example: the status of an issue, the author of a test case

Returns: a URL for an icon representing the status of the remote object

getStatusIconTitle

public String getStatusIconTitle( )

Returns the tool tip text for the status icon. If null, no tool tip text is shown. This value is not used if the statusIconUrl is null.

Returns: the tool tip text for the status icon

getStatusIconLink

public String getStatusIconLink( )

Returns a hyperlink for the status icon. If null, no hyperlink is shown. This value is not used if the statusIconUrl is null.

Returns: a hyperlink for the status icon

getApplicationType

public String getApplicationType( )

Returns the type of remote application that is linked with. This should be the product name, namespaced with the product company. This value is not displayed in the user interface. Links are grouped based on the applicationType and applicationName in the user interface. Rendering plugins can register to render a certain type of application. It is not possible to use a plugin to render links without an applicationType.

For example: “com.atlassian.confluence”, “com.mycompany.myproduct”

Returns: the type of remote application that is linked with

getApplicationName

public String getApplicationName( )

Returns the human-readable name of the remote application instance that contains the remote object. Links are grouped based on the applicationType and applicationName in the user interface. The applicationName is prepended to the iconTitle to form the icon tool tip text.

For example: “My Company's Confluence”, “HR JIRA”, “Helpdesk JIRA”

Returns: the human-readable name of the remote application instance that contains the remote object

REST API

An embodiment of the invention uses a REST API in connection with remote issue links. Representational State Transfer (REST) is a known style of software architecture for distributed systems such as the World Wide Web. As such, REST itself is not discussed in greater detail herein. In some embodiments of the invention there are two required fields for creating a link to a remote object: a URL and a link title.

POST http://localhost:8090/jira/rest/api/latest/issue/TST-1/remotelink
{
  “object”: {
  “url”:“,
  “title”:“Crazy customer support issue”
  }
}
Returns the successful response:
{ “self”:“http://localhost:8090/jira/rest/api/latest/issue/TST-1/remotelink/100”,
“id”:100} |
{
  “self”:“http://localhost:8090/jira/rest/api/latest/issue/TST-1/remotelink/100”,
  “id”:100
}

When a link is created, globalId: can optionally be supplied, which is an identifier that uniquely identifies the remote application and the remote object within the remote system. This globally unique identifier can be used to update or delete existing links on an issue.

POST http://localhost:8090/jira/rest/api/latest/issue/TST-1/remotelink
{
“globalId”: “system=http://www.mycompany.com/support&id=1”,
“object”: {
“url”:“http://www.mycompany.com/support?id=1”,
“title”:“Crazy customer support issue (RESOLVED)”
}
}

If a remote link on the issue exists with the same URL, the remote link is updated. Otherwise it is created. The update replaces all existing fields with the new values. Fields not present in the request are interpreted as having a null value.

Implementation

Because issue tracking systems are complex, as are the data structures that underlie them, as can be seen from the discussion above, the implementation of a remote issue link in accordance with the invention is not trivial. For example, the issue tracking system may be required to display a link, but it is not necessarily able to know immediately how to display it.

Consider FIG. 4, which is a block schematic diagram that shows an issue tracking system making a remote call via REST 30 and JAVA 31 via a communications path 35 to another server 32 that is hosting a remote plugin 33. The call follows appropriate links 34 at the remote server and returns sanitized HTML and JavaScript to the issue tracking system, which then renders this information inline.

In embodiments of the invention, the following approach can be used for the creation of the remote link. An external system injects the remote link details into an instance of the issue tracking system using the remote link REST API. In this case, the external system establishes the relationship between the remote object, i.e. the object in the external system, and an issue in the instance of the issue tracking system.

In alternative embodiments of the invention, the following approach can be used for the creation of a remote link. From the context of an issue in the issue tracking system, the user searches the remote system and selects a remote object to be linked to the current issue.

In embodiments of the invention, the following occurs for the display of remote link details on the View Issue page:

• • Determine the type, T, of the remote link being displayed on the View Issue page.
  • If there is a rendering plugin associated with T, then execute the rendering logic in that plugin. There is no limit to what the rendering plugin can do when displaying a remote link. Typically, rendering plugins connect with the remote system in real time to collect all of the information necessary to render the remote link completely. Such remote system communication typically uses a REST protocol. Sanitized markup is either returned from the remote system or a markup is assembled by the rendering plugin using JSON data returned from the remote system.
  • If a rendering plugin is not associated with T, then execute the default rendering plugin. The default behavior displays all of the information stored within the issue tracking system about the remote link. In contrast to a custom rendering plugin, the default behavior does not attempt to contact the remote system while displaying the remote link.

In embodiments of the invention, custom rendering plugins can also make permissioning and security decisions, i.e. when they contact the remote system, they can use the user context to decide what amount of information should be rendered. If, for example, the current JIRA user does not have permission to see the remote object or page, the custom renderer can choose to display information which indicates that the user does not have permissions.

Although other protocols may be used in various embodiments of the invention, an embodiment of the invention uses REST and/or HTTP for such calls. For example, FIG. 5 shows an instance of an issue tracking system 40 in which a View Issue page 41 is displayed to a user. In this example, such page can perform calculations and/or look at linked issues and dependent linked issues to determine, e.g. their start dates. In this example, the View Issue page shows this because start dates are necessarily shown in issue links. The exemplary View Issue page includes a panel that shows such dependencies.

In this example, the outbound protocol is HTTP. A remote link type rendering plugin 42 (discussed above in connection with FIG. 4) at the issue tracking system requests Web content from a remote instance 45/46, for example within execution of an issue in the form of an XML file 43 which contains one or more URLs 44 that require remote content, i.e. the remote issue content of the remote issue link.

The structure or implementation details of the remote applications and/or systems with which the issue tracking system communicates when remote links are displayed is not relevant. As long as the remote system has an API that the issue tracking system can communicate with while displaying the remote links, the system operates as desired.

The sophistication of the information that is displayed in the remote link section on the View Issue page, e.g. the derived or calculated information, is a function of what the remote system API can provide. In such case, a remote plugin 47 might have to make five REST calls to get the start dates of all of the dependent issues. Thus, an embodiment of the invention is concerned with providing a set of APIs with which a remote plugin can quickly get the information needed by the issue tracking system and then send a response back to the issue tracking system that is then rendered inside the View Issue page. In this regard, an issue may be thought of as an object tree, in which there are the main issue details at a top level, and then underneath that there might be a list of fixed versions, e.g. versions that might have a list of issue links. There is also a list of comments and a list of history. The REST request can ask for these items from the remote instance 46. For example, a comment has an author, an issue link has another issue linked to it.

One aspect of the invention shapes the data that is returned for the request, for example to manage size of payload and/or chattiness of the interaction. However, another application that is accessing the issue tracking system may know what it wants to show to its end user, e.g. a list of reported issues or a chart showing the user's progress. To accomplish such use case, the remote instance knows what data it needs, and so it formulates a query. The remote instance could replicate the issue tracking system's reporting functionality in some way. But often the remote instance has a specific purpose and requires a very specific view.

In an issue tracking system there is a client application that connects a user to an issue tracking system server. Embodiments of the invention use the REST API to show the same information as that shown in the issue tracking system, but remotely, e.g. in a Windows application. This requires flexible use of the issue tracking system API where, depending on what the user requests, different results can be returned. This is especially a problem for applications that are hard-coded for a specific use case with a single view.

In embodiments of the invention, a query defines two things: the substance of the query, i.e. what the user is looking for; and the range of information that must be returned to satisfy the user once an answer is found to the query. For example, a user can apply the same JQL expression to identify both a set of issues and the actual pieces of information that are to be returned. In embodiments of the invention, the issue tracking system knows that when it gets the query to look for the requested information but, with regard to all of the information that is available, only particular pieces of that information need to be returned. A serialization engine within the issue tracking system takes an object view of the issue and flattens it out into JavaScript Object Notation (JSON).

When the query is processed, it may be determined that the user only wants a subset of the data about the issues that match the JQL. Thus, in the query there is an instruction to the issue tracking system that tells it how to report the query back.

There is a set of options where the user can specify the list of desired fields. This shapes the information returned to satisfy the query. At the machine level a decision is made as to the form in which the information is to be reported back. The form is always the same, while REST API is purely a data API, i.e. a query interface that a remote system can use to get information out, all decisions as to form are made in the remote application. The issue tracking system has no decision in this process, but receives instructions from the remote instance for specific information, and the issue tracking system sends back exactly what is requested.

The foregoing discussion concerns the point that, with the issue tracking system REST API, clients or consumers can query for issue data using a very flexible query language (JQL) and can control the shape of the data that is returned. This allows clients to make optimization decisions, such as chattiness versus amount of data. In embodiments of the invention, the API provides very fine grain control of the data returned by the issue tracking system. Typically, this significantly reduces the implementation complexity on the client side and makes the client more robust because it only needs to know about subsets of the object tree that can be provided by the issue tracking system REST API.

One way to represent the way the data shape can be controlled is by drawing a tree structure and highlighting the branches of the tree that are included in the data returned to a client given a particular request. In embodiments of the invention, JSON is a naturally hierarchical data representation.

It should be appreciated that the REST API is not purely a data API. It also includes a command paradigm where, if the appropriate HTTP verb is used (POST, DELETE), data within the issue tracking system can be created, updated, or deleted.

Remote Issue Copying

Another embodiment of the invention allows a user to copy issues from one issue tracking system site to another. In this embodiment of the invention, once an application link is established (see the discussion below) between the local issue tracking system site and another, a new issue action, Remote Copy, appears in a view issue page. The user can limit this action to a particular user group, but by default in a preferred embodiment everyone can use it. The user is prompted to map field values by field names for the issue tracking system's built-in fields and/or to configure default values for required fields. In some embodiments of the invention, appropriate permissions are required to set the field value on the target site.

FIG. 6 is a block schematic diagram showing an issue tracking system and a remote instance with which a remote issue copy/move operation is implemented according to the invention. In this example, there are two issue tracking system instances 50, 53. This embodiment of the invention allows a user to copy an issue from one instance to another. Applications of this aspect of the invention include customer-facing systems in which customers submit issues, and where there is a separate instance for that purpose and for security reasons; and there is an internal instance, e.g. what the internal developers work on. Instead of an issue-collector approach. where the instances directly interact to execute queries for issues, this embodiment of the invention provides a system for, e.g. collaborating with customers, and in which issues are received from an external issue tracking system, e.g. a public bug-tracker to which customers submit bugs. Such bugs can be copied into an internal instance using this copy and move function.

This embodiment of the invention takes into account the fact that there may be two very different schemas for the two different projects which reside at separate instances. They may not have overlapping fields. One may have a subset of the required fields. See, for example the issues 55, 56 in FIG. 6, where one issue 55 has fields A, B, and C and the other issue 56 has fields C. D, and E. Each instance is missing two fields that should be filled in to create the issue in the other project. The user needs to be able to fill those in. The system must be able to report these errors. There must be flexibility in terms of whether attachments and all the comments get copied over.

In FIG. 6, each instance has corresponding application links 51, 54. This provides a way for connecting two systems so that they have a secure or trusted, or untrusted and authenticated, connection with each other. The remote system provides a description of its requirements to create an issue, and the local system that is trying to push, move, or copy the issue to the other system looks at description, realizes where the mismatch is, and then either sensibly defaults to some behavior that can be successful or requires the user to get involved to make a decision. A first part of this is the self-description language of the remote system or the local instance that is remote, and a second part is the ability of the first instance to interpret this description and figure out how to adapt it to local requirements.

In an embodiment of the invention, the local instance of the issue tracking system looks at the remote instance for a particular item, for example, and the remote system identifies how it handles this particular item, e.g. the fields that are used by the remote instance. Then the local instance looks internally against what the remote instance required to determine if the local instance can either compensate for the differences or if it needs to send an alert to bring in a human intervention. For example, if there are fields that are not filled in in the remote instance, then there are defaults, or they are not required because they can be dropped.

There is an API call within the issue tracking system REST API that supplies metadata about a given issue type within a given project context. Among other things, this metadata includes which fields are required, the possible values that “select list” type fields can take, and permissions on who can create issues. The “source” issue tracking system instance uses this REST call to make decisions about which fields can be copied to the “destination” issue tracking system instance unchanged and which fields require human intervention.

With regard to the architecture shown in FIG. 6, there are at least two scenarios.

Scenario 1: Trusted apps where there is a single user. This example assumes that the user names match in both the local instance and the remote instance.

Scenario 2: An OAuth situation. This occurs where one system wants to use information from another system, but it first asks for the user's permission. The first step of giving permission is the user identifying himself. As part of establishing that the user is authenticated, the user who is interacting with a local instance may try to do something with the remote instance, after which the user is advised that he needs to authenticate with the remote instance. If the user is already logged into the remote instance, the user is advised that the local instance wants permission to provide information about the user in the remote instance. If the user is not logged in, he is prompted to log in, thus identifying himself in the remote instance. There is typically no persistent relationship stored between the two instances regarding the user's appearance at each instance, but the user is allowed to authorize the exchange of information between the two instances. The application links establishes authenticated, remote interactions between applications. A successful authentication and authorization results in issuance of a token that can be used for subsequent interactions between the two systems. This token typically has an expiry date.

In this example, if a user wants to copy and move something, the first step is to determine if the user is permitted to do so, as noted in the two scenarios above. In an embodiment of the invention, an administrator sets up the application links. If the user is set up as trusted, then the user never notices anything because he has permission to proceed immediately. If the user is set up on an OAuth system, then there is human intervention where the user, while in one instance, gives himself permission to act as himself on the other instance. Once this is done, the system looks at what is being copied. The View Issue page is refreshed and the user sees the issue, e.g. in an issue bundle, and the issue can be moved or copied, for example via a drag-and-drop user interface tool.

The instance of the user who wants to perform the action, i.e. at the local instance, asks the remote instance for its capabilities, i.e. it asks the remote instance what is needed, what are requirements. Once a user has authenticated with the remote instance, the user must first choose the destination project for the issue to be copied and/or moved. It is the issue type and/or project combination that allows the destination issue tracking system instance to describe its requirements fully for successful issue creation to the source issue tracking system instance. The local instance receives the requirements from the remote instance and then, as the instance is trying to copy and/or move an issue, provides information back to the user: “successful,” “need more information,” “just not possible; you don't have permission.” Those are all three possible outcomes: automatically possible; possible with a little bit of manual intervention; and then impossible because the user does not have permission to create issues on that remote project. This may be inherent in a particular issue that is at the remote instance, based on issue type.

In one embodiment of the invention, the remote instance gets a list of requirements from the local instance and compares these requirements to what it needs locally; and it either meets those requirements or it does not. One of the first steps when trying to perform a remote copy is to pick a destination for that issue in the remote instance, both in terms of the project and issue type. In some embodiments of the invention, the remote instance can tell the local instance what its requirements are. For example, suppose that the remote instance has five requirements: three are mandatory and two are optional. It looks to see what is coming over from the local instance and sees that the three mandatory requirements are present, so it automatically accepts the issue. But, if one of the mandatory requirements is missing, it does not automatically accept the issue; and if there are, for example, three extra items, it does not care and merely drops them, but otherwise accepts the issue.

In embodiments of the invention, both move and copy are provided. Moving the original means that the item is being relocated; copying the original means that the item stays in its original place and there is a copy of it at another location. In the case of a move, there is not an automatic defaulted copy in the case of loss of data. If there might be a loss of data due to incompatibilities between the source and target instance, i.e. one or more fields may not be present at the destination instance, then the system warns the user that these fields are missing from the destination instance, and a notification is sent to the user to let the user decide to proceed or not. Further, in embodiments of the invention a copy operation which copies an issue to a destination issue tracking system instance also establishes a remote issue link between both copies of the issue.

OTHER EMBODIMENTS

Other embodiments of the inventive remote linking functionality disclosed herein include the notion of linking with intent. That is, when two issues are linked in a way that designates them to be copies, then actions taken on one issue can affect the copy of the issue in the remote instance. Note, this is not restricted to just two copies of an issue. Some example use cases include:

• • Keeping comments in sync between the copies of the issue.
  • When one copy of an issue goes through a workflow transition, then other copies of the issue may go through the same transition or some equivalent transition. Thus, the status of the copies of an issue is kept in sync.
  • When some change is made to an issue, then that change event is broadcast to all instances that have a copy of the issue. Those events can be fed into the notification systems of each instance and the appropriate notifications can be generated.
  • Change events could also be used to build a distributed Lucene index and search library of issues. This allows generation of richer reports on a network of issue copies that reside across a set of issue tracking system instances.

Computer Implementation

FIG. 7 is a block schematic diagram that depicts a machine in the exemplary form of a computer system 1600 within which a set of instructions for causing the machine to perform any of the herein disclosed methodologies may be executed. In alternative embodiments, the machine may comprise or include a network router, a network switch, a network bridge, personal digital assistant, a cellular telephone, a Web appliance or any machine capable of executing or transmitting a sequence of instructions that specify actions to be taken.

The computer system 1600 includes a processor 1602, a main memory 1604 and a static memory 1606, which communicate with each other via a bus 1608. The computer system 1600 may further include a display unit 1610, for example, a liquid crystal display (LCD) or a cathode ray tube (CRT). The computer system 1600 also includes an alphanumeric input device 1612, for example, a keyboard; a cursor control device 1614, for example, a mouse; a disk drive unit 1616, a signal generation device 1618, for example, a speaker, and a network interface device 1628.

The disk drive unit 1616 includes a machine-readable medium 1624 on which is stored a set of executable instructions, i.e. software, 1626 embodying any one, or all, of the methodologies described herein below. The software 1626 is also shown to reside, completely or at least partially, within the main memory 1604 and/or within the processor 1602. The software 1626 may further be transmitted or received over a network 1630 by means of a network interface device 1628.

In contrast to the system 1600 discussed above, a different embodiment uses logic circuitry instead of computer-executed instructions to implement processing entities. Depending upon the particular requirements of the application in the areas of speed, expense, tooling costs, and the like, this logic may be implemented by constructing an application-specific integrated circuit (ASIC) having thousands of tiny integrated transistors. Such an ASIC may be implemented with CMOS (complementary metal oxide semiconductor), TTL (transistor-transistor logic), VLSI (very large systems integration), or another suitable construction. Other alternatives include a digital signal processing chip (DSP), discrete circuitry (such as resistors, capacitors, diodes, inductors, and transistors), field programmable gate array (FPGA), programmable logic array (PLA), programmable logic device (PLD), and the like.

It is to be understood that embodiments may be used as or to support software programs or software modules executed upon some form of processing core (such as the CPU of a computer) or otherwise implemented or realized upon or within a machine or computer readable medium. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine, e.g. a computer. For example, a machine readable medium includes read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals, for example, carrier waves, infrared signals, digital signals, etc.; or any other type of media suitable for storing or transmitting information.

Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. For example, embodiments of the invention allow the user to create remote issue links between the original and the copy.

Accordingly, the invention should only be limited by the Claims included below.

Claims

1. A computer implemented method for performing remote operations in an issue tracking environment, comprising: a processor creating at least one link between issues in a local issue tracking system instance to objects and pages in at least one other, remote instance; andsaid processor using at least the following two fields for creating said link to said remote object: a URL and a link title.

2. The method of claim 1, wherein said remote instance hosts a remote plugin.

3. The method of claim 1, further comprising: said processor creating said at least one link pursuant to user execution of a query for at least one page within a separate application in said at least one other, remote instance from an issue within said local issue tracking system instance;wherein said query comprises a request for specific information regarding said issue and a form in which said information is to be reported back;said remote instance sending instructions to said local instance regarding the form for said specific information; andsaid local instance sending said information to said remote instance in the requested form.

4. The method of claim 1, wherein an issue comprises any of the following fields: project, key, summary, type, status, priority, resolution, affects version, fix version, component, labels, environment, description, links, assignee, reporter, votes, watchers, due, created, updated, resolved, estimate, remaining, and logged.

5. The method of claim 1, wherein an issue type comprises any of: a bug, an improvement, a new feature, a task, and a custom issue.

6. The method of claim 1, wherein issue priority comprises any of: blocker, critical, major, minor, and trivial.

7. The method of claim 1, wherein issue status comprises any of: open, in progress, resolved, reopened, and closed.

8. The method of claim 1, wherein issue resolution comprises any of: fixed, won't fix, duplicate, incomplete, and cannot reproduce.

9. The method of claim 1, further comprising: said processor providing at least one activity stream that shows events from all linked applications and third-party applications.

10. The method of claim 2, further comprising: said processor using a Java and REST API to add links to said issue tracking system in connection with said remote plugin.

11. The method of claim 1, further comprising: said processor providing a user dialog for creating said at least one link, said dialog comprising a field for entering a URL as a destination for said link.

12. The method of claim 1, further comprising: said processor providing a user dialog for searching the remote instance and selecting objects from the remote instance;wherein an underlying URL for the remote object is not known to the user and is constructed.

13. The method of claim 1, wherein said links comprise any of the following fields: a globally unique identifier which uniquely identifies a remote application and a remote object within said remote instance;a relationship between the remote object and the local instance issue;a hyperlink to the remote object;a title of the remote object;a textual summary of the remote object;an iconic representation of the type of object in the remote instance;text for a tooltip of an icon describing a type of object in the remote instance;an indication of whether the remote object is resolved;an iconic representation of status; anda textual description of the status for a tooltip of a status icon.

14. The method of claim 12, wherein said at least one link has the following construction: public RemotelssueLink(Long id, Long issueId,String globalId,String title,String summary,String url,String IconUrl,String iconTitle,String relationship,Boolean resolved,String statusIconUrl,String statusIconTitle,String statusIconLink,String applicationType,String applicationName).

15. The method of claim 1, further comprising: when a link is created, said processor creating a global identifier that uniquely identifies the remote application and the remote object within the remote instance.

16. The method of claim 1, wherein when a link on an issue exists with a same URL, said link is updated; otherwise said link is created; wherein said update replaces all existing fields with new values; andwherein fields that are not present in a request are interpreted as having a null value.

17. The method of claim 1, further comprising: said processor displaying a View Issue page to a user.

18. The method of claim 17, further comprising: a plugin at said local instance requesting content from said remote instance; andsaid remote plugin sending a response back to said local instance in a format that can then be rendered inside said View Issue page.

19. The method of claim 1, further comprising: a serialization engine for flattening an object view of an issue into JavaScript Object Notation (JSON).

20. A computer implemented method for copying and moving issues between issue tracking system instances, comprising: a processor establishing an application link between a first issue tracking system instance and a second issue tracking system instance;said processor creating a remote copy action in a view issue dialog;said processor prompting a user to map field values by field names for said target issue tracking system instance and, as required, to configure default values for required fields; andsaid processor effecting any of a copy and move action for an issue, wherein said first issue tracking system instance and second issue tracking system instance comprise either of a source instance and a target instance which each have different schemas and different projects.

21. The method of claim 20, further comprising: said processor prompting a user to select a destination project and issue type.

22. The method of claim 20, further comprising: said processor requiring permissions to set a field value on said target issue tracking system instance.

23. The method of claim 20, wherein said source instance and said target instance do not have overlapping fields; wherein one of said source instance and said target instance has a subset of the required fields;said processor issuing a notification prior to effecting a move of copy operation if any required fields are missing.

24. The method of claim 20, further comprising: said source instance system requesting a description of said target instance's requirements to create an issue;said target instance, pursuant to pushing, moving, or copying said issue, identifying areas of mismatch regarding said source instance requirements; andbased upon said areas of mismatch, said target instance either defaulting to a locally compliant format or requiring user input.

25. The method of claim 24, further comprising: said source instance implementing a self-description language that describes its requirements; andsaid target instance interpreting said description and adapting said issue to said source instance requirements.

26. The method of claim 25, further comprising: said target instance looking at said source instance for a particular issue;said source instance identifying fields that are used at said source instance for said issue;said target instance identifying those internal requirements versus requirements of said source instance that are necessary for said target instance and either compensating for differences between requirements of said target instance and said source instance or sending an alert for intervention.

27. The method of claim 20, wherein user names match in both the target instance and the source instance.

28. The method of claim 20, further comprising: said processor using OAuth to create application links and establish authenticated, remote interactions between said target instance and said source instance.

29. The method of claim 20, further comprising: said processor effecting any of three outcomes for a copy or move operation, said outcomes comprising automatically possible, possible with a little bit of manual intervention, and impossible because the user does not have permission to create issues on a remote instance.

30. The method of claim 20, further comprising: pursuant to performing a remote copy, selecting a destination for an issue in said target instance with regard to both a target project and an issue type; andsaid target instance informing said source instance regarding said target instance requirements.

31. The method of claim 20, wherein a move operation relocates an original issue; wherein a copy operation leaves the original item in its original place and makes a copy at another location; andwherein an automatic defaulted copy is not performed for a move operation in the case of loss of data due to incompatibilities between the source and target instance.

32. The method of claim 20, wherein a copy operation which copies an issue to a destination issue tracking system instance also establishes a remote issue link between both copies of the issue.

33. The method of claim 20, wherein when two issues are linked in a way that designates them to be copies, then actions taken on one issue affect the copy of the issue in the remote instance.

34. The method of claim 33, wherein comments are kept in sync between copies of the issue.

35. The method of claim 33, wherein when one copy of an issue goes through a workflow transition, other copies of the issue go through the same transition or an equivalent transition; wherein the status of the copies of an issue is kept in sync.

36. The method of claim 33, wherein when a change is made to an issue, then a change event is broadcast to all instances that have a copy of the issue.

37. The method of claim 36, wherein said change events are fed into notification systems of each instance and appropriate notifications are generated.