Atlassian Jira. Admin evolution. Part 7

[#1]

Part 6

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

Database

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"/> 
</entity> 

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

[Taranjeet Singh]

Great work @Alexey Matveev !