Merge pull request #93 from datasharingframework/dsf.dev_restructuring_2.0

schwzr · web-flow · commit 5f840adca1ef · 2025-06-03T08:50:57.000+02:00
fixed some links
diff --git a/docs/src/explore/concepts/security.md b/docs/src/explore/concepts/security.md
@@ -15,5 +15,5 @@ Authentication of organizations within the DSF is handled by the use of X.509 cl
 
 A webserver certificate is needed to run the FHIR endpoint and a 802.1X client certificate is used to authenticate against other organizations endpoints and as a server certificate for the business process engine.
 
-More information about client and server certificates can be found [here](/operations/v1/latest/maintain/install#client-server-certificates).
+More information about client and server certificates can be found [here](/operations/v1/latest/install#client-server-certificates).
 
diff --git a/docs/src/hackathon/index.md b/docs/src/hackathon/index.md
@@ -80,7 +80,7 @@ Versionen der unten aufgeführten Tools können sich noch bis zum Hackathon änd
 :::
 
 ### DSF
-[Installation](https://dsf.dev/stable/maintain/install.html) oder [Update](https://dsf.dev/stable/maintain/upgrade-from-1.html)
+[Installation](https://dsf.dev/operations/latest/install.html) oder [Update](https://dsf.dev/operations/latest/upgrade-from-1.html)
 
 ### Prozessplugins
 - DSF Ping Pong 1.0.1.0 [Release Notes](https://github.com/datasharingframework/dsf-process-ping-pong/releases/tag/v1.0.1.0)
diff --git a/docs/src/operations/v1.0.0/allowList-mgm.md b/docs/src/operations/v1.0.0/allowList-mgm.md
@@ -4,7 +4,7 @@ icon: share
 ---
 
 :::danger
-This is an outdated version of the Allow List Management documentation. Please use [the current version](/stable/maintain/allowList-mgm), even if you use an outdated DSF version.
+This is an outdated version of the Allow List Management documentation. Please use [the current version](/operations/latest/allowList-mgm.md), even if you use an outdated DSF version.
 :::
 
 You can read all about the concept of Allow Lists [here](/explore/concepts/allow-list.md).
diff --git a/docs/src/operations/v1.1.0/allowList-mgm.md b/docs/src/operations/v1.1.0/allowList-mgm.md
@@ -4,7 +4,7 @@ icon: share
 ---
 
 :::danger
-This is an outdated version of the Allow List Management documentation. Please use [the current version](/stable/maintain/allowList-mgm), even if you use an outdated DSF version.
+This is an outdated version of the Allow List Management documentation. Please use [the current version](/operations/latest/allowList-mgm.md), even if you use an outdated DSF version.
 :::
 
 You can read all about the concept of Allow Lists [here](/explore/concepts/allow-list.md).
diff --git a/docs/src/operations/v1.2.0/allowList-mgm.md b/docs/src/operations/v1.2.0/allowList-mgm.md
@@ -4,7 +4,7 @@ icon: share
 ---
 
 :::danger
-This is an outdated version of the Allow List Management documentation. Please use [the current version](/stable/maintain/allowList-mgm), even if you use an outdated DSF version.
+This is an outdated version of the Allow List Management documentation. Please use [the current version](/operations/latest/allowList-mgm.md), even if you use an outdated DSF version.
 :::
 
 You can read all about the concept of Allow Lists [here](/explore/concepts/allow-list.md).
diff --git a/docs/src/operations/v1.3.0/allowList-mgm.md b/docs/src/operations/v1.3.0/allowList-mgm.md
@@ -4,7 +4,7 @@ icon: share
 ---
 
 :::danger
-This is an outdated version of the Allow List Management documentation. Please use [the current version](/stable/maintain/allowList-mgm), even if you use an outdated DSF version.
+This is an outdated version of the Allow List Management documentation. Please use [the current version](/operations/latest/allowList-mgm.md), even if you use an outdated DSF version.
 :::
 
 You can read all about the concept of Allow Lists [in our introduction](/explore/concepts/allow-list.md).
diff --git a/docs/src/operations/v1.3.0/upgrade-from-1.md b/docs/src/operations/v1.3.0/upgrade-from-1.md
@@ -11,7 +11,7 @@ If you want to migrate from DSF 0.9.x, please follow [these instructions](upgrad
 :::
 
 ::: warning Update to DSF 1.2.0 first
-When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](/v1.2.0/maintain/upgrade-from-1).
+When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](../v1.2.0/upgrade-from-1).
 :::
 
 
diff --git a/docs/src/operations/v1.3.1/allowList-mgm.md b/docs/src/operations/v1.3.1/allowList-mgm.md
@@ -4,7 +4,7 @@ icon: share
 ---
 
 :::danger
-This is an outdated version of the Allow List Management documentation. Please use [the current version](/stable/maintain/allowList-mgm), even if you use an outdated DSF version.
+This is an outdated version of the Allow List Management documentation. Please use [the current version](/operations/latest/allowList-mgm.md), even if you use an outdated DSF version.
 :::
 
 You can read all about the concept of Allow Lists [in our introduction](/explore/concepts/allow-list.md).
diff --git a/docs/src/operations/v1.3.1/upgrade-from-1.md b/docs/src/operations/v1.3.1/upgrade-from-1.md
@@ -7,7 +7,7 @@ Upgrading the DSF from 1.3.0 to 1.3.1 involves modifying the docker-compose.yml
 
 
 ::: warning Update to DSF 1.2.0 first
-When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](/v1.2.0/maintain/upgrade-from-1).
+When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](../v1.2.0/upgrade-from-1).
 :::
 
 
diff --git a/docs/src/operations/v1.3.2/allowList-mgm.md b/docs/src/operations/v1.3.2/allowList-mgm.md
@@ -4,7 +4,7 @@ icon: share
 ---
 
 :::danger
-This is an outdated version of the Allow List Management documentation. Please use [the current version](/stable/maintain/allowList-mgm), even if you use an outdated DSF version.
+This is an outdated version of the Allow List Management documentation. Please use [the current version](/operations/latest/allowList-mgm.md), even if you use an outdated DSF version.
 :::
 
 You can read all about the concept of Allow Lists [in our introduction](/explore/concepts/allow-list.md).
diff --git a/docs/src/operations/v1.3.2/upgrade-from-1.md b/docs/src/operations/v1.3.2/upgrade-from-1.md
@@ -7,7 +7,7 @@ Upgrading the DSF from 1.3.1 to 1.3.2 involves modifying the docker-compose.yml
 
 
 ::: warning Update to DSF 1.2.0 first
-When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](/v1.2.0/maintain/upgrade-from-1).
+When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](../v1.2.0/upgrade-from-1).
 :::
 
 
