1. Introduction

This guide describes how Plastic SCM provides integration possibilities with diverse control tracking tools like Bugzilla, DevTrack, Mantis, OnTime, Trac and Jira.

Once you have configured your desired control tracking system, you will be able to transparently use the extension control tracking system. So, for all of them, you will be able to see the associated task information. Plastic SCM extensions allow two differente working modes: “task on branch”, one which one task on the task tracking system is associated to one Plastic SCM branch; from the branch view users can open their task tracking tool where the information is displayed. The second working mode is “task on changeset”, in this case one or more tasks are linked to one or more changesets, the information of the associated tasks are available from Plastic changeset view. Jira also allows seeing all options of check in done on the branch associated to a certain issue.

2. Bugzilla Integration

2.1. Introduction

This section describes the steps to follow in order to use Bugzilla integration with PlasticSCM. It also describes its advantages.

This extension is compatible with Bugzilla versions 2005, 2006 and 2007.

2.2. Configuration

2.2.1. Server

To set out every Bugzilla extension functionality, copy the script ‘plastic.cgi’(included on install_path/client/extensions/bugzilla ) on Bugzilla´s installation folder.

You may need to change the first line on the script:

#!/usr/bin/perl –wT

To:

#!c:\perl\bin\perl.exe –wT.

2.2.2. Client

In the first place it is necessary to copy ‘bugzillaextension.dll’ library to the folder where Plastic SCM client is installed.

You must add the following lines to the file ‘client.conf’ in order to indicate the client to use this extension.

Creating a file ‘bugzillaextension.conf’ is also needed in order to specify the extension the needed configuration parameters to interact with the server. This file will vary depending on the working mode used, the mode by default is “task on branch”, and the appearance of the default configuration is the following:

<BugzillaBaseUrl>http://localhost:8888</BugzillaBaseUrl>

</BugzillaExtensionConfiguration>

If you want to specify this “task on branch” mode, you should use:

<BugzillaBaseUrl>http://192.168.1.14:8888/bugzilla/3.0/</BugzillaBaseUrl>

<WorkingMode>TaskOnBranch</WorkingMode>

</BugzillaExtensionConfiguration>

For the “task on changeset” mode the file must be as follows:

<BugzillaBaseUrl>http://192.168.1.14:8888/bugzilla/3.0/</BugzillaBaseUrl>

<WorkingMode>TaskOnChangeset</WorkingMode>

</BugzillaExtensionConfiguration>

Parameters meaning:

BugzillaBaseUrl -> Url where is installed Bugzilla.

BranchPrefix -> Prefix will have the created branches on PlasticSCM that you want to associate with Bugzilla defect. That is, if you want to create an associated branch whith a defect 3 this branch should call, for example, SCM003.

You must additionally specify two other parameters:

PlasticCGI -> By defect: ‘/plastic.cgi’. Refers to the place and cgi name using Plastic SCM to obtain bugs information.

ShowBugCGI -> By defect: ‘/show_bug.cgi?id={0}’. Refers to the cgi place that orders to show bugs.

Once all the parameters have been set, Plastic SCM can begin to use Bugzilla extension in a fully transparent way to the user.

2.3. Characteristics

2.3.1. “Task on branch” working mode

Using this working mode, every Bugzilla defect is associated to a branch in Plastic, when creating a new branch; it will be given the same name as the one of the Bugzilla defect which will be associated to that certain branch.

Extended information of the branches will be display by accessing on the left hand side of the branch view, selecting a branch the menu on the right will show the information of the associated task/defect: its number, owner or developer the task has been assigned to, title and comments.

If you click on it, an Explorer window with the associated branch bug is opened:

2.3.2. Enforcing task existence

It is possible to setup Plastic repositories so that numbered branches associated to tasks are checked against Bugzilla. Only if there is a bug number defined in Bugzilla the working branch will be allowed. This check is performed on the branch creation operation, only for child branches.

In order to setup the branch creation check on a repository, create an attribute named “plastic-enforce-task-branch” on the desired repositories, like in the following sample using the command line:

