This is a guest post from StiltSoft company, a small team of Atlassian Experts and avid fans of JIRA and Confluence from Belarus. StiltSoft is the Atlassian Verified Vendor that develops Smart Attachments for JIRA, Table Filter for Confluence, Awesome Graphs for Bitbucket and other add-ons. This blog post will highlight the capabilities for organizing the tasks and attachments in Atlassian JIRA with the minimal investments and maximal efficiency. The post intends to showcase how the synergy of two addons: JIRA Smart Attachecments and JIRA Email This Issue can help you in that.

More and more teams worldwide move to Atlassian JIRA for managing projects, running processes with pre-defined workflows, and tracking progress on tasks within the single platform.

The Atlassian Marketplace is the place that continuously aggregates all kinds of add-ons and augmentations that enhance user experience in JIRA and other Atlassian products.

In this blog post, we are going to feature two add-ons - Email This Issue and Smart Attachments. The first add-on can greatly simplify your communication with external customers of yours and the second one can efficiently manage different artifacts and documents that appear during these interactions.

Setting Up Email This Issue

This add-on works on the basis of the incoming and outgoing mail servers configured in your JIRA. For the incoming server you also need to configure the email handler which will process the incoming emails from your external stakeholders and submit them either as new issues or comments to the existing issues.

Additionally, you can define the issue email template. Here you can customize the HTML template, add Velocity code for additional issue fields, configure output of contents of custom fields into the email subject, and so on.

You can also configure all kinds of notifications that should go to external stakeholders or JIRA users upon occurrence of specific issue events. Optionally, you can define canned responses that people will receive as a confirmation for request submission, or any other event.

To better tailor email notifications to specific circumstances, you can define the context for triggering email notifications. Here you can select projects, issue types, JQL filters, applied templates, notifications, define the list of senders or email addresses that the context can be applied to.

Email This Issue provides sufficient capabilities to configure the email sending rules and define email templates applicable in each specific situation.

Managing Requests with Email This Issue

In our blog post, we will take a look at operation of the localization agency that handles localization requests through JIRA by using Email This Issue.

The customer from game development company usually submits requests with a bunch of files for localization by email. They can include some short video cuts, verbal cues of game heroes, some documentation and promo materials, as well interface resources for different audiences.

Usually, the average request contains from 8 to 10 files of different formats. This creates additional problems for localization managers to locate the files for translation, and then to choose the already translated files for sending to the customer.

Email This Issue add-on handles all these incoming requests and creates issues within the related JIRA project or posts new comments for the existing issues.

Organizing Attachments within JIRA Issues

Smart Attachments is a right tool that can help you to efficiently organize attachments in your JIRA issues.

This add-on lets you create attachment categories that can be further used for attachment distribution among them for quick accessibility. Additionally, you can define the issue types for displaying this or that category, as well as set up access restrictions for different users, user groups, or project roles.

By default, all the attachments from new requests are stored in the Files for localization category. To automatically distribute attachments across categories, the project administrator configured the post function that automatically sorts out files across multiple categories depending on file formats. This procedure is executed when the localization manager transitions the issue from Open to In Progress status.

Once the localization manager proceeds to translation of the attached files, he or she already has a clean view of different file formats stored in different folders.


Managing Localization and Attached Files

While uploading the localized resources, translators can use the capabilities of Smart Attachments for managing document revisions. This helps them to track separate document revisions, and they can always discuss some occurred issues with the team with the help of comment threads.

If various localization managers work on different content types, each of them selects the completed attachments that should be added to the final email to the customer.

This feature of Email This Issue allows the manager to quickly select the completed files while sending the email to customer. This keeps the consistency of issues and prevents the problem with sending old versions of attachments, or even their initial versions.

Sending the Confirmation Email to Customer

At the final stage of localization, the project manager usually writes the final email and re-sends all the localized files to the customer. Email This Issue allows him or her to do this without problems directly from JIRA. Here the project manager can specify the required recipients, select the appropriate email template, and manage additional parameters of the letter.

All the attachments stored within the Add attachments to email field will be automatically added to email and delivered to the customer.

The project manager can also view the whole history of email communication on the Emails tab within the issue.

Using Add-ons Together

Using Email This Issue and Smart Attachments together is not an option, but a must if you deal with multiple attachments that you exchange during email communication. Email This Issue add-on allows you to quickly and efficiently process incoming email and regulate the outgoing email notifications to external stakeholders. The capabilities of Smart Attachments allow you to bring order to dozens of attachments that appear during email communication, and which you cannot efficiently manage with native JIRA tools.

Try Email This Issue and Smart Attachments add-ons right now! /pages/viewpage.action?pageId=42795055

The Box is Good

It's like playing with LEGO. All you have to do is find the right piece and put it in the right place. It's pretty easy to build your first project, but it can get tricky when your teammates get excited about it and come up with tons of new ideas how to make it better and better. 

To Use the Box: Stay Inside

 As Consultants, we prefer staying in the box. The reason why we're superfast is not that we eat and train like Usain Bolt. It's because we know quite a lot of LEGO pieces that can solve seemingly difficult problems like charm. 

Our clients are amazed by the fact that we deliver working solutions within weeks. We start small, with one team of a few members and a well-defined business process. When the team starts using it, they either ask for more or brag to the other teams how incredibly productive they've just become.


But when there is no piece, we have to decide wisely. It takes too much time and effort and quite risky to build and maintain a custom developed feature. If you're in this business you know what I'm talking about. You have to ask the question: What exactly is not in the box? 

