Project Atlassian Archives : Ascend Integrated

Automating Jira – 3 Examples Using Automation for Jira

by Mike Brown | Oct 29, 2018 | Ascend Blog, Jira, Project Atlassian

As Atlassian Experts and Solution Partner, Ascend Integrated uses many add-ons (apps) for implementing complex business requirements and scenarios. These add-ons / apps provide the ability to extend Jira further, either by adding scripts or configurations to meet evolving business needs. One add-on / app we’ve used with multiple clients to solve issues effectively and efficiently is Automation for Jira. Automation for Jira frees your team to focus on what’s important: development and releasing shippable products and serving your customers. With limited scripting, you can get a full automation suite up and running. The app relies on Rules set up in a “When”, “If”, and “Then” structure. For instance, “When: Value changes for Field X, if field x = “Updated”, Then: Edit issue fields”. In this blog, we wanted to share with you 3 unique ways to automate your Jira instance using the Automation for Jira app.

Updating Read-Only Fields

Setting a read-only field in Jira is easy. You can view the Community answer here: https://community.atlassian.com/t5/Jira-questions/Set-particular-custom-field-read-only/qaq-p/296959. If you’d like a read-only field value to update based on the values of other fields, Automation for Jira can accomplish this efficiently. Check out the configurations below:

When: “Value changes for” rule (Be sure to select the “Execute this rule immediately…” option)
If: set the JQL pointing to a specific field (i.e. Priority)
Then: “Edit Issue Fields” to choose which fields to edit. (This would be a read-only field for the users. Users will not be able to manually set this field, it will automatically set based on JQL parameters.)

An example of how this rule will be set up is shown below:

Combine with Dynamic Forms

Dynamic Forms another fan favorite, provides the ability for fields to display dependent upon selected values. While Dynamic Forms fields do not work directly with Automation for Jira, you can have other fields update based on a Dynamic Forms Field’s value through JQL. To do this, set up the following:

When: “Value changes for” rule
If: set the JQL pointing to the Dynamic Form field
Then: “Edit Issue Fields” to choose which field(s) to edit.

Managing Service Desk Tickets

If a user finds a verified bug, and they log it into Service Desk, Automation Jira can automatically create a cloned issue in your Jira development project, without agent intervention. To accomplish this, simply add a rule like the set up below:

When: “Issue Created” rule
If: set the JQL pointing to the field (i.e. customfield1000 = “X”)
Then: “Create Issue” and select what values should be in the fields.

This ensures both the development and agent queue for specific bugs / issues are always in alignment. Interested in checking out the app? Download it from the Marketplace here. It is available for Cloud, Server, and Data Center. Have questions about building out automation in Jira? Reach us here. How have you used automation in Jira?

Ascend Supports Launch of Miami AUG

by Ben Dickshinski | Mar 17, 2018 | Ascend Blog, Project Atlassian

When we opened our new office in Miami we saw an opportunity to support the launch of a Miami-based Atlassian User Group. This new space has improved our outreach efforts, and with this new AUG we want to be advocates for the use of Atlassian solutions in this vibrant and growing community. Small technology firms are booming in South Beach and we’re excited to be part of it.Yesterday we hosted the first Miami AUG, and used the event to discuss tips and tricks for getting the most out of the Atlassian ecosystem and showcased their newest tool: Stride. We enjoyed seeing some local users again, and were excited to meet some new ones. We hope that as we support further AUGs this community will grow and collaborate.

The date of the next AUG is TBD, so stay tuned.

Atlassian Summit 2017 Recap

by Mike Brown | Feb 26, 2018 | Ascend Blog, Project Atlassian

New User Interfaces for Cloud Products

The Atlassian Tool Suite for the Atlassian Cloud is getting a face lift. Over the next several months, new user interfaces for many of the tools in the Cloud (specifically Confluence, JIRA Core, JIRA Service Desk, and JIRA Software) will be released. Booths were set up near the entrance of the Exhibit Hall for users and passersby to test and provide feedback for the new user interface. While these new User Interfaces are not making it to the server instances yet, it paves the way for a redesign of the Atlassian User Interface.