cm makeattribute plastic-enforce-task-branch

With this attribute created, each time a child branch is created on the repository where it is defined, the extension will check the name of the new branch. If it starts with the task prefix, will then pick the number contained on it and ask Bugzilla if there is a matching bug number. Otherwise an error is printed and the operation cancelled. This is a sample of the error that is displayed:

2.3.3. “Task on changeset” working mode

When using the “task on changeset” working mode, every time a user commits or checks in his changes, a dialog will be displayed on which to include both comments related to those changes and the task or tasks that group of changes or changeset will be associated to:

Going to the option “Add new issue” another dialog will be opened. On this new dialog, as shown on the image above, the user would select the task or defect to be associated to the changeset:

Furthermore, from the changesets view, information on the task associated in Bugzilla will be displayed, from this view new tasks can be added to a certain changeset and by clicking on the task and Explorer window with the related task in Bugzilla will be opened:

3. DevTrack integration

3.1. Introduction

This section describes the steps to follow in order to use DevTrack integration with PlasticSCM. It also describes its advantages.

This extension is compatible with DevTrack versions 6 and 7.

3.2. Configuration

3.2.1. Server

To set out every DevTrack extension functionality, you must go to “DevTrack Admin” and select “Tool” and then “Link Plus” and the window shown on the following image will be displayed. From this window, clicking on the “New Link” option, a new window will appear, on which to include the following data:

· TechExcel DevTrack Project Name: The name of the project to be created

· Linked System ID

· Linked Project ID

These last two parameters would be used from the client in order to access DevTrack.

3.2.2. Client

In the first place it is necessary to copy ‘devtrackextension.dll’’ library to the folder where Plastic SCM client has been installed.

You must add the following lines (circled in red) to the file ‘client.conf’ in order to indicate the client to use this extension.

Creating a file ‘devtrackextension.conf’ is also needed in order to specify the extension of the parameters that will interact with the server. This file will have the following appearance by default:

<DevTrackExtensionConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DTLinkPlusUrl>http://192.168.1.237/LinkPlusWebService/WSDTIncident.asmx</DTLinkPlusUrl>

<User>terry-j</User>

<ProjectId>daveProject</ProjectId>

<SystemId>daveSystem</SystemId>

<BranchPrefix>issue</BranchPrefix> <DTBugInfoBrowserUrl>http://192.168.1.237/scripts/texcel/devtrack/buginfo.dll</DTBugInfoBrowserUrl>

</DevTrackExtensionConfiguration>

You must take into account that Plastic SCM integration with DevTrack provides with two different options depending on the working mode to be used; the one used by default is “task on branch” but it can be also specified as follows:

<User>terry-j</User>

<ProjectId>daveProject</ProjectId>

<SystemId>daveSystem</SystemId>

<BranchPrefix>issue</BranchPrefix> <DTBugInfoBrowserUrl>http://192.168.1.237/scripts/texcel/devtrack/buginfo.dll</DTBugInfoBrowserUrl>

<WorkingMode>TaskonBranch</WorkingMode>

</DevTrackExtensionConfiguration>

If the working mode you want to use is the “TaskOnChangeset”, the following “devtrackextension.conf” must be configured:

<User>terry-j</User>

<ProjectId>daveProject</ProjectId>

<SystemId>daveSystem</SystemId>

<BranchPrefix>issue</BranchPrefix> <DTBugInfoBrowserUrl>http://192.168.1.237/scripts/texcel/devtrack/buginfo.dll</DTBugInfoBrowserUrl>

<WorkingMode>TaskonChangeset</WorkingMode>

<AttributePrefix>dev_track</AttributePrefix>

</DevTrackExtensionConfiguration>

The meaning of the parameters on the file is as follows:

DTLinkPlusUrl -> Location of the LinkPlus web service as set up on Dev Track installation, which is also the location of the WSDTIncident.asmx file

Project ID -> The parameter set on the “Link Plus” information