To Make the Box Bigger: Think Out of It

And that's where we draw the line between being consultants and being a vendor. As Atlassian Vendors, we have to think out of the box, sometimes even further. When we listen to our customers, or simply use Atlassian products, we look for patterns of missing pieces or situations where users do workarounds to solve problems. In UX, that's a clear sign that there's room for improvement. 

Sometimes, as vendors, we have to think like there was no box at all to eliminate frontiers of thinking. If you don’t know the box, you think differently. Just like non-technical users, who actually don’t know the box. But they know exactly what they're missing. That's why they use workarounds. 

So we think like our clients. The one thing we learned in our years in product development in other fields is that client feedbacks are golden nuggets only if you treat them wisely. They can be biased by their expertise in your product, their level of work stress, their overall interest in their own work and a lot more. That's the tricky part, where lots of vendors bleed out. We need to be crystal clear about what little missing LEGO piece we want to build and focus on polishing it like a diamond.

Little Things Help the Big Things

As Atlassian Consultants, we believe, that Atlassian products empowered by their existing add-ons have enormous possibilities. These power-ups make the already feature-rich basic tools even more versatile. And more importantly: these little things help the Big Things meet everyday or specialized business needs more accurately. /hu/2017/04/25/Atlassian+-+Olyan,+mint+a+LEGO

One of the most important benefits of the Atlassian ecosystem is the power of integration opportunities. The difference between using one or two Atlassian applications is not merely the additional functionality you gain form the the second one but also the new dimensions deriving from the synergy.

This post demonstrates the power of integration and explores how Atlassian products can be connected with HipChat making it the central source of notifications and a platform of team collaboration.

Before you create integration

Consider what you need: global or room based integration? Global integration apply to all rooms in your HipChat group. Per-room integrations apply only to the rooms in which you install them.

  • To install global integration, go to Group admin > Integrations. This takes you to the Find New page that lists available integrations.
  • To install per-room integration, go to Group admin > Rooms and select the room. Then, click Integrations in the left menu bar.
ToolIntegration Configuration
    • Get notifications in your HipChat rooms about issues.
      • Assignee updated
      • Someone leaves a comment
      • ...
    • Create a dedicated HipChat room from the issue you're working on and want to discuss with your team.
    • Preview JIRA issues and service desk requests directly in HipChat when someone on your team mentions them.

The JIRA and HipChat integration is packaged with JIRA 6.4 and later versions. For previous versions of JIRA or for the latest integration plugin go to the HipChat for JIRA integration plugin page and follow the installation instructions.

Before you start, make sure JIRA and HipChat server are behind the same firewall (integration uses both pull and push way). You can check the connection status between JIRA and HipChat (Connected, Limited, Not connected, Unknown).

Now you can link JIRA to HipChat

  1. Log in as a JIRA administrator
  2. Go to the JIRA administration console > Applications.
  3. Scroll down the page to the Integrations section and select HipChat.
  4. Select the link below Connect HipChat.
  5. Follow the instructions to link JIRA to your HipChat site.
  6. Once integrated, you can connect your JIRA projects to your HipChat rooms.

You can link JIRA projects with one or more HipChat rooms so that when issues are updated or created, messages are sent to the HipChat rooms that you specify.

  1. You must be a logged in as an Administrator or a Project Administrator.
  2. Choose Administration > Projects. 
  3. Select a project.
  4. In the Project Administration menu, select HipChat Integration.
  5. Choose a HipChat room and select Add.
  6. Select the Issue Type, Priority, or select Advanced to enter a JIRA JQL Query.
  7. Select the actions that will send a notification to your room (issue created, assignee changed, new comments, and issue transitions).
  8. Select to notify users (using HipChat notifications) when a message is sent to the room.
    Notify Users in This Room uses HipChat notifications (playing a sound, popups, and bouncing dock icon) to alert users of new messages sent from JIRA. This functionality is only available in the web and IOS clients.
  9. Changes are saved automatically, continue browsing your project to continue.

Private rooms

Private rooms in HipChat are by invitation only. In order to in connect JIRA to a private room in HipChat you will need to authorize HipChat from the HipChat Integration setup screen.

Once you have authorized JIRA, all of the private rooms that you are a member of will be displayed in the room selector drop-down menu. When your JIRA project and room are integrated, everyone in the private room will be able to see the notifications that are sent to that room.

Afterwards you can configure the following

  • This setting can be overridden for individual projects by users with Project Admin permissions.
  • Enables issue links or issue key mentions to be displayed in guest rooms.
JIRA SoftwareSame like JIRA (see above)

No need any JIRA Software specific settings

