In this page

When should I use this?

Sometimes you may want to manipulate commit policies directly through the underlying database. For example:

  1. Initialize policies by creating new policies (even by cloning existing ones) for existing Jira projects.
  2. Automate policy management by creating new policies for every newly created Jira projects.
  3. Mass-update existing policies.
  4. Implement some type of integration or external tooling.

Please note that this technique should be the last resort only for those use cases that cannot be solved using the user interface or the REST API features.

Running SQL

Running SELECT queries

You can safely run queries against our tables in any situation.

Running INSERT, UPDATE, DELETE statements

As a general practice, it is recommended to shut down Jira while inserting, updating and deleting database records. The idea is to avoid problems caused by concurrent writes and by data both cached in the JVM memory and stored in the database.

We realize shutting down Jira is impractical in case of Jira instances with zero downtime allowed. In our experience, this is safe to modify the data in our tables even with Jira running!

Why so?

  1. Concurrent writes has very little probability: writes are super-fast, and policies are not modified frequently via the user interface any way.
  2. Our data is persisted using ActiveObjects (AO), the standard persistence technology for Atlassian apps. In our experience, AO loads the most current data from the database immediately after the updates. Data caching does not cause problems.

Database tables

Global configuration

The global configuration is stored in the table AO_764F4D_GLOBAL_CONFIGURATION. It has trivial columns, but this is very unlikely that you'd want to manipulate this table directly.

Commit policies

There are 3 tables to store the policy-related information:

  1. AO_764F4D_COMMIT_POLICY

    This is the top-level entity. Columns are totally trivial (thus not described here), only FLAGS requires explanation. It is a bit array with the following flags:

    • DISABLED (bit 0): whether policy is disabled
    • BYPASS_ALREADY_VERIFIED_COMMITS (bit 1): whether the commits already in the repository on another branch should be accepted without verification (since 3.0.0)
    • BYPASS_MERGE_COMMITS (bit 2): whether merge commits should be accepted without verification (since 3.0.0)

    Example: if you wanted to bypass already verified commits, FLAGS = 2. If you wanted it be disabled, as well, FLAGS = 2 + 1 = 3.

  2. AO_764F4D_COMMIT_RULE

    "Rule" is a child of the "policy" entity. (In other words, a policy contains any number of rules.) Make sure that the COMMIT_POLICY_ID value points to an existing policy.

    Fields are trivial. Please note that pattern type values either start with GLOB: or REGEX:, depending on their type.

  3. AO_764F4D_COMMIT_CONDITION

    "Condition" is a child of the "rule" entity. (In other words, a rule contains any number of conditions.) Make sure that the RULE_ID value points to an existing rule.

    Also note that each condition type has a custom set of parameters, which are JSON-encoded in the SERIALIZED_PARAMETERS column. For latest supported CONDITION_TYPE names and their parameter formats, we recommend you to create some configurations using the user interface and study the underlying data structures. It will be trivial, like this: 

    {"pattern":"GLOB:{alice,bob,charlie}@midori-global.com","attribute":"EMAIL"}

Questions?

Ask us any time.