System ID -> The one set on the “Link Plus” information

BranchPrefix -> Prefix will have the created branches on PlasticSCM that you want to associate with DevTrack issue. That is, if you want to create an associated branch whith an issue 3 this branch should call, for example, SCM003

DTBugInfoBrowserUrl -> The BugInfo.dll URL located on DevTack path

AttributePrefix -> Only used on the “TaskonChangeset” working mode, on this mode an attribute is associated to the changesets.

Once every parameter has been set, Plastic SCM can begin to use DevTrack extension in a fully transparent way to the user.

3.3. Characteristics

3.3.1. “Task on branch” working mode

The working mode used by default is the “task on branch”, which is usually used to work with the “branch per task” pattern, on which for each task to be done, a new branch will be created. In order to use this working mode, the “devtrackextension.con” file must be set following the steps on the previous section: specifying this working mode or using the default setting which used “task on branch”.

In order to start working with Plastic SCM and DevTrack, the first step would be creating issues in DevTrack, which would be usually done by the Project Manager, by clicking on the “New” option on DevTrack you can choose to submit a new feature or a new defect, depending on the nature of the new task to be submitted. The information to include would be title, type of task (bug, minor improvement, future enhancement or discrepancy report), description, developer assigned, etc as you can see on the following image:

Once the new task is created, DevTrack assigns it a number; in this case it would be number 106 as shown on the following image. Displaying the Issue List you can find issues by developer, state, etc and they can be edited anytime.

The next step is that the developer the task has been assigned to starts working on it, so he creates a new branch (as simple as right clicking on the parent branch and select the “create child branch” option), and a new window will be opened, in which to include the information of the new branch: its name, in this case 106, as the DevTrack task with the prefix stated on the “devtrackextension.conf” (scm), comments related to the newly created branch and, as Plastic SCM branches are smart and remember their base, a base can be set on this dialogue, and every time a user has to change to that branch to work on it, it will automatically “remember” its base.

Now the user can always check the information of the issues just by going to the extended information on the branch view (on the left top side of the view), and select the branch: a dialog will be displayed on the right from which the DevTrack extension information is shown: ID number, owner, status, title, etc.

Clicking on each of the issues an Explorer window with the associated branch task will be opened, when the users changes the status or any other field of the issue; the new information will appear by refreshing DevTrack extension.

3.3.2. “Task on changeset” working mode

In the case that you are using the “task on changeset” working mode with the extension of Plastic SCM and DevTrack, the “devtrackextension.conf” must be set up indicating it, as shown on the Client section. It must be indicated as the working mode by default is not “task on changeset” but “task on branch”.

In order to start working we must have created DevTrack tasks so that the developer assigned to those tasks can start working on them.

Once the developers has checked out the files he was to work with and the changes are submitted, the developer checks them in and an information dialogue will be displayed; on this dialogue users can include their comments on the check in operation as well as the issues associated from their task tracking control, DevTrack in this case. By using this working mode, one or more than one changeset in Plastic can be associated to one or more than one tasks in DevTrack. The dialogue appearance is shown on the following image:

By selecting the option “Add new issue” on this check in information dialogue, a new window will be displayed on which to include the ID or number of the DevTrack issue and by pressing on the “Details” button the information of the issue will be shown as the following image displays:

Once the changeset(s) have been linked to the issue or task in DevTrack, the extension information will be shown on the changeset view. From the DevTrack Extension information users can also add new issue or delete previous ones and by clicking on each of the issues associated to a certain changeset, an Explorer window in DevTrack will be opened. Whenever a user modifies an issue in the task tracking tool, by refreshing the TechExcel DevTrack Extension information, it will be shown in Plastic.

4. Mantis integration

4.1. Introduction

This section describes the steps to follow in order to use Mantis integration with PlasticSCM. It also describes its advantages.

This extension is compatible with Mantis versions 0.19.4, 1.0.0, 1.0.8 y 1.1.0a3.

4.2. Configuration

4.2.1. Server