Planning Poker ( for HipChat is coming soon, it will be a very cool addon.

JIRA Service DeskSame like JIRA (see above)No need any JIRA Service Desk specific settings
  • Space - Room level integration opportunities (the HipChat integration lets Confluence send the following notifications to your HipChat rooms)
    • Page is created
    • Page is updated
    • Blog post is Created
  • Who is online
    • When you hover over a user mention or a byline it will show if the user is available in HipChat. Green, yellow and red icons indicate when someone is available, away or doesn't want to be disturbed.
  • First your organisation's HipChat account needs to be connected to Confluence. It only takes a minute.

    • You'll need administrator permissions for your HipChat group to do this.

    • If you're a Confluence admin go to > General Configuration > HipChat Integration and click Connect HipChat to get started.

    • If you're a Space Admin you can go to Space Tools > Integration > HipChat to get started. 

      • Using the Documentation theme? If your space uses the Documentation theme go to Browse > Space Admin > HipChat.

    • You'll need to be logged in to HipChat as a Group Admin to complete the integration.

  • You'll need Space Admin permissions, and if you are connecting to private HipChat rooms, you will need to log in to HipChat on the integration screen.
  • To set up space notifications go to Space Tools > Integration > HipChat and add a room to the list

You get Bamboo notifications in your chat room for events such as:

  • when a build passes or fails
  • when you are assigned responsibility for a breaking build
  • when a build you are responsible for has been fixed
  • when a manual stage of a build is ready to be run
  • when a deployment starts, and completes

...and many other notification events.

You can get Bamboo plan notifications in HipChat rooms:

  1. Specify the  hipchat.api.url system property that is used when Bamboo is starting. The hipchat.api.url value must be set to the URL of the HipChat.
  2. Set up plan notifications in Bamboo that use the 'HipChat' Recipient type.
Bitbucket ServerThe HipChat integration lets Bitbucket send the following notifications to your HipChat rooms
  • Pull requests
    • created
    • commented
    • merged
    • declined
  • Commits
    • pushed
    • commented
  • Select Administration Settings > HipChat integration
  • Using HipChat, click the link below the Connect HipChat button, enter your HipChat URL, then click Connect HipChat.
  • Log in to HipChat with an account that has admin rights. 
  • Click Install to finish installing the Bitbucket Server HipChat Addon.
  • Select the repository that you want to send notifications from, and the HipChat room where you want the notifications to appear.
    • You can choose multiple rooms to receive notifications from a repository but must add each connection separately. 
    • Repeat this process for all the repositories where you want to send notifications.
Bitbucket CloudThe HipChat integration lets Bitbucket send the following notifications to your HipChat rooms
  • Pull requests
    • created
    • commented
    • merged
    • declined
  • Commits
    • pushed
    • commented
  • Issues
    • created
    • updated
    • commented
  • To install or manage the integration from Bitbucket you need:

    • A HipChat account with access to the rooms which will receive notifications.
    • A Bitbucket account with one of the following:  
      • Individual account: you must own the repository you are trying to add the integration to you cannot just have administrator access.
      • Team: you must have administrator access to the team which owns the repository not just the repository you are trying to add.
  • Integration opportunities:
    • For a team, install from the team settings (Select Teams>Your team name then click Manage team) page, or a repository's Settings page.
    • For an individual account, install from a repository's Settings page
    • If you are using both team and individual account, do not forget to install the addon for teams and individuals too.
  • Steps of intagration:
    • Click HipChat integration.
    • Click Install integration and follow the onscreen instructions to install the integration.
    • Select the repository you want to send notifications from, and the HipChat room where you want the notifications to appear.
      • You can choose multiple rooms to receive notifications from a repository but must add each connection separately. 
      • Repeat this process for all the repositories you want to send notifications.
    • Select the notifications you want to receive.


Migration Stories

This article is part of our migration stories: a series of blog posts we are publishing here from time to time inspired by our projects we fulfill for our customers.

One of our customers (a huge European logistics company's Hungarian headquarter) has offices throughout Europe. However they wanted to federate their multiple JIRA instances into a single one. As part of this huge project, they requested us to migrate a certain projects of a live JIRA instance used in France into their main live instance hosted on their infrastructure in Hungary. JIRA's Project Restore capabilities seemed to offer a promising route to achieve our goals.

To be more precise on the situation we had to deal with, it is important to mention that the source JIRA system was a JIRA Cloud instance. First of all, we had to migrate from JIRA Cloud to an intermediate JIRA Server instance. This process will be covered by the next article in this series. Here we cover the migration of projects from JIRA Server to JIRA Server.

Alternatives to Migration

As the target JIRA system was a running live instance with many projects, it wasn't possible to do a full backup and restore operation. This could have been the easiest solution, but not for us here.

We had to rely on JIRA's Project Restore feature. If one reads through the docs, it will be clear how cumbersome this process is if you need to migrate many projects, using lots of different schemes, workflows, custom fields etc. The doc prescribes to manually create or configure almost all aspects of a JIRA project in the target JIRA system.

Having many projects and metadata all mingled with add-ons hidden in workflow transitions and custom fields, this looked to be several day of manual JIRA configuration. We have desperately searched for an alternative solution and ended up with adding this add-on to our mission: Project Configurator. This add-on has proved to be a life saver for us, see below why.

The Migration

After a few attempts, we have followed the below steps successfully. We presume the source and target systems are of the same JIRA versions. If this is not the case, we recommend you upgrade the source system to the version of the target one before the migration.

If the target system is of an older version than the source system, we recommend you upgrade the target system to the same version of the source.

Step 1 - Disable Emailing in the Target System

Before doing anything, we disabled sending and receiving emails in the target system.

You can disable all emailing by setting the below startup options in or setenv.bat:


Step 2 - Add-ons

There were add-ons in the source JIRA system that were not available in the target, so we installed them. It is important to have the add-ons installed before the migration as migrated components (workflows elements, fields etc) may come from add-ons. So it is crucial that these components may be created correctly during the migration phase.

Note, the add-ons configuration must be manually duplicated from the source system. Add-on persistent data is not restored during the data load when you restore only projects.

Step 3 - Migrate Metadata using Project Configurator

We were very happy to have Project Configurator add-on available as it proved to save lots of time and efforts. 

This is what you need to do to migrate metadata using Project Configurator:

Resolve Name Collisions

Rename all schemes, dashboards, filters, screens, workflows, custom fields, etc  if a corresponding entity exist in the target system with the same name but different definition.

E.g. if there is a Screen Scheme with the same name but different screenmapping, rename the scheme in the source system to prevent name collisions. Name collisions is not a problem for Project Configurator, it will simply overwrite the schemes in the target system. And this is certainly something you will want to avoid.

Export the metadata you want to migrate

Configure the export through Project Configurator's admin screen:

The export will create an XML file you will need in the next step.

Load the metadata in the target system

Before loading the metadata in the target JIRA instance, we strongly recommend you read at least this page in Project Configurator's documentation

Project Configurator allows you to load the XML file in a transaction that is rolled back. This is a simulation of the data load to reveal potential problems without corrupting the database.

if the simulation completes with errors, repeat the data load with "Apply changes?" turned on.


Important notes

Project Components and Versions:

  • By default Versions and Components are loaded by Project Configurator. We recommend you leave them out when you import the metadata. It is because when you import project data (see below), JIRA will stop saying, it cannot import project data into projects with existing versions and components. This means, you will have to delete all components and versions from the projects before the import can progress further.

Project configurator will migrate users, but there a few things to know:

  • user passwords are not migrated, users may have to use "Forgotten password" link upon first login to generate a new password
  • users are created in the first writeable user directory be it Active Directory / LDAP or JIRA's internal directory. Setting the order of user directories in the target system before loading metadata is important

Step 4 - Migrate Workflows

Even though recent versions of Project Configurator supports moving workflows, we used JIRA's Workflow bundle export and restore feature to move the workflows themselves. Workflow bundles are rich in terms of containing all elements of the workflow, including definition of the screens, custom fields used by the transitions,  and transition elements (e.g. post functions) added from add-ons. This is why it is important that all add-ons are available in the target system.

See details in the  documentation.

It is important to know that both the export and the import are very sophisticated. Warnings, explanations and settings are available. Importing the bundle you may opt for creating the missing statuses.



Step 5 - Restore Projects

Restoring projects requires you to create a full export (XML backup) in the source system and use "Project Import" in JIRA Administration / System to start the restore process.

Follow the steps detailed in the documentation.

Project import gives you detailed summary of the import result, and the potential errors allowing you to repeat the import after fixing the problems.

Important notes

We experienced that during the project restore process, the Create workflow transition in the issues' workflows is executed. This may have unexpected consequences.

If the Create transition contains post functions that initialize fields (e.g. assign issues, update custom fields etc), the issues that are imported will be reassigned to someone else, or fields will be overwritten.

E.g. if the Create transition has a post function from MISC Workflow Extensions: to assign the issue to the first member of a role, the issue will be reassigned unexpectedly.

Due this fact, you need to remove these post functions from the workflows before importing the project data. The easiest is to copy the workflows, modify the original ones and restore them in the workflow schemes from the copy after the data migration.

Step 6 - Add Mail Handlers

if the source system had mail handlers, you must add them manually to the target system in Administration / System / Incoming Mail

Step 7 - Enable Emailing and Restart

Finally, edit to enable emailing again and restart and reindex JIRA.

Backups and Restore Points Strategy

We recommend you do a system backup before each and every step listed above. If a step fails and you will have a backup version to restart from the previous step, it is a real time saver and relief. If JIRA and its database are running in a virtual server environment, creating snapshots of the systems are the best options. These operations are fast and reliable.


Due to the complexity and many aspects of Projects in JIRA, moving them from one JIRA instance to another is a cumbersome process that includes many manual configuration too, despite Project Configurator that helps a lot but cannot make everything smooth. However, if done with care and attention, the above steps will most likely let you complete project migrations in a more plannable timeframe. /x/gwBzAg

"Do you migrate to Atlassian?"  is a series of articles focusing on a typical customer project: migrating data and business logic from any kind of 3rd party solutions into the Atlassian ecosystem. The reasons and the source systems can be various that is why we try to collect as many real customer stories as possible. Stay tuned, maybe once a day during a migration project you will have a much easier and happier day thanks to tips&tricks we share here.

About the source systems

„Redmine is a flexible project management web application. Written using the Ruby on Rails framework, it is cross-platform and cross-database.”



Tool for

Project management

1st release in


Current version (release date)

3.2.0 (06.12.2015)


Open Source, GNU General Public License v2 (GPL)

Cost for 500 users



Ruby on Rails


Both cloud and own server version


Produced by

Jean-Philippe Lang

Demo site

Addons (729 plugins are available)

Reason of change

Our customer has already used Confluence for their internal knowledge base and document store. The integration opportunity of JIRA and Confluence was a good selling point, but the main reasons were the enhanced functionality and flexibility.

They found their old, Redmine-based system uncomfortable in the following aspects:

  • needed a sophisticated permission settings
    • which is easy to configure in JIRA with permission and security schemes
  • wanted to use e-mail for collaboratation for tasks
  • their monthly reward system was based on the reported working hours so needed deep worklog analysis and overview

Migration process

Most of the migration process was done in 6 super easy steps, as JIRA Importers Plugin (known as JIM as well) with JIRA Redmine Importer plugin were powerful tools with a handy user interface. (Due to privacy reasons we used only sample pictures below)

  1. Connection settings
  2. Projects mapping
  3. Custom field settings
  4. Field settings
  5. Values settings
  6. Issue links settings

Difficulties and solutions

Many project to one

Our customer used a lot different projects in the Redmine, but they decided to move all of the issues into only one project after the migration. Hopefully the "destination project" option makes this change very easy.

Disabled users

During the test migration we found some interesting log entry like this

 2015-08-05 10:14:27,489 WARN - Commenter named l***a.o***z not found. Creating issue with currently logged in user instead

After a small research we found the reason: the user was disabled in the Redmine. Enabling for the export phase was a quick solution.

JIM (JIRA Importers Plugin) log entries provide very detailed and helpful information, so this is one of the strongest part of the addon (see the example below).

First test migration
2015-08-05 12:56:29,826 INFO - Import started by admin using com.atlassian.jira.plugins.importer.redmine.RedmineDataBean
2015-08-05 12:56:29,850 INFO - ------------------------------
2015-08-05 12:56:29,850 INFO - Importing: Users
2015-08-05 12:56:29,850 INFO - ------------------------------
2015-08-05 12:56:29,850 INFO - Only new items will be imported
2015-08-05 12:59:00,807 INFO - 48 users associated with import. 47 new users were created and imported as active.
2015-08-05 12:59:00,807 INFO - ------------------------------
2015-08-05 12:59:00,807 INFO - Finished Importing : Users
2015-08-05 12:59:00,807 INFO - ------------------------------
Try an another export without deleting previously migrated users (testing just the data side)
2015-08-06 16:08:09,563 INFO - Import started by admin using com.atlassian.jira.plugins.importer.redmine.RedmineDataBean
2015-08-06 16:08:09,573 INFO - ------------------------------
2015-08-06 16:08:09,573 INFO - Importing: Users
2015-08-06 16:08:09,573 INFO - ------------------------------
2015-08-06 16:08:09,573 INFO - Only new items will be imported
2015-08-06 16:09:54,264 INFO - 48 users associated with import. 0 new users were created and imported as active.
2015-08-06 16:09:54,264 INFO - ------------------------------
2015-08-06 16:09:54,264 INFO - Finished Importing : Users
2015-08-06 16:09:54,264 INFO - ------------------------------

Multi user picker custom field migration error

There was a multi user picker field in Redmine called “Participants” for some issues. Unfortunately, instead of user names or ID-s we always got just unmatchable ID-s during the test migration. We reported this bug to Atlassian but they couldn’t reproduce the error.  Due to internal security rules our customer didn't allow Atlassians to enter into their system for bug tracking. So we had to correct these issues by hand after the migration

Update your Redmine and addons

As described in the documentation before starting the migration process ensure that both Redmine, and import addons are not too old versions

  • Minimum Redmine versions supported are 1.3.0+ and 2.0+.
  • Make sure that you are using version 5.0.2 or later of the JIRA Importers Plugin.
  • Enable the REST web service in Redmine in Administration > Settings > Authentication > Enable REST webservice, if you haven't already enabled it.

First time we forgot it, so we can prove that JIM really will not work with old version of Redmine, we had to upgrade it before its final shut down (smile)

Lessons learned

  • Great log information – error resolution is much more easy after reading the migration logs
  • Most of the original data can be migrated in a step-by-step procedure, so do not be afraid of the migration
  • Not only Redmine migration is so easy (Trac, Rally, Asana, Bugzilla, etc are supported), see the opportunities here

More details

If you are interested you can view a short video summary about this customer story (unfortunately only in Hungarian) recorded in the 2nd Hungarian Atlassian Meetup.


"Do you really know Confluence Permissions?" is a series of articles focusing on some rarely known, non-trivial and sometimes absolutely surprising aspects of Confluence Permissions. Stay tuned to learn everything we've found through our exciting journey to discover the absolute details.

Some Background

You may ask yourself, what is so exciting about Confluence permissions, it is well documented, you just set some flags on users or groups and you're done. However, we found this is far from being true.

Confluence permissions are not only have multiple levels (site, space, page) but they are interfering, they have effect on each other and often result in unexpected effective permissions that are hard to spot and understand in a Confluence instance.

In other words, effective permissions sometimes derive from implicit combinations of individual permissions. Or effective permissions are permissions users effectively have but not necessarily directly assigned.

Due to the levels and complexity of (effective) permissions, page restrictions, spread through your dozens or hundreds of spaces and pages in your Confluence instance, unwanted access to pages may be given to users or groups risking information leak. This is just one example for why understanding permissions is crucial to operate mid sized or large Confluence instances. 

In this and subsequent articles we'll show case examples and hidden secrets of Confluence's permission systems. And we'll show you how to manage permissions all over your Confluence site. Let's start our journey!

Information leakage in your organization

To carry on a Confluence, three things are necessary: keep the secret, keep the secret, and yet even keep the very secret... but sometimes your secret information is leaking.
According to Wikipedia: "Information leakage happens whenever a system that is designed to be closed to an eavesdropper reveals some information to unauthorized parties nonetheless."

Is it a common problem for organizations? We think it is. Let's see some examples:

  • If you google information leakage policy you can get huge amount of pages: ~ 7.760.000
    • just for fun if you google for Atlassian you can get ~ 9.330.000 pages
  • There are numerous article on the internet about big data breaches and information leaks of the history
    • even big companies (British Airways, Mozilla, NASDAQ, AT&T...) have faced with this problem as you can see on this beautiful infographics
  • "51% of employees believe safeguarding corporate information is IT’s problem, not theirs" reporting by Symantec
  • What are the primary causes of breaches? "42% employee mistake or unintentionally action" published on

Customers ask very often to do a kind of "Healthcheck" service on their Atlassian software. During these cooperation we found some "easy to understand but easy to mess up" configuration resulting information leak. This article is about 4 useful tips for preventing unpleasant situation for Confluence or Space Administrators.

New users can have permissions because of default groups

"confluence-users is the default group into which all new users are assigned. Permissions defined for this group will be assigned to all new Confluence users." - Confluence documentation about Confluence Groups.

So be careful creating user who is not a member of your organization, for example, an external partner . Maybe these users should not be members of confluence-users group because it grants them unwanted permissions by default that allow them to access spaces for internal uses. 


Every user have to have at least "Can Use" permission to log in to Confluence. So if you do not add them to any groups, you'll have to assign them this permission individually. Further details about this permission are here.

Be careful with default space permissions

Confluence makes it very easy to set up default permissions for newly created spaces. It can speed up the space creating process for Space Administrators. This setting can be found in the "Confluence administration" interface, under Space Permissions, Default Space Permissions (see the documentation here).

By default confluence-users is  granted with the following permission, and you can add or edit permissions for any groups as you like:

Most cases not only Confluence Administrators but also project leaders, department leads have Create Space permissions on their Confluence site. It decreases the load of IT support, and make your process faster, so we love this feature. But never forget to think over the visibility of the new space. If you are creating a very sensitive space - and have a supportive default permission settings good for most cases - after the space is created, delete everything from the Space Permissions and set up carefully with the proper ones.

If you work with extremely sensitive information we recommend you to delete everything (even confluence-users!) from the default space permission setting. Doing this guarantees preventing this kind of information leakage.

Check the global configuration to deny anonymous access

Confluence is also very handy tool for creating public access knowledge bases. This is provided by the "anonymous access" feature, so anybody can read the articles without logging in to the site. If your organization rules do not allow to access any content without login, check the global permission setting of the Confluence and deny the anonymous "Can Use" permission like this:

By unchecking "Can Use", anonymous can not access any space, any content, even if Confluence Administrators or your Space Admins accidentally granted any kind of space level permission in the Space Permission interface to the anonymous.

Always double-check a group permissions before adding a new user

Groups - as everywhere - can really speed up and make clear your permission settings. On the other hand never forget to double-check a group permissions before adding a new user/employee into it avoid unwanted access to important information. Group permission checking is not so easy in Confluence by default, because you have to go through all of the spaces and check the used permission settings one-by-one but there is an addon at the marketplace which can help you a lot.

Lessons learned

Confluence is designed for information sharing and collaboration

  • do not forget that new users can have unwanted permissions coming from their default groups
  • be careful setting up the proper permissions for sensitive pages and spaces, most cases the default settings can be too permissive
  • if your organization rules do not allow to access any content without login deny the Anonymous "Can Use" permission
  • never forget to double-check group's permissions before adding a new user/employee to avoid unwanted access

/pages/viewpage.action?pageId=38897004META-INF Ltd. is the creator of the Ultimate Permission Manager for Confluence.

A customer of ours (Morphologic Localisation Ltd), for whom we developed a JIRA addon many years ago to integrate JIRA with their legacy systems, has recently contacted us to help them upgrade their Confluence instance to the latest version. The first question that everyone would have asked was what version of Confluence they had.

The answer was quite shocking: Confluence 2.9. we got excited and afraid at the same time. Last time we saw a similarly old Confluence site was back in 2008 when we installed the first Confluence instance at SonyMusic in Munich.

Our customer was a kind we can wish for any consultant. It was very easy to communicate and to work with them. We did not even had to meet personally, we talked over the phone, used chat, but the trust was established the very first minute. We proposed T&M, they accepted it because they understood the complexity of the process and our arguments. So the job was doomed a happy ending.

A Vital Dinosaur 

When we first entered the Confluence site, we realized that the customer was a heavy user, they built a huge documentation and knowledge base system. Yet the good old Confluence 2.9 was so fast we could not believe my eyes. All pages opened in less than a second, they seemed like static HTML pages. All of this felt very abnormal in today's, modern, resource intensive fatty systems including JIRA and Confluence.

Interestingly Confluence Download Archive still lists almost all versions back to 1.0.3 released in 2004(!). It is very impressive to see how old Confluence is and what a tremendous amount of work and functionality had been incorporated into this product. The below chart shows how the size of Confluence Standalone distribution changed over time. Yes, it started as a 19MB(!) package in 2004. While version 5.9.4 is almost 440MB(!). A 23 times bigger giant.


It as also very astonishing to see how Atlassian imagined the UI back in 2009 when Confluence 2.9 was released. It was so simple, pure, oldish, lack of any eye-candy features. Still we remembered how impressed we were in 2008/9 about the beauty of Confluence UI Atlassian had developed at that time.

We still remembered the old Rich text/wiki markup editor with many-many bugs, limitations, annoying behaviours. Luckily it had passed away and Atlassian developed an uncomparably better editor we can enjoy today.

we wanted to install Confluence 1.0.3 out of pure fun too to see the very first screens, we have found an old evaluation license from 2005 in my MAC account which was accepted by Confluence 1.0.3. However, after configuring database connections, Hibernate threw a bunch of exceptions and Confluence could not complete database initialization. Probably java 1.7 was not good for that. This is how Confluence 1.03 install screens looked like.

Even Confluence 2.9 looked quite funny comparing to what we know Confluence like:

The Upgrade Process

It was obvious that the upgrade cannot be done in a one huge jump from 2.9 to 5.9.4, but rather in three stages as advised by the Confluence Update Documentation

Our customer wanted not only to upgrade Confluence, but also to move it to totally new server environment replacing the old mysql database with Postgres too. Therefore we have not followed the documentation word-by-word.

There were two aspects that made the upgrade process less complex:

  • The customer did not have any thirdparty addons deployed in their old Confluence instance
  • They could stop using Confluence for upgrade process. This meant we did not have to do a test upgrade first but updated their production system immediately. As we moved to a new server, the old system could remain intact.

Upgrade from 2.9 to 3.5.13

First, we created an XML backup from the old Confluence 2.9.

We selected the latest minor build of 3.5.13 that was downloadable. We manually installed it in the new server environment using an empty Postgresql database.

Once it was running we simply performed a Restore from XML backup. Confluence 3.5.13 could upgrade the content easily without any problems.

Upgrade from 3.5.13 to 5.0.3

The above steps were repeated:

  • XML export from 3.5.13
  • Install Confluence 5.0.3 manually (not with the installer) an empty database
  • Import the XML backup and let Confluence perform the upgrade

It completed again without any problems. 

We felt we were close to a successful upgrade.

Upgrade from 5.0.3 to 5.9.4

Again the well known steps:

  • XML export
  • Install 5.9.4 this time using the installer as it was supposed to be the final instance, empty database
  • Import the XML backup and let Confluence perform the upgrade

All went fine. However all content was imported without attachments.

Upgrading Attachments

Confluence 2.9 already stored attachments in the Confluence home directory. However the structure of the attachment directories was totally different from what Confluence 3.5.13 required. In the stage of 2.9 to 3.5.13 the attachments were not converted to the new directory structure.

Luckily this is something that might have happened to others as well. Most probably this was the reason Atlassian added a tricky feature to restructure attachments from the old format to the new, calling: CONFLUENCE_BASE_URL/admin/restructureattachments.jsp

It restructured the directories in a second. Later when I upgraded 3.5.13 to 5.0.3 and then 5.0.3 to 5.9.4, we simply copied the new directory structure over and all was fine. Well, almost. Space logos and user avatars were missing.

Googling the internet for an hour did not yield any useful information. Browsing again and again the old Confluence home directory, we noticed there was a folder called "nonspaced" in the attachment folder, which proved to be relief. After copying it to the server, space logos appeared properly.

However, we could not manage to restore user avatars. We were searching, googling a lot but could not find an answer for the question where Confluence 2.9 stored user avatars.

If you know where user avatars were stored in old Confluence versions, please let us know.

Post Upgrade Tasks

After completing the upgrades, some manual reconfiguration had to be done:

  • Confluence Mail Archiving system addon was disabled somehow during the upgrade, hence all mail accounts that used to work in Confluence 2.9 had to be reconfigured after enabling the addon.
  • I had to assignee a lot more memory to Confluence. 2.9 was happily running on 384MB, 5.9.4 got 1.5GB.
  • Confluence base url had to be reset to the live url


There are a few consequences to draw from the above experience:

  • Even the very old Confluence sites may be upgraded to the latest version in a few hours
  • Lack of addons made it much simpler
  • Space logos and user avatars need special attention.

Despite the powerful server environment, Confluence 5.9.4 is far from the performance of Confluence 2.9. Yet, none would like to work with the old version. Confluence has emerged to be one of the best tools for collaboration, knowledge management. With its plenty of features, nice user interface, integration capabilities make it a lot more powerful product that is fun to work with.


We are happy and proud to announce that Atlassian has qualified us as Verified Vendor! We are the only one in Hungary as of now!

"Ok, congrats!" - you could say - "But what's in it for me?"

More than you could imagine! Let me sum up the criteria Atlassian requires all vendors to meet to become Atlassian Verified and how we meet them. 



Paid via Atlassian add-ons are installed in at least 500 active instances

This is a tough requirement hard to meet. It means vendors have a massive customer base, in other words they are important part and contributor of the Atlassian ecosystem.

We have two such a product:

Atlassian product compatibility quaranteed

Vendors must guarantee that all of their Paid via Atlassian addons are made compatible with the latest versions of Atlassian products in 14 days after their release.

Be assured we work hard and devoted to meet this requirements. 

Documentation and Support URLs

Vendors must publish their support and documentation URLs for all Paid-via-Atlassian addons and allow anyone register in a support system and submit questions, problem reports, or feature requests.

Our documentation and support URLs are available here: 

Transparent Support conditions and SLAs

Vendors must provide clear conditions and SLAs they undertake and guarantee for their customers.

Our support is available at least 8 hours a day, 5 working days a week in our local time zone for all paid-via-Atlassian add-ons. 

We use JIRA to resolve and track customer reported bugs and feature requests, for all paid-via-Atlassian add-ons.

Feel free to reach us with questions, requests or reports. We will listen.

Emergency Contact

Vendors must provide 24/7 emergency contact channel towards Atlassian and guarantee response time not more than 15 minutes in case something goes really wrong or critical concerning the Paid-via-Atlassian addons.

We have established a direct telephone and email hotline that Atlassian regularly tests to see if we keep our promise to respond in 15 minutes. So far we succeeded (smile)

What comes next?

This is not the beginning - but a very remarkable milestone - of a beautiful friendship (Source: Black cat white cat (smile) ) and a guarantee of proficiency our customers can trust! (smile)

Confluence permission? Content export needs? E-mail collaboration in JIRA? Or decreasing e-mail notifications? 

Check our Atlassian addons now, maybe one of them is an answer for your problem to be solved. /pages/viewpage.action?pageId=38896256

"Do you really know Confluence Permissions?" is a series of articles focusing on some rarely known, non-trivial and sometimes absolutely surprising aspects of Confluence Permissions. Stay tuned to learn everything we've found through our exciting journey to discover the absolute details.

Some Background

You may ask yourself, what is so exciting about Confluence permissions, it is well documented, you just set some flags on users or groups and you're done. However, we found this is far from being true.

Confluence permissions are not only have multiple levels (site, space, page) but they are interfering, they have effect on each other and often result in unexpected effective permissions that are hard to spot and understand in a Confluence instance.

In other words, effective permissions sometimes derive from implicit combinations of individual permissions. Or effective permissions are permissions users effectively have but not necessarily directly assigned.

Due to the levels and complexity of (effective) permissions, page restrictions, spread through your dozens or hundreds of spaces and pages in your Confluence instance, unwanted access to pages may be given to users or groups risking information leak. This is just one example for why understanding permissions is crucial to operate mid sized or large Confluence instances. 

In this and subsequent articles we'll show case examples and hidden secrets of Confluence's permission systems. And we'll show you how to manage permissions all over your Confluence site. Let's start our journey!


Brief summary of the situation:

  • Ben is a user on your Confluence space
  • Ben isn't a member of any group in your Confluence (but he has Global Use access, so he can log in)
  • Ben is a member of your security team, and he is responsible for managing Page restrictions
  • So you - as a Space Administrator - set up Ben a "Restriction Add/Delete" permissions in the Space Permission (as you can see below)

That's looks great, isn't it?

Not really... Sooner or later Ben will definitely send you an error message "Hi, unfortunately I couldn't manage any Page Restriction (see the attached print screen). Please correct it"

What is wrong with the permission setting? You followed the "Principle of least privilege", set up the needed permissions, but Ben is an unhappy users, he could not do his job.



A user couldn't manage page restriction despite having a Restriction Add/Delete permission in the Space.



Believe it or not, you have to add a "Page Add" permission to Ben.

Setting up a Restrictions Add/Delete and Page Add permission for Ben as you can see below:

leads to the wanted permissions, so Ben can manage the page restrictions.

Are you surprised? We definitely were (smile)

Lessons learned

Never forget to add Page Add permission to a user who has to manage restrictions on you Confluence Space

/pages/viewpage.action?pageId=38895991META-INF Ltd. is the creator of the Ultimate Permission Manager for Confluence.

Don’t worry, it’s not so terrifying news as you think!

Publishing JIRA7 maybe the biggest change in the history of the product. Atlassian announced to separate JIRA into 3 different products targetting different types of teams

  • JIRA Core, for business teams
  • JIRA Software, for agile teams
  • JIRA Service Desk, for support teams


We collected some useful information to help you understand the significant changes and benefits that JIRA's new variations bring to all customers.

Your existing maintenance of JIRA will be renewed as JIRA Software by default

Renewal as JIRA Core or JIRA Service Desk must be submitted to Atlassian, feel free to contact us, we are ready to help you with your renewal.

Role of the products on the market

JIRA Core is the most similar to what you've known as pure JIRA. However, it is tailored to better suit the needs of Business Teams, for instance HR ,Finance, Procurement, etc.

JIRA Software is the combination of JIRA and JIRA Agile in a single product. It comes with all typical functionality that Agile Teams need.

JIRA Service Desk is the combination of JIRA and the former JIRA Service Desk addon, in a brand new and improved package. It will suit the needs of most Support Teams out-of-the-box. 
If you need more detailed information, read the following manual:

Upgrading your license from JIRA6 to JIRA7

The process is not so difficult. Atlassian published a very detailed manual about changing you licenses,  the documentation can be found here (

Specialized products for unique needs of different teams

Agile teams, business teams or support teams can have totally different feature requests in JIRA. Atlassian created separate developer teams for the 3 new JIRA products focusing on the target groups expectations.

All variations of JIRA brings different default workflows, issue types, project types and UI elements for the target teams

You may pay less for your JIRA's license and maintenance!

You can buy different user tiers for the 3 product.

Imagine a situation: Your team contains 20 developers, and 15 business worker. In the past you had to buy 50 users JIRA and 50 users JIRA agile. Now, you can buy 25 users JIRA Software and 25 users JIRA Core. So you can save 25 users JIRA Software license cost!

Even addon licenses may become cheaper!

Your addon user tier must be adjusted for the biggest user limit of the 3 JIRA product, so if you have 25 JIRA Software and 50 JIRA Core users, you don’t have to buy addons with 100 users, but only with 50 users!

Contact us - we'll listen

if you happen to have questions you cannot find answer for, feel free to contact us. We are always listening and will try to help you. /pages/viewpage.action?pageId=38895883

We are Atlassian Experts in Hungary since 2007. We believe in the uniqueness of Atlassian and the Atlassian Ecosystem. This makes us passionate about what we do every day. With our many years of experience, we help companies work more efficiently, improve their processes and unleash their corporate potential with the best suite of tools available. Additionally to our services, we build very popular, award winning extensions to Atlassian products that target special requirements and make your work even more efficient and fun.

During 2015 we decided to (re)start our Atlassian Expert Blog to support the Atlassian Community with spreading our knowledge and experiences. Stay connected and learn how you can use the Atlassian ecosystem event better.

We are planning to cover the following topics

  • practical tips & tricks
  • case studies and customer stories
  • news about Atlassian and Atlassian products
  • Atlassian Marketplace addon test and review
  • META-INF news
  • other relevant, interesting topics

Do you miss anything? Are you really interested in anything special? Or do you have a great story? Tell us, let's create the next great post about it! /pages/viewpage.action?pageId=38895877