Sessions and Classes

Breakout sessions were informative, and provided insight into many aspects of the Atlassian Tool Suite, from tools and techniques used at large tech firms and systems such as Netflix and LinkedIn, to developing custom add-ons, integrations, and improving performance in JIRA and Confluence. You can check out over 10 hours of recorded breakout sessions here…just don’t watch them all at once: Wednesday Sessions and Thursday Sessions.

Will we see you in Barcelona next year (2018)?

We hope you had a great time last week. Find us on Twitter and share your favorite experience at Atlassian Summit. We look forward to seeing everyone again in Barcelona for the 2018 Summit!

Day(s)

Hour(s)

Minute(s)

Second(s)

Atlassian Summit 2017

by Mike Brown | Aug 25, 2017 | Ascend Blog, Project Atlassian

The Atlassian Summit in San Jose is fast approaching! Between the excitement of the keynotes, partner day, bash, and the exhibit floor partners and decision makers, the week will be filled with opportunities for networking and education on agile and the Atlassian tool suite.

As an Atlassian Silver Solutions Partner, we’d like to take a moment to share some thoughts on what we’d like to see this year at Summit:

New JIRA Capabilities: JIRA has expanded greatly in functionality since 2015 and its continued growth is a testament to a strong following and user base. We’d like to learn what Atlassian is planning for JIRA 7.5 and beyond!
Confluence Integrations: Confluence has had limited integrations with other Atlassian tools in the past. What can we expect going forward?
Bamboo’s Next Steps: Where are we going with Continuous Build and Integration? What will happen with Bamboo, and will Bitbucket’s build capabilities be expanded to incorporate more CI capabilities?
Trello: What will the future of Trello look like, now that Atlassian has purchased the firm? How will it be incorporated into the Atlassian tool suite?
Future Integration Capabilities: In 2015 we got Atlassian Connect, but what does the future of the Plugin SDK look like?
Atlassian Cloud capabilities: Will we be able to integrate LDAP to the Cloud? And what about the ability to create our own URLs?

If you have any questions in the meantime regarding the Atlassian tool suite, visit our site and learn more about the tools and our capabilities: https://ascend.zellecloud.com/what-we-do/atlassian/.

Integrating JIRA and SSO Using CAS

by Mike Brown | Aug 1, 2017 | Ascend Blog, Project Atlassian

By default, Atlassian JIRA has an internal directory, integrates with LDAP / Active Directory, and integrates with a Single Sign On (SSO) solution: Crowd. However, a growing number of administrators are looking to integrate their Atlassian solutions across their enterprise Central Authentication Service (CAS). We decided to write this blog based on the original work put together by the JASIG team: CAS Configuration. The original code repository can be found here if you’d like to build the JAR files yourself: https://github.com/apereo/java-cas-client. A more detailed account along with code snippets can be found on our blog here: https://ascend.zellecloud.com/ascend-blog.

While the JASIG team created an excellent entry, we wanted to build on its success by adding easy-to-find download links, updated XML entries, and some additional details or directories / locations. This entry includes details on integrating with JIRA 7.x running on a Linux-based server.

The five steps we are covering here include:

Shutdown JIRA + Know your File Locations
Copy the JAR Files
Modify web.xml
Modify seraph-config.xml
Start JIRA

While this is meant to be an overview and will help in getting your JIRA to communicate with your CAS system, it is not meant to be a full setup of CAS, or a full JIRA configuration / set up as well. This article is for semi-advanced users and administrators. But, with that said if you have any questions as you go through it, please feel free to reach out to us: info@ascend.zellecloud.com.

Step 1: Shutdown JIRA + Know your File Locations

First, make sure JIRA is shut down.

All files discussed here will exist in the following locations (note, JIRA_INSTALL by default is set to the /opt/atlassian/jira/atlassian-jira/ directory). The list of the files to be modified / copied are below as well as their locations:

seraph-config.xml: JIRA_INSTALL/WEB-INF/classes
web.xml: JIRA_INSTALL/WEB-INF/
CAS Client for Java Core: JIRA_INSTALL/WEB-INF/lib (needs to be copied here)
CAS Client for Java Atlassian Integration (for JIRA 7): JIRA_INSTALL/WEB-INF/lib

NOTE:
You can download the updated CAS clients (v3.3) that will be used along with the Jira7 JAR files from our Bitbucket repository here (download both files): https://bitbucket.org/mbrown_ascend/jira-cas-integration/downloads/

Step 2: Copy the JAR Files

After you have downloaded the files above (CAS Client for Java Core v3.3.3 + CAS Client for Java Atlassian Integration v3.5), copy both of these JAR files both into the JIRA_INSTALL/WEB-INF/lib/ file directory.

Step 3: Modify web.xml

Open up web.xml in your favorite text editor. We used VIM for most of these modifications. Around line 374, just above the “THIS MUST BE THE LAST FILTER IN THE DEFINED CHAIN” comment, add the following code (Wherever it says to add your specific information):

<!-- CAS:START - Java Client Filters -->
 
<filter>
   <filter-name>CasSingleSignOutFilter</filter-name>
   <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
</filter>
<filter>
  <filter-name>CasAuthenticationFilter</filter-name>
  <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
  <init-param>
    <param-name>casServerLoginUrl</param-name>
    <param-value> Include your CAS login here </param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value> include your JIRA url here </param-value>
  </init-param>
</filter>
<filter>
    <filter-name>CasValidationFilter</filter-name>
    <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
    <init-param>
        <param-name>casServerUrlPrefix</param-name>
        <param-value>Include your CAS login here</param-value>
    </init-param>
    <init-param>
        <param-name>serverName</param-name>
    <param-value>include your JIRA url here</param-value>
    </init-param>
    <init-param>
        <param-name>redirectAfterValidation</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
 
<!--- CAS:END -->

Next, around line 627, there will be a filter mapping for your login, something like this:

    <filter-mapping>
        <filter-name>login</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher> <!-- we want security/login to be applied after urlrewrites, for example -->
    </filter-mapping>

Above the filter mapping code listed above, copy and paste the following:

<!-- CAS:START - Java Client Filter Mappings -->
 
<filter-mapping>
   <filter-name>CasSingleSignOutFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>CasAuthenticationFilter</filter-name>
    <url-pattern>/default.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>CasValidationFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
 
<!-- CAS:END -->

You can just copy / paste this code directly. After you have finished, save the web.xml file (in the VIM editor type ESC and then “:wq”).

Step 4: Modify seraph-config.xml

Next, you must make the following modifications to the seraph-config.xml file. In your seraph-config.xml file, there should be series of parameters. This is where you will make the modifications. Look at the code below, once again any area below that states “add your CAS URL…” is what you will need to modify.

<init-param>
    <!--
      The login URL to redirect to when the user tries to access a protected resource (rather than clicking on
      an explicit login link). Most of the time, this will be the same value as 'link.login.url'.
    - if the URL is absolute (contains '://'), then redirect that URL (for SSO applications)
    - else the context path will be prepended to this URL
 
    If '${originalurl}' is present in the URL, it will be replaced with the URL that the user requested.
    This gives SSO login pages the chance to redirect to the original page
    -->
    <param-name>login.url</param-name>
    <!--<param-value>/login.jsp?os_destination=${originalurl}</param-value>-->
    <param-value>add your CAS URL here</param-value>
</init-param>
<init-param>
    <!--
      the URL to redirect to when the user explicitly clicks on a login link (rather than being redirected after
      trying to access a protected resource). Most of the time, this will be the same value as 'login.url'.
    - same properties as login.url above
    -->
    <param-name>link.login.url</param-name>
    <!--<param-value>/login.jsp?os_destination=${originalurl}</param-value>-->
    <!--<param-value>/secure/Dashboard.jspa?os_destination=${originalurl}</param-value>-->
    <param-value>add your CAS URL here</param-value>
