Begin of the insertion**As a** self-hosting GitLab administrator,

**I want to** be ableEnd of the insertion Begin of the deletion ### StepsEnd of the deletion to Begin of the insertionupdate all stored GitLab integration links when changingEnd of the insertion Begin of the deletion reproduce


changeEnd of the deletion the Begin of the deletion domain of your gitlabEnd of the deletion instance Begin of the insertiondomain,End of the insertion

Begin of the insertion**so that** links to issues, merge requests, and other entities remain functional andEnd of the insertion Begin of the deletion ### What isEnd of the deletion the Begin of the insertionsystem retains its value after a domain migration.End of the insertion Begin of the deletion buggy behavior?End of the deletion

Begin of the insertion### **Acceptance criteria**End of the insertion Begin of the deletion <br>End of the deletion

* Begin of the insertionA tool, script, or documented process existsEnd of the insertion Begin of the deletion I hadEnd of the deletion to Begin of the insertionupdateEnd of the insertion Begin of the deletion change the domain of my self-hosted gitlab instance. Then I realized that literallyEnd of the deletion all Begin of the insertionstoredEnd of the insertion Begin of the deletion theEnd of the deletion links Begin of the insertioncontainingEnd of the insertion Begin of the deletion created in/byEnd of the deletion the Begin of the insertionGitLab domain across all relevantEnd of the insertion Begin of the deletion gitlab integration are &quot;hardcoded&quot; in theEnd of the deletion database Begin of the insertiontables.End of the insertion

* Begin of the insertionThe solution must handle all integration-created links (e.g., issues, MRs, pipelines, webhooks, etc.).

* The solution must be safeEnd of the insertion Begin of the deletion I do not wantEnd of the deletion to Begin of the insertionrun on production dataEnd of the insertion Begin of the deletion talk about what I think of this, being a software developer myself for a very long time, because that will lead us nowhere.


### What is the expected behavior?


Rather than discussing that this is an improper implementation, as this is not something completely unusualEnd of the deletion and Begin of the insertionprovideEnd of the insertion Begin of the deletion unthinkable (while also notEnd of the deletion a Begin of the insertionwayEnd of the insertion Begin of the deletion daily task ofc it is quite the contrary actually and just happens that you migrateEnd of the deletion to Begin of the insertionpreview changes before applying.

* The solution should not require modifying application codeEnd of the insertion Begin of the deletion another systemEnd of the deletion or Begin of the insertionre-installing integrations.


###

### **Technical notes**

* Links are currently hardcoded withEnd of the insertion Begin of the deletion host) I would be more than happy and thankful if you could provide me allEnd of the deletion the Begin of the deletion tables involved so I can write myself some proper SQL statements for postgres that update all the old storedEnd of the deletion domain Begin of the insertioninEnd of the insertion Begin of the deletion names toEnd of the deletion the Begin of the insertiondatabase.

* The feature could be a rake task, SQL migration script, or admin UI option.

* GitLab integrationsEnd of the insertion Begin of the deletion new one, as currently 100s of links to issuesEnd of the deletion and Begin of the insertionprojects may have references stored in various tables. Documentation should include which tablesEnd of the insertion Begin of the deletion MRsEnd of the deletion are Begin of the insertionaffected.


###

### **PermissionsEnd of the insertion Begin of the deletion completely uselessEnd of the deletion and Begin of the insertionvisibility considerations**End of the insertion Begin of the deletion lead to nowhere. The whole system lost its value for all the projects handled.End of the deletion

Begin of the insertion**To whom is this feature visible?**End of the insertion Begin of the deletion ### Environment informationEnd of the deletion

Begin of the deletion **OpenProject installation type**

End of the deletion * Begin of the insertionOpenProject administrators


<br>

### **Out of scope**

End of the insertion Begin of the deletion Packaged installation

End of the deletion * Begin of the insertionAutomatic detectionEnd of the insertion Begin of the deletion CentOS/RedHat/Alma 9 packages (currently version 14End of the deletion of Begin of the insertiondomain changes.

* Backward compatibility for both old and new domains (redirects or proxying).


<br>End of the insertion Begin of the deletion OP still)


**OpenProject version**End of the deletion

Begin of the insertion<br>End of the insertion Begin of the deletion _14.6.3-1730194473.d9ae0312.centos9_End of the deletion

Begin of the insertion<br>End of the insertion Begin of the deletion **Browser**

N/A

**Operating System**

N?A

**Language**

N/AEnd of the deletion