You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: "Supported upgrade procedure for self-hosted DefectDojo Pro deployments using the Helm chart"
4
+
draft: false
5
+
weight: 5
6
+
audience: pro
7
+
---
8
+
9
+
This page describes the supported upgrade procedure for self-hosted DefectDojo Pro deployments that use the DefectDojo Pro Helm chart.
10
+
11
+
## Upgrade everything as one unit
12
+
13
+
Each DefectDojo Pro release consists of a Helm chart version, container image versions, and the Pro settings files. These are built and tested together and must be upgraded together as one unit.
14
+
15
+
Upgrading only the image tags is not supported and will break your deployment.
16
+
17
+
## Settings files and upgrades
18
+
19
+
DefectDojo Pro ships a `pro_settings.py` file with every release, and the file changes with nearly every version. Do not carry a copy of `pro_settings.py` forward across upgrades, and do not patch an older copy by hand. The application must always run the `pro_settings.py` that matches its version.
20
+
21
+
Put your own customizations in `local_settings.py`, never in `pro_settings.py`. Your `local_settings.py` is preserved across upgrades.
22
+
23
+
The Helm chart ships and mounts the matching `pro_settings.py` and your `local_settings.py` automatically. When you upgrade using the chart, there is nothing to copy or migrate by hand.
24
+
25
+
## Supported upgrade procedure
26
+
27
+
1. Review the release notes for every version between your current version and your target version, not just the target itself. See the [DefectDojo Pro Changelog](/releases/pro/changelog/) and the version-specific [upgrade notes](/releases/os_upgrading/upgrading_guide/).
28
+
2. Back up your database.
29
+
3. Upgrade to the Helm chart release that matches your target application version, reusing your existing values files. Do not change image tags independently of the chart version.
30
+
31
+
If you have questions about upgrading your on-premise deployment, contact [support@defectdojo.com](mailto:support@defectdojo.com).
Copy file name to clipboardExpand all lines: docs/content/issue_tracking/jira/PRO__jira_guide.md
+32Lines changed: 32 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -138,6 +138,38 @@ Note that DefectDojo cannot send any Issue\-specific metadata as Custom Fields,
138
138
139
139
Follow **[this guide](#custom-fields-in-jira)** to get started working with Custom Fields.
140
140
141
+
#### Close / Reopen Transition fields
142
+
143
+
Some Jira workflows **require** certain fields to be set as part of a transition — for example, a workflow that refuses to close an Issue unless a Resolution and a Justification field are provided on the close screen. The Custom fields setting above only applies when an Issue is *created*, so it cannot satisfy these workflows.
144
+
145
+
Without these settings, DefectDojo sends close / reopen transitions with no fields. A workflow that requires fields will reject that transition, and the Finding and the Jira Issue fall out of sync: the Finding shows as Mitigated in DefectDojo while the Issue remains open in Jira.
146
+
147
+
The **Close Transition fields** and **Reopen Transition fields** settings accept a JSON object that is sent as the `fields` payload of the close / reopen transition call. For example, to close Issues with a Resolution of *Won't Fix* plus a justification value:
148
+
149
+
```json
150
+
{
151
+
"resolution": {"name": "Won't Fix"},
152
+
"customfield_10200": "Risk accepted by security team #report-false-positive"
153
+
}
154
+
```
155
+
156
+
Leave these settings as 'null' if your Jira workflow does not require fields on transitions.
157
+
158
+
**Which fields do you need?**
159
+
160
+
* Ask your Jira admin which fields are on the close / reopen **transition screens**, and which of them are enforced by a validator. The configured JSON must satisfy **every** required field: if any required field is missing from the payload, Jira rejects the whole transition and sets nothing — supplying only some of the required fields does not help.
161
+
* Conversely, fields must be present **on the transition screen** to be sent at all: Jira rejects transitions that attempt to set fields that are not on the screen for that transition.
162
+
* On workflows built with Jira Cloud's current workflow editor, Jira automatically fills in the site's default Resolution when an Issue moves to a done-category status. So, a required Resolution alone will not block a bare transition there, and the practical use of `"resolution"` in this payload is choosing a *meaningful* value (for example *False Positive*) instead of the site default. Workflows built with the classic editor, or with marketplace validator apps, can still hard-require Resolution.
163
+
* Reopen transitions typically clear the Resolution via the workflow itself, so **Reopen Transition fields** usually only needs the custom fields your workflow requires.
164
+
165
+
**Notes:**
166
+
167
+
* The same JSON is sent for *every* close (or reopen) transition for the Product or Engagement — the values are static and do not vary per Finding. If you need different fields per disposition (for example, a different Resolution for False Positive findings than for remediated findings), use the DefectDojo Pro Jira Integrator, which supports per-status transition field mappings.
168
+
* Values use the same format as Jira's REST API: strings for text fields, `{"name": ...}` for resolutions, `[{"name": ...}]` for multi-select fields, and so on.
169
+
* If transitions were rejected while these settings were missing or incomplete, correcting the settings repairs the drift: the next status push for the Finding retries the transition with the configured fields.
170
+
* Both settings are also available on the `/api/v2/jira_projects/` REST endpoint (`close_transition_fields` / `reopen_transition_fields`), so they can be managed via the API.
171
+
* These fields are also applied when DefectDojo closes an Issue because its Finding was **deleted** — the values are captured at the moment the close is queued.
172
+
141
173
#### Jira labels
142
174
143
175
Select the relevant labels that you want the Issue to be created with in Jira, e.g. **DefectDojo**, **YourProductName..**
Copy file name to clipboardExpand all lines: docs/content/issue_tracking/pro_integration/integrations.md
+18-10Lines changed: 18 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,11 +10,15 @@ aliases:
10
10
DefectDojo Pro's Integrations let you push your Findings and Finding Groups to ticket tracking systems to easily integrate security remediation with your teams existing development workflow.
0 commit comments