To set out every Mantis extension functionality, copy the script ‘plastic.php’(included on install_path/client/extensions/mantis ) on the Mantis´installation folder.

4.2.2. Client

In the first place it is necessary to copy ‘mantisextension.dll’’ library to the folder where you have installed Plastic SCM client.

You must add the following lines to the file ‘client.conf’ in order to indicate the client to use this extension.

Creating a file ‘mantisextension.conf’ is also needed in order to specify the extension of the parameters that will interact with the server. This file will have the following appearance by default:

<MantisBaseUrl>http://localhost:8888</MantisBaseUrl>

</MantisExtensionConfiguration>

You must take into account that Plastic SCM integration with Mantis provides with two different options depending on the working mode to be used; the one used by default is “task on branch” but it can be also specified as follows:

<MantisBaseUrl>http://localhost:8888</MantisBaseUrl>

<WorkingMode>TaskOnBranch</WorkingMode>

</MantisExtensionConfiguration>

If the working mode you want to use is the “TaskOnChangeset”, the following “mantisextension.conf” must be configured:

<MantisBaseUrl>http://localhost:8888</MantisBaseUrl>

<WorkingMode>TaskOnChangeset</WorkingMode>

</MantisExtensionConfiguration>

The meaning of the parameters on the file is as follows:

MantisBaseUrl -> Url where Mantis is installed.

BranchPrefix -> Prefix will have the created branches on PlasticSCM that you want to associate with Mantis issue. That is, if you want to create an associated branch whith an issue 3 this branch should call, for example, SCM003.

You can additionally specify two other parameters:

PlasticPHP -> By defect: ‘/plastic.php’. Refers to the place and php name that uses Plastic SCM to obtain issues information.

ShowBugPHP -> By defect: ‘/view.php?id={0}’. Refers to the php place that orders to show issues.

Once every parameter has been set, Plastic SCM can begin to use Mantis extension in a fully transparent way to the user.

4.3. Characteristics

4.3.1. “Task on branch” working mode

The working mode by default is “task on branch”, used for the “branch per task” pattern, on which for each task to be done a new branch will be created; to use this working mode the “mantisextension.conf” file must be set following the steps of the previous section.

As usual, the first step would be creating issues in Mantis, this would be usually done by the Project Manager, by clicking on the “Report Issue” option a dialog on which to include the information of the new issue to be done will be opened, the information to include would be title, description, severity, etc.

When the issue is created, Mantis assigns it a number, in this case 4, and as you can see on the picture below, displaying the list of issues, which are shown on different colours depending on their status, you can select one and change its status, so issue 4 goes from new to assigned.

The next step is that the developer the task has been assigned to starts working on it, so he creates a new branch (as simple as right clicking on the parent branch and select the “create child branch” option), as shown on the following image, and, in order to link it to the issue in Mantis, it must be given the same number, 4 in this case:

Now the user can always check the information of the issues just by going to the extended information on the branch view and selected the branch: a dialog will be displayed on the right from which the Mantis extension information is shown: issue number, owner, status, etc.

Clicking on each of the issues an Explorer window with the associated branch issue will be opened, when the users changes the status or any other field of the issue; the new information will appear by refreshing Mantis extension.

4.3.2. “Task on changeset” working mode

In the case that you are using the “task on changeset” working mode with the extension of Plastic SCM and Mantis, the “mantisextension.conf” must be set up indicating it, as shown on the Client section. It must be indicated as the working mode by default is not “task on changeset” but “task on branch”.

In order to start working we must have created Mantis tasks so that the developer assigned to those tasks can start working on them. Once the changes are submitted and the developer checks them in an information dialogue will be displayed, on this dialogue users can include their comments on the check in operation as well as the issues associated from their task tracking control, Mantis. By using this working mode, one or more than one changeset in Plastic can be associated to one or more than one issues in Mantis. The dialogue appearance is shown on the following image:

By selecting the option “Add new issue” on this check in information dialogue, a new window will be displayed on which to include the ID or number of the Mantis issue and by pressing on the “Details” button the information of the issue will be shown as the following image displays:

Once the changeset(s) have been linked to the issue or task in Mantis, the extension information will be shown on the changeset view. From the Mantis Extension information users can also add new issue or delete previous ones and by clicking on each of the issues associated to a certain changeset, an Explorer window in Mantis will be opened. Whenever a user modifies an issue in Mantis, by refreshing the Mantis Extension information, it will be shown in Plastic.

5. Trac integration

5.1. Introduction

This section describes the steps to follow in order to use Trac integration with PlasticSCM. It also describes its advantages.

This extension is compatible with Trac versions from 0.10.

5.2. Configuration

5.2.1. Server

To set out every Trac extension functionality, you must install the XMLRPC plugin to Trac server.

On the following link: http://trac-hacks.org/wiki/XmlRpcPlugin you can find information on how to download, install and verify that it has been properly set up.

Using Trac administration tool XML_RPC permit must be assigned to users using the extension. If this permit is assigned to user “anonymous” it will be available to every system user.

When using the extension several Server configuration features must be taken into account:

If the authentication method used is the Basic one (option --basic-auth when launching tracd), and authentication based on user/password can be done. In this case the URL need to access XMLRPC services would be: http://servidor/trac/login/xmlrpc.

If any other authentication method is used Plastic extension cannot proceed with the user authentication. In this case user anonymous must be given permits for XML-RPC and theURL, access to the services would be through: http://servidor/trac/xmlrpc. It will not be necessary to inster user/password on the extension configuration file.

5.2.2. Client

In the first place it is necessary to copy ‘CookComputing.XmlRpc.dll’ and ‘tracextension.dll’ libraries to the folder where you have installed Plastic SCM client.

You must add the following lines to the file ‘client.conf’ in order to indicate the client to use this extension.

Creating a file ‘tracextension.conf’ is also needed in order to specify the extension of the parameters that will interact with the Server. This file will have the following appearance by default:

<XmlRpcUrl>http://localhost:8080/trac/login/xmlrpc</XmlRpcUrl> <ShowTicketUrl>http://localhost:8080/trac/ticket</ShowTicketUrl> <User>tester</User>

<Password>tester</Password>

</TracExtensionConfiguration>

The working mode used by default is “Task on Branch” and it can also be specified on the “tracextension.conf”:

<XmlRpcUrl>http://localhost:8080/trac/login/xmlrpc</XmlRpcUrl> <ShowTicketUrl>http://localhost:8080/trac/ticket</ShowTicketUrl> <User>tester</User>

<Password>tester</Password>

<WorkingMode>TaskonBranch</WorkingMode>

</TracExtensionConfiguration>

In order to use the “Task on Changeset” working mode, the following “tracextension.conf” must be set up:

<XmlRpcUrl>http://localhost:8080/trac/login/xmlrpc</XmlRpcUrl> <ShowTicketUrl>http://localhost:8080/trac/ticket</ShowTicketUrl> <User>tester</User>

<Password>tester</Password>

<WorkingMode>TaskonChangeset</WorkingMode>

</TracExtensionConfiguration>

Parameters meaning:

XmlRpcUrl -> Url where XMLRPC services are located on the server.

ShowTicketUrl -> Url where you can check the tickets registered into the system.

User -> User name to be authenticated for XMLRPC calls. This user must have XML-RPC system permit.

Password -> Password corresponding to a previous user.

BranchPrefix -> Prefix that will contain branches created in Plastic SCM, to be associated with an OnTime bug. If you need to create a branch associated to bug 3, it must be called, for instance: SCM003.

Once all the parameters have been configured, Plastic SCM can begin to use Trac extension in a fully transparent way to the user.

5.3. Characteristics

5.3.1. “Task on branch” working mode

The working mode by default is “task on branch”, used for the “branch per task” pattern, on which for each task to be done a new branch will be created; to use this working mode the “tracextension.conf” file must be set following the steps of the previous section.

