Consider, if you will, a non-technical member of staff.  They have been tasked with writing promotional materials for your organization’s new software offering.  In order to do so, they will need to speak the technical capabilities and nuances of the product.  They have entered… the Developer Zone.

Rod Serling may be gone, but his legacy lives on wherever there is a disconnect between two worlds. In our case, the disconnect is between technical and non-technical persons.  The challenge is to connect those groups without alienating either one; non-technical people may find themselves overwhelmed with jargon, and technical staff may find it difficult to dedicate time to teaching nontechnical staff about the nuances of a product.

Knowledge Management can be the bridge between these worlds.  Let us examine.

The goal of Knowledge Management is not simply to collect data; as we have previously discussed, the role of Knowledge Management is the consistent and considered application of information and ideology, in keeping with the ultimate goals of an organization.

When two different groups need to exchange information, Knowledge Management can act as a mediator.   A robust Knowledge Management system allows for the asynchronous transfer of information; the two groups need not

How much does your organization value the ability to say, “I don’t know”? Is wilful ignorance a core tenet of the institutional ideology to which your employees are subject?

The advantage of an effective Knowledge Management strategy is that as issues arise, the solutions to those issues may be catalogued.  By resolving the issue and cataloguing the solution, the issue becomes an asset. The ability to solve the problem becomes part of the institutional memory of the organization. That ability may be monetized or harnessed, and the wheels of capitalism may continue to turn.

The disadvantage of an effective knowledgebase is that the organization no longer gets to claim ignorance of that particular issue. By cataloguing the ability to address an issue, an institution lays claim to some responsibility for it.   In other words, it’s harder to pass the buck when the tools to address the issue are at hand.

This is a cynical viewpoint, but business is cynical.  Let us consider an example.

In the context of a business that relies on volume, speed is king.  One such example is a low-level call centre.   Employees must meet the minimum standard to address a customer’s issue, in such a way

The ultimate goal of Organizational Knowledge Management is not to collect, store, and curate information.  Those tasks are a means to the end with which Knowledge Management ultimate concerns itself:  application of ideology.

All industries benefit from a focus on consistency, in both material and conceptual spaces. Knowledge Management is the facilitation of clean, ideologically consistent information. The ultimate fate of that information is the prerogative of the rest of the organization; Knowledge Management is only concerned with how the information is perceived and presented.

All effective organizations have a consistent ideology by which they operate.   Effective ideology is symptomatic of the deliberate fostering of a workplace culture, which manifests as a central source of truth (i.e. a knowledgebase).   Consistent information is the means by which all organizations may move and grow in the same direction; inconsistent information causes organizations to move in different directions, resulting in stagnation or inefficiency.

Knowledge Management is ultimately the application of a consistent ideology at an organizational level. When policy dictates that an organization has a single source of truth, the job of Knowledge Management is to ensure the consistent application of a workplace’s culture and ideology. While Knowledge Management is the application


I worked in an inbound call centre for three years.  I worked as a Level 1 analyst, meaning that the work I was doing was intended to resemble all of the previous calls that I’d taken. In other words, I wasn’t paid to come up with creative or unusual solutions.

 In that time, I learned that there were three ways that clients could quickly become upset:

  • Getting the runaround. There are few ways to upset a call centre client more quickly than causing them to feel that they are being shuffled around between people who don’t know the answer, or don’t care about their issue.
  • Getting the wrong answer. Clients rarely got upset when they were told by a rep “I’m not sure, I’ll have to check on that”.   What would upset them is if the representative confidently presented them with the wrong answer, and the client had to call back later to rectify the issue.
  • Getting inconsistent answers. Possibly even more so than getting the wrong answer, clients got very upset when they were told different things by different phone reps.   This was often the result of the phone rep working from memory or making assumptions.

All three

Knowledge Management exists to support an organization’s larger efforts.   That is, it serves to further the larger goals of the organization; Knowledge Management is not the final goal, and rarely is captured knowledge an end unto itself. Unless an organization exists solely to capture information in something like an archival effort, there is almost certainly a larger organizational goal.

It follows that the Knowledge Management team must have strong insight into how the rest of an organization works.  Knowledge ebbs and flows, and the team must be able to both capture information, as well as make it available in an appropriate and timely manner.    

What is appropriate when it comes to access to knowledge? Not all information is destined to be made available to all work units.  It can reasonably be said that there is a hierarchy of sensitivity, and some information meets the criteria to be protected.  The Knowledge Management team must strive strike a balance between total access to information, and creating information silos.