</init-param>
<init-param>
    <!-- URL for logging out.
    - If relative, Seraph just redirects to this URL, which is responsible for calling Authenticator.logout().
    - If absolute (eg. SSO applications), Seraph calls Authenticator.logout() and redirects to the URL
    -->
    <param-name>logout.url</param-name>
    <!--<param-value>/secure/Logout!default.jspa</param-value>-->
    <param-value>add your CAS LOGOUT URL here</param-value>
</init-param>

After you have finished with this modification, scroll down to around line 93, and comment out SSOSeraphAuthenticator and JIRASeraphAuthenticator lines:

<!-- CROWD:START - If enabling Crowd SSO integration uncomment the following SSOSeraphAuthenticator and comment out the JiraSeraphAuthenticator below -->
    <!--
    <authenticator class="com.atlassian.jira.security.login.SSOSeraphAuthenticator"/>
    -->
<!-- CROWD:END -->
 
    <!-- CROWD:START - The authenticator below here will need to be commented out for Crowd SSO integration -->
    <!-- <authenticator class="com.atlassian.jira.security.login.JiraSeraphAuthenticator"/> -->
    <!-- CROWD:END -->

Add the following to this section instead:

<authenticator class="org.jasig.cas.client.integration.atlassian.Jira7CasAuthenticator">
        <init-param>
            <param-name>casServerUrlPrefix</param-name>
            <param-value>include your cas server here</param-value>
        </init-param>
        <init-param>
            <param-name>serverName</param-name>
            <param-value>include your JIRA server URL</param-value>
        </init-param>
</authenticator>

From there, save and close the file.

Step 5: Start JIRA

After you start JIRA instance, go to a browser and type in your JIRA URL. You will be re-directed to your CAS Client.

If you are having issues with your configuration, please reach out to us anytime! We have completed CAS configurations in multiple environments using different versions of CAS. If you have any questions about this blog or about integrating your Atlassian Tool with multiple SSOs, send us an email at info@ascend.zellecloud.com.

Your Help Desk Needs: Zendesk vs. Atlassian JIRA Service Desk

by Mike Brown | Mar 16, 2017 | Ascend Blog, Project Atlassian

No one can downplay the importance of utilizing an efficient and effective IT Service Management (ITSM) software at work in your organization or enterprise. A business must be able to respond both externally to customers’ requirements, and internally to stakeholders with inquiries or support needs in an acceptable amount of time and maintain consistent communication throughout the process. Two applications dominating the ITSM market with their innovative approaches to service management are Atlassian’s JIRA Service Desk and the Zendesk platform. To be effective, ITSMs often need to provide reporting capabilities, SLA’s, automation, and need to be easily extendable / adaptable across multiple teams. Here we’ll examine the pros and cons of both applications, along with our recommendations based on our use of both applications across different environments.

Note: comparisons between Zendesk and Service Desk were made using the Zendesk Cloud platform, and the JIRA Service Desk Cloud / v 3.3.1 (server) implementations.

Zendesk

Founded in 2007, Zendesk is a system for tracking, prioritizing, and solving customer support tickets (thank you Wikipedia). Zendesk is a completely cloud based ITSM. After I went to their application site, https://www.zendesk.com/ and clicked “Get Started”, I was up and running in a matter of 5 minutes. Pretty cool! I began customizing my Zendesk instance right away, and was happily greeted with a straightforward user interface (see Figure 1 below). Just adding a new field was a simple task. Much of the administration was intuitive, no training required!

Figure 1: Adding a New Field

After setting up the system itself, users entering tickets would see a screen similar to this one:

Figure 2: Entering a Ticket into Zendesk

Here are some of my thoughts based on my experience working with Zendesk in the past and just recently.

Starting Price:

$5.00 per agent per month (agent denotes someone who is a user and administrator of the ITSM, not a customer)

Pros:

