Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Atlassian Jira. Admin evolution. Part 7

Part 6

In this part we will start changing our solution to make it better.


As you can remember we created the user_managers table in the database using a Postgres database manager. This is a bad solution because:

  • you need to remember that this table should be created manually, if you move Jira configuration from one Jira instance to another
  • if you take a backup via Jira xml export, this table will not be present in the backup
  • a new Jira administrator will know nothing about this table unless it is written in a document and the new Jira administrator reads this document. I am myself very much against documenting solutions. Solutions must be understandable without reading documentation.

How could we create our database table in a better way?

You can find the WEB-INF/classes/entitydefs/entitymodel.xml file. This file contains the description of tables in the Jira database. Here is an example:


We can add our own table via this file. We could also define the primary key of our table, indexes but for the sake of simplicity we will use just this definition:

<entity entity-name="user_managers" table-name="user_manager" package-name="">        <field name="user" col-name="user" type="long-varchar"/> 
<field name="manager" col-name="manager" type="long-varchar"/> 

Also we need also to add information for our table into WEB-INF/classes/entitydefs/entitygroup.xml

<entity-group group="default" entity="user_managers"/>

Now we need to restart our Jira server. After it you can find the user_managers table in the Jira database.

Why is this way to create a table in the Jira database better than the first one?

Because right now you can take a backup of your Jira and restore your Jira without loosing the user_managers table. But what are the drawbacks?

  • We need to restart our Jira server to have a new table and this restart will make our Jira server unavailable for users.
  • To get rid of the Jira table we need to rollback changes in the entitymodel.xml and entitygroup.xml files, remove the table from Jira database and restart the Jira server. Again it will make our server unavailable for users.
  • If we want to move our configuration from one Jira Server to another we need to move our two files: entitymodel.xml and entitygroup.xml.
  • If we update our Jira Server then we need to add our new tables to the new entitymodel.xml and entitygroup.xml files. We can not simply update the new files with the old ones because we can loose changes which were introduced with the new Jira version.
  • We need to document our solution so that a new Jira admin know what to expect.

As you can see we still have many things to handle. I would not recommend this solution. We will talk later what would be a better solution.

Part 8

1 comment


Log in or Sign up to comment

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you