As usual, the first step would be creating issues in Trac, this would be usually done by the Project Manager, by clicking on the “New Ticket” option a dialog on which to include the information of the new issue to be done will be opened, the information to include would be title, description, summary, etc.

When the task or ticket is created, Trac assigns it a number, in this case 3, and as you can see on the picture below, displaying the list of tasks, searching by state or developer, you can select one and change its status, so issue 3 is shown as a defect assigned to michael.

The next step is that the developer the task has been assigned to starts working on it, so he creates a new branch (as simple as right clicking on the parent branch and select the “create child branch” option), as shown on the following image, and, in order to link it to the issue in Trac, it must be given the same number, 3 in this case, including the prefix set on the “tracextension.conf”, which is SCM in this case:

Now the user can always check the information of the tasks just by going to the extended information on the branch view and selected the branch: a dialog will be displayed on the right from which the Trac extension information is shown: ID, title, owner, status, etc.

5.3.2. “Task on changeset” working mode

In the case that you are using the “task on changeset” working mode with the extension of Plastic SCM and Trac, the “tracxtension.conf” must be set up indicating it, as shown on the Client section. It must be indicated as the working mode by default is not “task on branch” but “task on changeset”.

In order to start working we must have created tasks on Trac, so that the developer assigned to those tasks can start working on them. Once the changes are submitted and the developer checks them in an information dialogue will be displayed, on this dialogue users can include their comments on the check in operation as well as the issues associated from their task tracking control, Trac. By using this working mode, one or more than one changeset in Plastic can be associated to one or more than one tasks in Trac. The dialogue appearance is shown on the following image:

By selecting the option “Add new issue” on this check in information dialogue, a new window will be displayed on which to include the ID or number of the Trac task and by pressing on the “Details” button the information of the issue will be shown as the following image displays:

Once the changeset(s) have been linked to the ticket or task in Trac, the extension information will be shown on the changeset view. From the Trac Extension information users can also add new tasks or delete previous ones and by clicking on each of the issues associated to a certain changeset, an Explorer window in Trac will be opened. Whenever a user modifies an issue in the task tracking tool, by refreshing the Trac Extension information, it will be shown in Plastic.

6. JIRA Integration

6.1. Introduction

This section describes the steps to follow in order to use JIRA integration with Plastic SCM, as well as its advantages.

6.2. Configuration

6.2.1. Server

A user with Administration permit on JIRA must create a new ‘CustomField’ in the system. You must click on the ‘CustomField’ link on the administration tab.

Click on “Add Custom Field”.

“Read-only text field” must be selected as type. This option cannot be edited manually. The log for check in operations done through JIRA extension for Plastic SCM must be introduced.

Now a name must be given to this field, as well as to its set up options. You can leave the options by default, which means that this check in log will be used for every project and every type of issue. But is needed, these options can be modified.

On the option of choosing a screen for this field you must select “Default Screen”.

This newly created field will not appear until a check in operation has been done, so a client must be configured and that client must check in on the branch associated to that issue.

You can see that and internal id has been assigned to this CustomField:

This id must be written down as it must be specified on the client extension configuration.

Once this step is completed our CustomField is created.

JIRA system administrator must also active calls to RPC’s on the server, as this is how the extension communicates with the server.

Go to “General Configuration” in Global Settings and check if the ‘Accept remote API calls’ is active.

If it is deactivated, you must Edit Configuration in order to activate it.

Once these steps have been fulfilled, JIRA server is ready to accept Plastic SCM integration.

6.2.2. Client

In the first place it is necessary to copy ‘jiraextension.dll’ to the folder where Plastic SCM client is installed.

You must add the following lines to the file ‘client.conf’ in order to indicate the client to use this extension.

Creating a ‘jiraextension.conf’ is also needed in order to specify the extension of the parameters that will interact with the Server. This file will have the following appearance by default:

The working mode by default will be “task on branch”, which can be specific by configuring the following “jiraextension.conf”:

<WorkingMode>TaskOnBranch</WorkingMode>

