AO table inaccessible in plugin after creation

Jira Development Jira Server
1

I have added an AO table in my plugin.
The table creates itself correctly when initializing the plugin and after the table is created, an upgrade task is run to migrate existing data to the new table.

In most cases (in dev, staging and almost all customer installations), the plugin can access the AO table correctly.

I wrote “most cases” because in one particular customer’s case, the AO table was created but whenever the upgrade task tries to create a record in the AO table, the following exception occurs:

Database:
	- name:Microsoft SQL Server
	- version:11.00.7462
	- minor version:0
	- major version:11
Driver:
	- name:Microsoft JDBC Driver 7.2 for SQL Server
	- version:7.2.1.0
com.microsoft.sqlserver.jdbc.SQLServerException: Cannot find the object "AO_12345_PLUGIN_TABLE" because it does not exist or you do not have permissions.
	at com.atlassian.activeobjects.internal.EntityManagedActiveObjects.create(EntityManagedActiveObjects.java:102)

The rest of the stack simply points to the upgrade task

I have confirmed with the customer that the table exists, so my guess was that this is a security issue but I haven’t found where the issue could come from precisely.

Has anyone else had this kind of issue or has hints of what I could look at?

Thanks in advance!

2
  • Update -
    It seems every time the upgrade task is called, a single entity is created (row added to the DB), then the next one throws the exception.
3

Issue found, to whomever it might interest:
Our upgrade task identity inserts values.
The issue comes from Jira not specifying the table’s schema when trying to deactivate the identity insert and the customer created a custom schema for Jira.

Here is a sample of the query causing the issue:

SET IDENTITY_INSERT jira.AO_12345_TABLE ON
INSERT INTO jira.AO_12345_TABLE (ID) VALUES (?)
SET IDENTITY_INSERT AO_12345_TABLE OFF
4

AO Issue found here: [AO-710] - Ecosystem Jira
It’ll probably never get fixed so if anybody else gets this issue, I suggest you ask your customer to either change the user’s default schema to whatever schema he configured or use the default dbo schema.