All of that to say, the Knowledge Management team must have insight at every level of an organization.  It must be able to not only ingest and digest data, but must also have


There may come a day where you need to script the migration of permissions from one Confluence Space to another.

The permissions of a Confluence Space can be retrieved and treated as collection of objects.  This allows us to easily pass them on to a source page as a new set of permissions.

The Code

We’re using the Soap Service to affect change in the permissions of a Space.  After using the ComponentLocator to declare the SpaceSoapService, we retrieve the source Space as an object.  We do the same for the destination source.

The permissions of the source Space are then extracted.  This is not a single object, but rather a collection of objects.

We iterate through each of the permission objects.  Each object is a collection of attributes.  We need to determine if the permissions object relates to a single user, or a group.  Every type of permission gets it’s own object.

Permissions objects associated with a group look like so:


The first attribute is the permission type.  The second is the permission ID. The third element is the group with which this permission is associated, and this is where the format of the permissions object differs



All Confluence Spaces have a sidebar, in which you’ll find the page hierarchy as well as any useful links that the Space Administrator has seen fit to add. 

Unfortunately Atlassian provide no clearly documented way of programmatically adding links to the sidebar of a Space.   That doesn’t mean it’s not possible, but rather that Atlassian haven’t seen fit to document how it may be accomplished.


The question now facing us is “how are links added to a sidebar when using the Confluence web interface?” If we can answer that question, we can programmatically replicate it.

This question is answered over the course of three steps:

1. We first add a shortcut to the sidebar of a Space, using the main Confluence interface.  When we do this, we can watch the network traffic that is generated by this request, and tease it apart to determine the actions we must take to replicate it.

2. By inspecting the Network Traffic, we can extract the CURL request that was sent to the Confluence server. From the CURL request, we can extract the target link:


This is the link that the Confluence web interface uses to communicate the desired change


If I wanted to perform a search of Jira using Groovy and ScriptRunner, I might make use of the SearchRequestService.  This class contains many useful methods, most of them having to do with filters. 

A great many of these take a JiraServiceContext as an argument.  For example, these are the parameters of the createFilter() method:

  	createFilter(JiraServiceContext serviceCtx, SearchRequest request) 

At this point you might start to wonder what a “Jira Service Context” is, and for good reason. Atlassian has once again failed to document exactly what they want, or how to provide it. There is nothing in any of the documentation about what exactly this argument is.  The arguement has it’s own page in the documentation, but that contains no useful information on actually implementing or understanding this parameter.

This is a recurring theme with Atlassian and their APIs.   Rarely is the official documentation helpful or complete; instead we must rely on the kindness of strangers on the internet who post code snippets.  That’s one of the major reasons I started posting the Groovy code that I wrote for Atlassian products; the vendor sure isn’t providing any help, and hopefully what I write will be of help



It’s surprisingly difficult to simply return a list of administrators for a Jira project.    I had to hunt for a relatively simple way to accomplish this.  In the end I found a snippet to build on, written by Mark Markov and located here on the Atlassian forums.

I initially got frustrated because I was looking to return all of the administrators using the libraries that deal with permissions.  Permissions and roles are two very different things in Jira; permissions are set up using a permission scheme, and applied to more than one Jira Project.  Roles and Users are specific to each Project.

Returning the users in a Projec role requires the use of several libraries.   Outlined below are two pieces of Groovy code for accomplishing this.  The first returns all users in a given role, across all of the projects in Jira.  The second returns the users in a role for an explicitly defined project.

The Code (Return all jira users in a role)

As always, we start by declaring our imports.   The foundation of any Jira or Confluence Groovy script is the Component Accessor. We’ll also need the Project Manager and the Project Role Manager


This script retrieves all the members of a supplied Confluence group, and then retrieves the timestamp of the last time that user logged in to Confluence.

The Code

As you can see from the code below, we’re working with three classes.  The usual Component Locator, the Login Manager, and the Group Manager.

After telling the Component Locator to fetch the Login Manager and Group Manager, we feed the name of a group to the getGroup() method of the Group Manager.  This returns a group as an object.

We also need to define an array that will hold our results. This is because the ScriptRunner console doesn’t easily provide output; you can’t simply throw in a System.out.println().   If you try to use the log as output, it truncates after 300 results.  Instead we need to add the results to an array, and then return the array at the end.

The group object we created is passed to the getMemberNames() method of the group manager, which unsurprisingly returns the names of group members.

Next a for-each statement takes each user in the group and uses the getLoginInfo of the Login Manager to get the login information of each user.

Finally, within