diff --git a/docs/src/operations/v1.4.0/allowList-mgm.md b/docs/src/operations/v1.4.0/allowList-mgm.md
@@ -4,7 +4,7 @@ icon: share
 ---
 
 :::danger
-This is an outdated version of the Allow List Management documentation. Please use [the current version](/stable/maintain/allowList-mgm), even if you use an outdated DSF version.
+This is an outdated version of the Allow List Management documentation. Please use [the current version](/operations/latest/allowList-mgm.md), even if you use an outdated DSF version.
 :::
 
 You can read all about the concept of Allow Lists [in our introduction](/explore/concepts/allow-list.md).
diff --git a/docs/src/operations/v1.4.0/upgrade-from-1.md b/docs/src/operations/v1.4.0/upgrade-from-1.md
@@ -7,7 +7,7 @@ Upgrading the DSF from 1.3.2 to 1.4.0 involves modifying the docker-compose.yml
 
 
 ::: warning Update to DSF 1.2.0 first
-When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](/v1.2.0/maintain/upgrade-from-1).
+When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](../v1.2.0/upgrade-from-1).
 :::
 
 
diff --git a/docs/src/operations/v1.5.0/allowList-mgm.md b/docs/src/operations/v1.5.0/allowList-mgm.md
@@ -4,7 +4,7 @@ icon: share
 ---
 
 :::danger