Straightforward User Interface and Administration built into the Zendesk application. Take a look at Figure 1 above to see just how easy it is to add a field to a ticket.
Triggers, Automations, and SLA’s are now a core feature built into the Zendesk application.
Social Media Integration (yes you can link to Facebook, Twitter, etc.).
Reporting and Views functionality allows users to create views using specific conditions selected from multi-select boxes. Users can drag+drop columns to better organize their reports.
Rich App Marketplace for add-ons and extending the functionality of your Zendesk instance. Some of these add-ons are free and easily installed on your instance with a few clicks.

Cons:

As its hosted in the cloud, the URL will appear as “yourcompanyname.zendesk.com” rather than having it on a dedicated URL.
Price of $5 per month per agent can be costly to a small business depending on the number of agent accounts you would like to create.
Limited overall customization capabilities: while Zendesk is simple to get up and running, and it is certainly extendable, there is much less functionality out-of-the-box with Zendesk when compared with JIRA Service Desk.
Zendesk is not specifically ITIL compliant. While it is possible to install plugins in order to bring the system close to ITIL compliance, it is not ITIL certified out of the box.

JIRA Service Desk

Built on the power and flexibility of JIRA Core, JIRA Service Desk is a standalone ITSM software developed by Atlassian for use as an IT Help Desk ticketing system. After navigating to the Atlassian website and clicking “Try it Free”, I’m brought here where I can create my own Service Desk instance in the Cloud: https://www.atlassian.com/software/jira/service-desk/try and I’m off and running. Service Desk can also be downloaded locally to your own server.

After I create my instance, I can create a Service Desk Project based on previously defined templates, or I can create a custom project, including workflows, fields, request / issue types, permissions, notifications, etc. Figure 3 shows the types of customizations, for instance you can perform creating custom fields.

Figure 3: Customizing Fields for JIRA Service Desk

Figure 4 provides an overview of how the ticket / request type forms will look like if you choose a standard out-of-the box template.

Figure 4: Entering A Ticket Through JIRA Service Desk

Starting Price:

$10.00 for 1 – 3 agents in the cloud / server instances.

Pros:

To start, JIRA Service Desk is ITIL Compliant and Certified. This is a make or break decision for some organizations looking to implement an ITSM that complies with ITIL.
Excellent price points initially (1 – 3 agents are only $10.00 / month), though it can become expensive if you begin scaling (i.e. a service desk with 6 agents would run you $3,000.00 per year, compared with $30.00 per month using Zendesk).
The administration section of JIRA Service Desk is extremely customizable, you can customize anything from field types, to request types, automation & SLA’s, and create custom dashboards using built-in gadgets.
Comprehensive reporting using JIRA Query Language (JQL), allow you to create advanced reports easily.
Atlassian Marketplace is filled with Add-Ons (some free) that further extend the functionality of Service Desk.

Cons:

Too many customization options require the Service Desk administrators to be specialists. Nuances abound when administering a Service Desk instance.
For clients using the server-based version of Service Desk, they will need to have a separate server / hosted environment which may add to the costs.
If you are using the Atlassian Cloud instance, you will be stuck with a URL such as “yourcompanyname.atlassian.net”, very similar to Zendesk.
There are inconsistent functionalities across the Cloud and Server versions of Service Desk. New functionality is often introduced in the Cloud before it is found on the Server version.

Conclusion

Zendesk and JIRA Service Desk are both powerful ITSM’s in the marketplace. They provide a full range of functionality for users of all types of organizations. Interestingly enough, these systems have long since decided to interoperate with one another. Users may install add-ons for JIRA that allow JIRA data points to be displayed in a Zendesk instance (and vice versa).

Our recommendation: JIRA Service Desk is best suited for organizations who require more complex reporting out-of-the-box, additional functionality / control, and who may need their Service Desk instance hosted behind a firewall. Zendesk is preferential for smaller organizations (not to say it can be used for larger organizations as well) who do not require the complex administration / management / reporting, but want a dependable system running in the cloud.

What are your thoughts, have you used Service Desk or Zendesk?

« Older Entries