</JiraExtensionConfiguration>

On the other hand, for users who want to use the “task on changeset” mode, this file would have the following appearance:

<WorkingMode>TaskOnChangeset</WorkingMode>

</JiraExtensionConfiguration>

Parameters meaning:

HttpUrl -> JIRA IP address and port.

User -> JIRA user to be logged in the system for doing queries and check in logs.

Password -> Password corresponding to the specified user.

ProjectKey -> Key of the Project whose issues will be related to Plastic SCM branches.

BranchPrefix -> Prefix that will contain branches created in Plastic SCM, to be associated with a JIRA issue. If you need to create a branch associated to issue PRJ-3, it should be called SCM003.

CustomFieldId -> id of the previously created field to be used for logging check ins done with Plastic SCM.

You can additionally specify two other parameters:

SoapUrl -> By default: ‘/rpc/soap/jirasoapservice-v2’. It refers to the relative location of the web services used by the client.

TaskUrl -> By default: ‘/browse/’. It refers to the web path on which the issues are shown.

Once all the parameters have been configured, Plastic SCM can begin to use JIRA extensión in a fully transparent way to the user.

6.3. Characteristics

6.3.1. “Task on branch” working mode

In order to use this working mode, the first step would be setting it up on the “jiraextension.conf” file following the indications from the previous section, or leaving the configuration by default which applies to this mode.

To start working with Plastic SCM and Jira extensión you first have to create the issues on the task tracking system by clicking on the “Create New Issue” option and inserting data data related to the new issue, name, project associated, summary, etc.

Jira will asign a number to the newly created issue, which will be the same number given to the Plastic branch when working on that task, in this case we create issue number 3.

When the developer who has been assigned to that issue starts working on it, he will go to Plastic and create a new branch; he must take into account that he has to give it the same name as the one of the issue on Jira (3), with the scm prefix, as specified on the “jiraextension.conf” file, so the extension will link the branch and the issue:

By clicking on the left hand side of the branch view (“show extended information”), the information associated to the branches will be displayed on the GUI´s right hand side as shown on the following screenshot. Selecting a branch the detailed information of the Jira issue will be shown: name, title, comment and owner.

By clicking on it, an Explorer window with the associated branch issue is opened, whenever the user finishes the task and changes its status, in order to view the new status, he will only have to refresh it on the Plastic branch extended information.

6.3.2. “Task on changeset” working mode

In order to use the “task on changeset” working mode with Plastic SCM and Jira, the “jiraextension.conf” must be set up indicating this particular working mode, as shown on the file configuration, as the working mode used by default is “task on branch”.

One the issues are created in Jira, as shown on the previous working mode section, the developer will normally work on his changes in Plastic and when checking them in a checkin information dialog will be displayed; on this dialog users can include their comments as well as the tasks or issues associated from their task control tool, Jira. By using this working mode, one or more than one issue can be associated to one or more than one changesets:

On this dialog, by selecting the “Add new issue” option shown on the previous figure, a new dialog will be displayed, on which to include the ID of the issue to be linked to that changeset:

Once the changeset has been linked to the issue or task in Jira, from the changeset view its information will be shown, and users can also add new issues or delete previous ones; and by clicking on each issue an Explorer window with the associated branch issue in Jira will be opened.

6.3.3. Check in operations register

Apart from showing information on the issues associated to the branches integrated with Plastic SCM, this extension logs in JIRA every check in done on the branches with associated issues. So, after working on the branch associated to ‘PRJ-1’ issue, if you have a look at the issue you would find the following:

You can see how every check in operation has been registered on the branch associated to that issue.

For every check in you can see the following information: its repository, the changeset associated to the operation, Plastic SCM user and the time (client´s) on which it was done, the comment associated to that check in and the involved items.

This view can be a lot bigger, depending on the work done on each branch, so this field can be hidden and the user will be able to see the rest of the issue fields.

In order to show/hide it you must click on the ‘Hide/Show’ link on the top of the previously created ‘Custom Field’.