-This is an outdated version of the Allow List Management documentation. Please use [the current version](/stable/maintain/allowList-mgm), even if you use an outdated DSF version.
+This is an outdated version of the Allow List Management documentation. Please use [the current version](/operations/latest/allowList-mgm.md), even if you use an outdated DSF version.
 :::
 
 You can read all about the concept of Allow Lists [in our introduction](/explore/concepts/allow-list.md).
diff --git a/docs/src/operations/v1.5.0/upgrade-from-1.md b/docs/src/operations/v1.5.0/upgrade-from-1.md
@@ -7,7 +7,7 @@ Upgrading the DSF from 1.4.0 to 1.5.0 involves modifying the docker-compose.yml
 
 
 ::: warning Update to DSF 1.2.0 first
-When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](/v1.2.0/maintain/upgrade-from-1).
+When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](../v1.2.0/upgrade-from-1).
 :::
 
 
diff --git a/docs/src/operations/v1.5.1/allowList-mgm.md b/docs/src/operations/v1.5.1/allowList-mgm.md
@@ -4,7 +4,7 @@ icon: share
 ---
 
 :::danger
-This is an outdated version of the Allow List Management documentation. Please use [the current version](/stable/maintain/allowList-mgm), even if you use an outdated DSF version.
+This is an outdated version of the Allow List Management documentation. Please use [the current version](/operations/latest/allowList-mgm.md), even if you use an outdated DSF version.
 :::
 
 You can read all about the concept of Allow Lists [in our introduction](/explore/concepts/allow-list.md).
diff --git a/docs/src/operations/v1.5.1/upgrade-from-1.md b/docs/src/operations/v1.5.1/upgrade-from-1.md
@@ -7,7 +7,7 @@ Upgrading the DSF from 1.5.0 to 1.5.1 involves modifying the docker-compose.yml
 
 
 ::: warning Update to DSF 1.2.0 first
-When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](/v1.2.0/maintain/upgrade-from-1).
+When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](../v1.2.0/upgrade-from-1).
 :::
 
 
diff --git a/docs/src/operations/v1.5.2/allowList-mgm.md b/docs/src/operations/v1.5.2/allowList-mgm.md
@@ -4,7 +4,7 @@ icon: share
 ---
 
 :::danger
-This is an outdated version of the Allow List Management documentation. Please use [the current version](/stable/maintain/allowList-mgm), even if you use an outdated DSF version.
+This is an outdated version of the Allow List Management documentation. Please use [the current version](/operations/latest/allowList-mgm.md), even if you use an outdated DSF version.
 :::
 
 You can read all about the concept of Allow Lists [in our introduction](/explore/concepts/allow-list.md).
diff --git a/docs/src/operations/v1.5.2/install-plugins.md b/docs/src/operations/v1.5.2/install-plugins.md
@@ -28,7 +28,7 @@ To install and learn more about each Process Plugin, you can visit the Marketpla
 
 
 ### Prerequisites
