To get a better idea of what was causing this "multiple primary key" issue, we've made the Postgres DB log all statements executed during packin for the kanbanboard plugin.
The following statements relate to the kdb_kanbanboard_trl table being created and failing:
2025-11-25 14:47:27.107 CET [13770] adempiere@adempiere LOG: execute <unnamed>: CREATE TABLE KDB_KanbanBoard_Trl (AD_Client_ID NUMERIC(10) NOT NULL)
2025-11-25 14:47:27.226 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN AD_Org_ID NUMERIC(10) NOT NULL
2025-11-25 14:47:27.336 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN Created TIMESTAMP NOT NULL DEFAULT getDate()
2025-11-25 14:47:27.784 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN CreatedBy NUMERIC(10) NOT NULL
2025-11-25 14:47:27.941 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN Description VARCHAR(255) DEFAULT NULL
2025-11-25 14:47:28.050 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN IsActive CHAR(1) NOT NULL CHECK (IsActive IN ('Y','N')) DEFAULT 'Y'
2025-11-25 14:47:28.310 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN KDB_KanbanBoard_Trl_UU VARCHAR(36) DEFAULT NULL
2025-11-25 14:47:28.311 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD CONSTRAINT KDB_KanbanBoard_Trl_UU_idx PRIMARY KEY (KDB_KanbanBoard_Trl_UU)
2025-11-25 14:47:28.527 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN Name VARCHAR(60) NOT NULL
2025-11-25 14:47:28.641 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN Updated TIMESTAMP NOT NULL DEFAULT getDate()
2025-11-25 14:47:28.782 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN UpdatedBy NUMERIC(10) NOT NULL
2025-11-25 14:47:28.925 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN KDB_KanbanBoard_ID NUMERIC(10) NOT NULL
2025-11-25 14:47:29.038 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN AD_Language VARCHAR(6) NOT NULL
2025-11-25 14:47:29.135 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN IsTranslated CHAR(1) NOT NULL CHECK (IsTranslated IN ('Y','N')) DEFAULT 'N'
2025-11-25 14:47:29.240 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD COLUMN KDB_KanbanCard TEXT DEFAULT NULL
2025-11-25 14:47:29.561 CET [13770] adempiere@adempiere LOG: execute <unnamed>: ALTER TABLE KDB_KanbanBoard_Trl ADD CONSTRAINT KDB_KanbanBoard_Trl_key PRIMARY KEY (KDB_KanbanBoard_ID,AD_Language)
2025-11-25 14:47:29.562 CET [13770] adempiere@adempiere ERROR: multiple primary keys for table "kdb_kanbanboard_trl" are not allowed
Looking at the order in which these columns are created, they fit their order of declaration in the PackOut.xml file found in: /META-INF/2Pack_1.0.0[KDB/dict/PackOut.xml]
We can see that there's indeed two primary keys being created: the first one on (KDB_KanbanBoard_Trl_UU), the second on (KDB_KanbanBoard_ID,AD_Language).
However, browsing the PackOut file indicates that only (KDB_KanbanBoard_ID,AD_Language), the KDB_KanbanBoard_Trl_key index/constraint, is meant to be a primary key (XML: <IsKey>true</IsKey>)
The UUID column is NOT marked as such, yet the system seems to force a primary key on it anyway.
Our theory currently is that something in the incremental pack-in process is trying to create a primary key at the earliest opportunity for tables it is constructing that don't have one already.
This would explain why we can see the Postgres log of the pack-in process above add a Primary Key constraint on the _UU column, and then collapse when another primary key, the intended one, is created afterwards.
We believe this may be a change made sometime since IDP version 9, as we didn't encounter such an issue on deploying the kanbanboard plugin on an IDP v10 instance previously.
We haven't found the code responsible for this "early PK creation" issue.
In any case, the kanbanboard plugin seems to be broken on IDP version 12 because of this, as the pack-in fails and rolls back.