Content
Will a custom table added to an OpenProject database get removed by upgrade
If I wanted to create a plugin that required storing data in a structure that is not covered by the OpenProject database, can I safely create my own table in the database or will it cause issues with a version upgrade (i.e. custom table gets removed by the upgrade, or prevents the upgrade proceeding).
If that is not possible is there a recommended way forward?
Use case:
Emailing non-users from a work package. I want to store the message content and replies as individual comments but add metadata that would allow a subsequent reply from the work package to contain the full chain of email conversation without including comments that were not emails.
See below mockup for context.
Email received by External user at 10:46
Subject: RE: Please review this clinical content
Thank you for sending this through, we will be in touch if we have further questions.
Kind regards,
OpenProject user
From: external.person@email.com
Sent: Thursday, March 12, 2026 10:41 AM
Subject: RE: Please review this clinical content
Hi openproject userI attached an updated document with comments
Regards,
External user
To: external.person@email.com
Sent: Thursday, March 12, 2026 9:02 AM
Subject: Please review this clinical contentHi External person,
Can you please review the attached document for any clinical inaccuracies?Kind regards,
OpenProject user
Replies (2)
There is nothing stopping you from adding an extra table in principle.
An upgrade won't remove any tables or even touch them unless there is a migration file that specifically does that.
And such a file would only be part of your plugin presumably.
What could happen is that it breaks upgrades (migrations) if you add certain foreign keys or other constraints coupling your table to the core OpenProject ones.
For instance if you were to add a foreign key reference to, I don't know, the
filenamecolumn in theattachmentstable, and we add a migration that removes that column which we might in this case because that column is not actually used anymore. It should be empty anyway, but just to give an example.This would then break the core migration.
Thanks so much for the quick reply Markus, that all makes sense.