-- A DSF installation of version 1.3.x or higher. An installation guide can be found [here](https://dsf.dev/stable/maintain/install.html).
+- A DSF installation of version 1.3.x or higher. An installation guide can be found [here](https://dsf.dev/operations/latest/install.html).
 
 ### Deployment
 - Add the process jar-file to the DSF BPE folder `/opt/bpe/process`: 
diff --git a/docs/src/operations/v1.5.2/upgrade-from-1.md b/docs/src/operations/v1.5.2/upgrade-from-1.md
@@ -7,7 +7,7 @@ Upgrading the DSF from 1.5.1 to 1.5.2 involves modifying the docker-compose.yml
 
 
 ::: warning Update to DSF 1.2.0 first
-When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](/v1.2.0/maintain/upgrade-from-1).
+When upgrading from 1.0.0 or 1.1.0 it is important to migrate to [DSF 1.2.0 first](../v1.2.0/upgrade-from-1).
 :::
 
 
diff --git a/docs/src/operations/v1.6.0/install-plugins.md b/docs/src/operations/v1.6.0/install-plugins.md
@@ -28,7 +28,7 @@ To install and learn more about each Process Plugin, you can visit the Marketpla
 
 
 ### Prerequisites
-- A DSF installation of version 1.3.x or higher. An installation guide can be found [here](https://dsf.dev/stable/maintain/install.html).
+- A DSF installation of version 1.3.x or higher. An installation guide can be found [here](https://dsf.dev/operations/latest/install.html).
 
 ### Deployment
 - Add the process jar-file to the DSF BPE folder `/opt/bpe/process`: 
diff --git a/docs/src/operations/v1.7.0/install-plugins.md b/docs/src/operations/v1.7.0/install-plugins.md
@@ -28,7 +28,7 @@ To install and learn more about each Process Plugin, you can visit the Marketpla
 
 
 ### Prerequisites
-- A DSF installation of version 1.3.x or higher. An installation guide can be found [here](https://dsf.dev/stable/maintain/install.html).
+- A DSF installation of version 1.3.x or higher. An installation guide can be found [here](https://dsf.dev/operations/latest/install.html).
 
 ### Deployment
 - Add the process jar-file to the DSF BPE folder `/opt/bpe/process`: 
diff --git a/docs/src/operations/v1.7.1/install-plugins.md b/docs/src/operations/v1.7.1/install-plugins.md
@@ -28,7 +28,7 @@ To install and learn more about each Process Plugin, you can visit the Marketpla
 
 
 ### Prerequisites
-- A DSF installation of version 1.3.x or higher. An installation guide can be found [here](https://dsf.dev/stable/maintain/install.html).
+- A DSF installation of version 1.3.x or higher. An installation guide can be found [here](https://dsf.dev/operations/latest/install.html).
 
 ### Deployment
 - Add the process jar-file to the DSF BPE folder `/opt/bpe/process`: 
diff --git a/docs/src/operations/v1.7.1/upgrade-from-1.md b/docs/src/operations/v1.7.1/upgrade-from-1.md
@@ -6,7 +6,7 @@ icon: update
 Upgrading the DSF from 1.7.0 to 1.7.1 involves modifying the docker-compose.yml files and recreating the containers. 
 
 ::: warning Update to DSF 1.7.0 first
-When upgrading from DSF version < 1.7.0 it is important to migrate to [DSF 1.7.0 first](../../v1.7.0/maintain/upgrade-from-1).
+When upgrading from DSF version < 1.7.0 it is important to migrate to [DSF 1.7.0 first](../v1.7.0/upgrade-from-1).
 :::
 
 
diff --git a/docs/src/operations/v1.8.0/index.md b/docs/src/operations/v1.8.0/index.md
@@ -7,9 +7,9 @@ Data Sharing Framework 1.x is the current major release of the Data Sharing Fram
 
 # System Administrators
 
-- [Install DSF 1.8.0](maintain/install)
-- [Upgrade from DSF 1.7.1](maintain/upgrade-from-1)
-- [Upgrade from DSF 0.9.x.](maintain/upgrade-from-0)
+- [Install DSF 1.8.0](install)
+- [Upgrade from DSF 1.7.1](upgrade-from-1)
+- [Upgrade from DSF 0.9.x.](upgrade-from-0)
 
 
 ## New features
diff --git a/docs/src/operations/v1.8.0/install-plugins.md b/docs/src/operations/v1.8.0/install-plugins.md
@@ -28,7 +28,7 @@ To install and learn more about each Process Plugin, you can visit the Marketpla
 
 
 ### Prerequisites
-- A DSF installation of version 1.3.x or higher. An installation guide can be found [here](https://dsf.dev/stable/maintain/install.html).
+- A DSF installation of version 1.3.x or higher. An installation guide can be found [here](https://dsf.dev/operations/latest/install.html).
 
 ### Deployment
 - Add the process jar-file to the DSF BPE folder `/opt/bpe/process`: 
diff --git a/docs/src/operations/v1.8.0/upgrade-from-1.md b/docs/src/operations/v1.8.0/upgrade-from-1.md
@@ -6,7 +6,7 @@ icon: update
 Upgrading the DSF from 1.7.1 to 1.8.0 involves modifying the docker-compose.yml files and recreating the containers. 
 
 ::: warning Update to DSF 1.7.0 first
-When upgrading from DSF version < 1.7.0 it is important to migrate to [DSF 1.7.0 first](../../v1.7.0/maintain/upgrade-from-1).
+When upgrading from DSF version < 1.7.0 it is important to migrate to [DSF 1.7.0 first](../v1.7.0/upgrade-from-1).
 :::
 
 
diff --git a/docs/src/process-development/api-v1/dsf/organization-identifiers.md b/docs/src/process-development/api-v1/dsf/organization-identifiers.md
@@ -4,7 +4,7 @@ icon: creative
 ---
 
 ### Organization Identifiers
-DSF FHIR server instances always have something called an `organization identifer`. It uniquely identifies the organization the DSF FHIR server instance belongs to for its [Allow-List mechanism](https://dsf.dev/intro/info/allowList.html). It is configured as an [environment variable](https://dsf.dev/stable/maintain/fhir/configuration.html#dev-dsf-fhir-server-organization-identifier-value). You can make a GET request to `https://domain/fhir/Organization` to get a list of all organizations for the DSF FHIR server instance running under `domain`. The results will also include the `organization identifier` of each organization.  
+DSF FHIR server instances always have something called an `organization identifer`. It uniquely identifies the organization the DSF FHIR server instance belongs to for its [Allow-List mechanism](https://dsf.dev/intro/info/allowList.html). It is configured as an [environment variable](https://dsf.dev/operations/latest/fhir/configuration.html#dev-dsf-fhir-server-organization-identifier-value). You can make a GET request to `https://domain/fhir/Organization` to get a list of all organizations for the DSF FHIR server instance running under `domain`. The results will also include the `organization identifier` of each organization.  
 
 #### Organization Identifiers in Task Resources
 [Task](../fhir/task.md) resources require you to reference an organization via its identifier as the `Task.requester` and `Task.restriction.recipient` elements. The exact values for these elements depend on the [ActivityDefinition](../fhir/activitydefinition.md) the [Task](../fhir/task.md) resource should conform to. As a general rule, you will want to put the identifier of your own organization as the `Task.requester` and `Task.restriction.recipient` elements for [Task](../fhir/task.md) resources which initially start processes. All other cases depend on the context of the message being sent during process execution.
diff --git a/docs/src/process-development/api-v1/guides/creating-activity-definitions.md b/docs/src/process-development/api-v1/guides/creating-activity-definitions.md
@@ -238,7 +238,7 @@ Here is what they mean:
 - `remote` versions of the above rules work the same but the requester's certificate is instead required to match a thumbprint marked as a remote organization.
 - `practitioner` suffixes all work the same. They include the same rules as their prefixes but now additionally require the requester to match a certain `practitioner-role`. A list of them
   can be found [here](https://github.com/datasharingframework/dsf/blob/main/dsf-fhir/dsf-fhir-validation/src/main/resources/fhir/CodeSystem/dsf-practitioner-role-1.0.0.xml). This allows
-  for more granularity when defining authorization rules within an organization and can be integrated into local user management via [OpenID Connect](https://dsf.dev/stable/maintain/fhir/access-control.html).
+  for more granularity when defining authorization rules within an organization and can be integrated into local user management via [OpenID Connect](https://dsf.dev/operations/latest/fhir/access-control.html).
 
 As you can see, there are no `practitioner` versions of `remote` authorization rules. From the perspective of the receiving DSF instance, remote requests are always issued by an organization. They do not hold any information about the local user management of the requesting organization. You can also find examples of all Codings from above [here](../dsf/requester-and-recipient.md).
 
@@ -407,7 +407,7 @@ Finally, we will add the `practitionerRole` slice:
 </extension>
 ```
 
-Notice that there is no `binding` element specified for `practitionerRole.value[x]`. This is intentional. In the example we used a code from the [dsf-practitioner-role](https://github.com/datasharingframework/dsf/blob/main/dsf-fhir/dsf-fhir-validation/src/main/resources/fhir/CodeSystem/dsf-practitioner-role-1.0.0.xml) CodeSystem. This CodeSystem includes a standard set of codes which are often sufficient for DSF use cases. You can freely add other CodeSystems if you find these codes do not apply for your use case. The code you set here can be used in the [DSF role config](https://dsf.dev/stable/maintain/fhir/access-control.html) to allow certain users with this `practitioner-role` to send requests.
+Notice that there is no `binding` element specified for `practitionerRole.value[x]`. This is intentional. In the example we used a code from the [dsf-practitioner-role](https://github.com/datasharingframework/dsf/blob/main/dsf-fhir/dsf-fhir-validation/src/main/resources/fhir/CodeSystem/dsf-practitioner-role-1.0.0.xml) CodeSystem. This CodeSystem includes a standard set of codes which are often sufficient for DSF use cases. You can freely add other CodeSystems if you find these codes do not apply for your use case. The code you set here can be used in the [DSF role config](https://dsf.dev/operations/latest/fhir/access-control.html) to allow certain users with this `practitioner-role` to send requests.
 
 Working our way back up to the Coding we selected, we will now add the extension we just created as the `Coding.extension:organization-practitioner` element:
 ```xml
diff --git a/docs/src/process-development/api-v2/dsf/organization-identifiers.md b/docs/src/process-development/api-v2/dsf/organization-identifiers.md
@@ -4,7 +4,7 @@ icon: creative
 ---
 
 ### Organization Identifiers
-DSF FHIR server instances always have something called an `organization identifer`. It uniquely identifies the organization the DSF FHIR server instance belongs to for its [Allow-List mechanism](https://dsf.dev/intro/info/allowList.html). It is configured as an [environment variable](https://dsf.dev/stable/maintain/fhir/configuration.html#dev-dsf-fhir-server-organization-identifier-value). You can make a GET request to `https://domain/fhir/Organization` to get a list of all organizations for the DSF FHIR server instance running under `domain`. The results will also include the `organization identifier` of each organization.  
+DSF FHIR server instances always have something called an `organization identifer`. It uniquely identifies the organization the DSF FHIR server instance belongs to for its [Allow-List mechanism](https://dsf.dev/intro/info/allowList.html). It is configured as an [environment variable](https://dsf.dev/operations/latest/fhir/configuration.html#dev-dsf-fhir-server-organization-identifier-value). You can make a GET request to `https://domain/fhir/Organization` to get a list of all organizations for the DSF FHIR server instance running under `domain`. The results will also include the `organization identifier` of each organization.  
 
 #### Organization Identifiers in Task Resources
 [Task](../fhir/task.md) resources require you to reference an organization via its identifier as the `Task.requester` and `Task.restriction.recipient` elements. The exact values for these elements depend on the [ActivityDefinition](../fhir/activitydefinition.md) the [Task](../fhir/task.md) resource should conform to. As a general rule, you will want to put the identifier of your own organization as the `Task.requester` and `Task.restriction.recipient` elements for [Task](../fhir/task.md) resources which initially start processes. All other cases depend on the context of the message being sent during process execution.
diff --git a/docs/src/process-development/api-v2/guides/creating-activity-definitions.md b/docs/src/process-development/api-v2/guides/creating-activity-definitions.md
diff --git a/docs/src/security/readme.md b/docs/src/security/readme.md

Original file line number	Diff line number	Diff line change
`@@ -15,5 +15,5 @@ Authentication of organizations within the DSF is handled by the use of X.509 cl`
`15`	`15`
`16`	`16`	`A webserver certificate is needed to run the FHIR endpoint and a 802.1X client certificate is used to authenticate against other organizations endpoints and as a server certificate for the business process engine.`
`17`	`17`
`18`		`-More information about client and server certificates can be found [here](/operations/v1/latest/maintain/install#client-server-certificates).`
	`18`	`+More information about client and server certificates can be found [here](/operations/v1/latest/install#client-server-certificates).`
`19`	`19`