More fixed links -> stick to relative ones

danjoa · danjoa · commit 46e88ab7ccfa · 2025-12-22T12:47:50.000+01:00
diff --git a/guides/advanced/publishing-apis/asyncapi.md b/guides/advanced/publishing-apis/asyncapi.md
@@ -34,7 +34,7 @@ If you want to generate one AsyncAPI document for all the services, you can use
 cds compile srv --service all -o docs --to asyncapi --asyncapi:merged
 ```
 
-[Learn how to programmatically convert the CSN file into an AsyncAPI Document](/node.js/cds-compile#to-asyncapi){.learn-more}
+[Learn how to programmatically convert the CSN file into an AsyncAPI Document](../../../node.js/cds-compile#to-asyncapi){.learn-more}
 
 ## Presets { #presets}
 
diff --git a/guides/databases/sqlite.md b/guides/databases/sqlite.md
@@ -106,7 +106,7 @@ Configure the build to create an initial _schema.sql_ file for SQLite using `cds
 :::
 
 
-[Learn more about creating an initial database schema](/java/cqn-services/persistence-services#initial-database-schema-1){.learn-more}
+[Learn more about creating an initial database schema](../../java/cqn-services/persistence-services#initial-database-schema-1){.learn-more}
 
 </div>
 
diff --git a/guides/deploy/to-cf.md b/guides/deploy/to-cf.md
@@ -159,7 +159,7 @@ cds add xsuaa
 ```
 
 ::: tip This will also generate an `xs-security.json` file
-The roles/scopes are derived from authorization-related annotations in your CDS models. Ensure to rerun `cds compile --to xsuaa`, as documented in the [_Authorization_ guide](/guides/security/authorization#xsuaa-configuration) whenever there are changes to these annotations.
+The roles/scopes are derived from authorization-related annotations in your CDS models. Ensure to rerun `cds compile --to xsuaa`, as documented in the [_Authorization_ guide](../security/authorization#xsuaa-configuration) whenever there are changes to these annotations.
 :::
 
 [Learn more about SAP Authorization and Trust Management/XSUAA.](https://discovery-center.cloud.sap/serviceCatalog/authorization-and-trust-management-service?region=all){.learn-more}
diff --git a/guides/extensibility/customization.md b/guides/extensibility/customization.md
@@ -969,7 +969,7 @@ Obtain these two from the `VCAP_SERVICES` environment variable in your deployed
 
 **Note:** The `key` and `clientsecret` properties are secrets that should not be stored in an unsafe location in productive scenarios!
 
-[Learn more about environment variables / `VCAP_Services`.](/node.js/cds-connect#bindings-in-cloud-platforms){.learn-more}
+[Learn more about environment variables / `VCAP_Services`.](../../node.js/cds-connect#bindings-in-cloud-platforms){.learn-more}
 
 If you leave out the respective secret (enclosed in square brackets above), you will be prompted to enter it interactively.
 This can be used to feed the secret from the environment to `cds login` via standard input, like so:
diff --git a/guides/multitenancy/index.md b/guides/multitenancy/index.md
@@ -329,7 +329,7 @@ In a first terminal, start the MTX sidecar process:
    [cds] - [ terminate with ^C ]
    ```
 
-   [If you get an error on server start, read the troubleshooting information.](/get-started/troubleshooting#why-do-i-get-an-error-on-server-start){.learn-more}
+   [If you get an error on server start, read the troubleshooting information.](../../get-started/troubleshooting#why-do-i-get-an-error-on-server-start){.learn-more}
    :::
 
 
@@ -667,7 +667,7 @@ You should now see the route mapped to your application.
 
 There are several ways to update the database schema of a multitenant application.
 
-* For **CAP Java** applications, schema updates should be done as described in the respective [Java Guide](/java/multitenancy#database-update)
+* For **CAP Java** applications, schema updates should be done as described in the respective [Java Guide](../../java/multitenancy#database-update)
 * For **CAP Node.js** applications, you can use either of:
   - the `cds-mtx upgrade` command from a terminal
   - the [MTX Sidecar API](mtxs#upgrade-tenants-→-jobs)
@@ -778,7 +778,7 @@ For CAP Java, all these services are supported natively and SaaS dependencies ar
 :::tip Explicitly activate the Destination service
 SaaS dependency for Destination service needs to be activated explicitly in the `application.yaml` due to security reasons. SaaS dependencies for some of the other services can be **de**activated by setting the corresponding property to `false` in the `application.yaml`.
 
-Refer to the `cds.multiTenancy.dependencies` section in the [CDS properties](/java/developing-applications/properties#cds-properties).
+Refer to the `cds.multiTenancy.dependencies` section in the [CDS properties](../../java/developing-applications/properties#cds-properties).
 :::
 
 For CAP Node.js, all these services are supported natively and can be activated individually by providing configuration in `cds.requires`. In the most common case, you simply activate service dependencies like so:
diff --git a/guides/security/authorization.md b/guides/security/authorization.md
@@ -42,8 +42,8 @@ From perspective of CAP, the authentication method is freely customizable. For c
 
 Find detailed instructions for setting up authentication in these runtime-specific guides:
 
-- [Set up authentication in Node.js.](/node.js/authentication)
-- [Set up authentication in Java.](/java/security#authentication)
+- [Set up authentication in Node.js.](../../node.js/authentication)
+- [Set up authentication in Java.](../../java/security#authentication)
 
 
 In _productive_ environment with security middleware activated, **all protocol adapter endpoints are authenticated by default**<sup>1</sup>, even if no [restrictions](#restrictions) are configured. Multi-tenant SaaS-applications require authentication to provide tenant isolation out of the box. In case there is the business need to expose open endpoints for anonymous users, it's required to take extra measures depending on runtime and security middleware capabilities.
@@ -110,7 +110,7 @@ For XSUAA or IAS authentication, the request user is attached with the pseudo ro
 :::
 
 #### internal-user
-Pseudo-role `internal-user` allows to define application endpoints that can be accessed exclusively by the own PaaS tenant (technical communication). The advantage is that similar to `system-user` no technical CAP roles need to be defined to protect such internal endpoints. However, in contrast to `system-user`, the endpoints protected by this pseudo-role do not allow requests from any external technical clients. Hence is suitable for **technical intra-application communication**, see [Security > Application Zone](/guides/security/overview#application-zone).
+Pseudo-role `internal-user` allows to define application endpoints that can be accessed exclusively by the own PaaS tenant (technical communication). The advantage is that similar to `system-user` no technical CAP roles need to be defined to protect such internal endpoints. However, in contrast to `system-user`, the endpoints protected by this pseudo-role do not allow requests from any external technical clients. Hence is suitable for **technical intra-application communication**, see [Security > Application Zone](../../guides/security/overview#application-zone).
 
 ::: tip
 For XSUAA or IAS authentication, the request user is attached with the pseudo role `internal-user` if the presented JWT token has been issued with grant type `client_credentials` or `client_x509` on basis of the **identical** XSUAA or IAS service instance.
@@ -137,8 +137,8 @@ CAP does not make any assumptions on the presented claims given in the token. St
 In most cases, CAP's default mapping will match your requirements, but CAP also allows you to customize the mapping according to specific needs. For instance, `user_name` in XSUAA tokens is generally not unique if several customer IdPs are connected to the underlying identity service.
 Here a combination of `user_name` and `origin` mapped to `$user` might be a feasible solution that you implement in a custom adaptation. Similarly, attribute values can be normalized and prepared for [instance-based authorization](#instance-based-auth). Find details and examples how to programmatically redefine the user mapping here:
 
-- [Set up Authentication in Node.js.](/node.js/authentication)
-- [Custom Authentication in Java.](/java/security#custom-authentication)
+- [Set up Authentication in Node.js.](../../node.js/authentication)
+- [Custom Authentication in Java.](../../java/security#custom-authentication)
 
 ::: warning Be very careful when redefining `$user`
 The user name is frequently stored with business data (for example, `managed` aspect) and might introduce migration efforts. Also consider data protection and privacy regulations when storing user data.
@@ -173,7 +173,7 @@ service BookshopService {
 }
 ```
 
-Note that both annotations introduce access control on an entity level. In contrast, for the sake of [input validation](/guides/services/providing-services#input-validation), you can also use `@readonly` on a property level.
+Note that both annotations introduce access control on an entity level. In contrast, for the sake of [input validation](../../guides/services/providing-services#input-validation), you can also use `@readonly` on a property level.
 
 In addition, annotation `@Capabilities` from standard OData vocabulary is enforced by the runtimes analogously:
 
@@ -225,7 +225,7 @@ In general, **implicitly auto-exposed entities cannot be accessed directly**, th
 
 In contrast, **explicitly auto-exposed entities can be accessed directly, but only as `@readonly`**. The rationale behind that is that entities representing value lists need to be readable at the service level, for instance to support value help lists.
 
-See details about `@cds.autoexpose` in [Auto-Exposed Entities](/guides/services/providing-services#auto-exposed-entities).
+See details about `@cds.autoexpose` in [Auto-Exposed Entities](../../guides/services/providing-services#auto-exposed-entities).
 
 This results in the following access matrix:
 
@@ -278,7 +278,7 @@ The following values are supported:
 
 - The `to` property lists all [user roles](#roles) or [pseudo roles](#pseudo-roles) that the privilege applies to. Note that the `any` pseudo-role applies for all users and is the default if no value is provided.
 
-- The `where`-clause can contain a Boolean expression in [CQL](/cds/cql)-syntax that filters the instances that the event applies to. As it allows user values (name, attributes, etc.) and entity data as input, it's suitable for *dynamic authorizations based on the business domain*. Supported expressions and typical use cases are presented in [instance-based authorization](#instance-based-auth).
+- The `where`-clause can contain a Boolean expression in [CQL](../../cds/cql)-syntax that filters the instances that the event applies to. As it allows user values (name, attributes, etc.) and entity data as input, it's suitable for *dynamic authorizations based on the business domain*. Supported expressions and typical use cases are presented in [instance-based authorization](#instance-based-auth).
 
 A privilege is met, if and only if **all properties are fulfilled** for the current request. In the following example, orders can only be read by an `Auditor` who meets `AuditBy` element of the instance:
 
@@ -509,7 +509,7 @@ annotate Articles with @(restrict: [
   { grant: ['UPDATE'], to: 'Vendor',  where: (stock > 0) } ]);
 ```
 
-You can define `where`-conditions in restrictions based on [CQL](/cds/cql)-where-clauses.<br>
+You can define `where`-conditions in restrictions based on [CQL](../../cds/cql)-where-clauses.<br>
 Supported features are:
 * Predicates with arithmetic operators.
 * Combining predicates to expressions with `and` and `or` logical operators.
@@ -641,7 +641,7 @@ Be aware that deep paths might introduce a performance bottleneck. Access Contro
 
 ### Association Paths { #association-paths}
 
-The `where`-condition in a restriction can also contain [CQL path expressions](/cds/cql#path-expressions) that navigate to elements of associated entities:
+The `where`-condition in a restriction can also contain [CQL path expressions](../../cds/cql#path-expressions) that navigate to elements of associated entities:
 
 ```cds
 service SalesOrderService @(requires: 'authenticated-user') {
@@ -811,7 +811,7 @@ As shown before, defining an adequate authorization strategy has a deep impact o
 
 ### Separation of Concerns
 
-Consider using [CDS Aspects](/cds/cdl#aspects) to separate the actual service definitions from authorization annotations as follows:
+Consider using [CDS Aspects](../../cds/cdl#aspects) to separate the actual service definitions from authorization annotations as follows:
 
 <!--- % include _code sample='services.cds' %} -->
 ::: code-group
@@ -855,8 +855,8 @@ The service provider frameworks **automatically enforce** restrictions in generi
 
 If generic enforcement doesn't fit your needs, you can override or adapt it with **programmatic enforcement** in custom handlers:
 
-- [Authorization Enforcement in Node.js](/node.js/authentication#enforcement)
-- [Enforcement API & Custom Handlers in Java](/java/security#enforcement-api)
+- [Authorization Enforcement in Node.js](../../node.js/authentication#enforcement)
+- [Enforcement API & Custom Handlers in Java](../../java/security#enforcement-api)
 
 ## Role Assignments with IAS and AMS
 
@@ -968,7 +968,7 @@ Inline configuration in the _mta.yaml_ `config` block and the _xs-security.json_
 
 ### 3. Assembling Roles and Assigning Roles to Users
 
-This is a manual step an administrator would do in SAP BTP Cockpit. See [Set Up the Roles for the Application](/node.js/authentication#auth-in-cockpit) for more details. If a user attribute isn't set for a user in the IdP of the SAP BTP Cockpit, this means that the user has no restriction for this attribute. For example, if a user has no value set for an attribute "Country", they're allowed to see data records for all countries.
+This is a manual step an administrator would do in SAP BTP Cockpit. See [Set Up the Roles for the Application](../../node.js/authentication#auth-in-cockpit) for more details. If a user attribute isn't set for a user in the IdP of the SAP BTP Cockpit, this means that the user has no restriction for this attribute. For example, if a user has no value set for an attribute "Country", they're allowed to see data records for all countries.
 In the _xs-security.json_, the `attribute` entity has a property `valueRequired` where the developer can specify whether unrestricted access is possible by not assigning a value to the attribute.
 
 
diff --git a/guides/security/data-protection.md b/guides/security/data-protection.md
@@ -118,7 +118,7 @@ CAP doesn't require any specific authentication strategy, but it provides out of
 On configured authentication, *all CAP endpoints are authenticated by default*.
 
 ::: warning
-❗ **CAP applications need to ensure that an appropriate [authentication method](/guides/security/authorization#prerequisite-authentication) is configured**.
+❗ **CAP applications need to ensure that an appropriate [authentication method](authorization#prerequisite-authentication) is configured**.
 It's highly recommended to establish integration tests to safeguard a valid configuration.
 :::
 
@@ -180,9 +180,9 @@ The set of rules that apply to a user reflects a specific conceptual role that d
 Obviously, the business roles are dependent from the scenarios and hence *need to be defined by the application developers*.
 
 Enforcing authorization rules at runtime is highly security-critical and shouldn't be implemented by the application as this would introduce the risk of security flaws.
-Instead, [CAP authorizations](/guides/security/authorization) follow a declarative approach allowing applications to design comprehensive access rules in the CDS model.
+Instead, [CAP authorizations](authorization) follow a declarative approach allowing applications to design comprehensive access rules in the CDS model.
 
-Resources in the model such as services or entities can be restricted to users that fulfill specific conditions as declared in `@requires` or `@restrict` [annotations](/guides/security/authorization#restrictions).
+Resources in the model such as services or entities can be restricted to users that fulfill specific conditions as declared in `@requires` or `@restrict` [annotations](authorization#restrictions).
 According to the declarations, server-side authorization enforcement is guaranteed for all requests. It's executed close before accessing the corresponding resources.
 
 ::: warning
@@ -196,7 +196,7 @@ To verify CAP authorizations in your model, it's recommended to use [CDS lint ru
 
 The rules prepared by application developers are applied to business users according to grants given by the subscribers user administrator, that is, they're applied tenant-specific.
 
-CAP authorizations can be defined dependently from [user claims](/guides/security/authorization#user-claims) such as [XSUAA scopes or attributes](https://help.sap.com/docs/btp/sap-business-technology-platform/application-security-descriptor-configuration-syntax)
+CAP authorizations can be defined dependently from [user claims](authorization#user-claims) such as [XSUAA scopes or attributes](https://help.sap.com/docs/btp/sap-business-technology-platform/application-security-descriptor-configuration-syntax)
 that are deployed by application developers and granted by the user administrator of the subscriber.
 Hence, CAP provides a seamless integration of central identity service without technical lock-in.
 
@@ -222,7 +222,7 @@ Based on the CDS model and configuration of CDS services, the CAP runtime expose
 | Name              | Configuration    | URL                                       | Authorization                                 |
 |-------------------|------------------|-------------------------------------------|-----------------------------------------------|
 | CDS Service `Foo` | `service Foo {}` | `/<protocol-path>/Foo/**`<sup>1</sup>     | `@restrict`/`@requires`<sup>2</sup>           |
-|                   | OData v2/v4      | `/<odata-path>/Foo/$metadata`<sup>1</sup> | See [here](/guides/security/authorization#requires) |
+|                   | OData v2/v4      | `/<odata-path>/Foo/$metadata`<sup>1</sup> | See [here](authorization#requires) |
 | Index page        |                  | `/index.html`                             | none, but disabled in production              |
 
 > <sup>1</sup> See [protocols and paths](../../java/cqn-services/application-services#configure-path-and-protocol)
@@ -302,7 +302,7 @@ CAP guarantees that code for business requests runs on a DB connection opened fo
 ### Isolated Transient Data { #isolated-transient-data }
 
 Although CAP microservices are stateless, the CAP Java runtime (generic handlers inclusive) needs to cache data in-memory for performance reasons.
-For instance, filters for [instance-based authorization](/guides/security/authorization#instance-based-auth) are constructed only once and are reused in subsequent requests.
+For instance, filters for [instance-based authorization](authorization#instance-based-auth) are constructed only once and are reused in subsequent requests.
 
 <div class="impl java">
 
diff --git a/guides/uis/fiori.md b/guides/uis/fiori.md
@@ -520,7 +520,7 @@ SELECT.from(Books.drafts) //returns all drafts of the Books entity
 
 ## Use Roles to Toggle Visibility of UI elements
 
-In addition to adding [restrictions on services, entities, and actions/functions](/guides/security/authorization#restrictions), there are use cases where you only want to hide certain parts of the UI for specific users. This is possible by using the respective UI annotations like `@UI.Hidden` or `@UI.CreateHidden` in conjunction with `$edmJson` pointing to a singleton.
+In addition to adding [restrictions on services, entities, and actions/functions](../security/authorization#restrictions), there are use cases where you only want to hide certain parts of the UI for specific users. This is possible by using the respective UI annotations like `@UI.Hidden` or `@UI.CreateHidden` in conjunction with `$edmJson` pointing to a singleton.
 
 First, you define the [singleton](../advanced/odata#singletons) in your service and annotate it with [`@cds.persistence.skip`](../databases/index.md#cds-persistence-skip) so that no database artefact is created:
 
diff --git a/node.js/_menu.md b/node.js/_menu.md
@@ -62,4 +62,4 @@
 # [Testing](cds-test)
 # [TypeScript](typescript)
 # [Best Practices](best-practices)
-# [Integrate with UCL](ucl)
+# [Integrate with UCL](../../node.js/ucl)
diff --git a/node.js/authentication.md b/node.js/authentication.md
@@ -430,7 +430,7 @@ export default function custom_auth(req: Req, res: Response, next: NextFunction)
 }
 ```
 
-[If you want to customize the user ID, please also have a look at this example.](/node.js/cds-serve#customization-of-cds-context-user){.learn-more}
+[If you want to customize the user ID, please also have a look at this example.](cds-serve#customization-of-cds-context-user){.learn-more}
 
 
 ## Authentication in Production
diff --git a/node.js/cds-connect.md b/node.js/cds-connect.md
diff --git a/node.js/cds-facade.md b/node.js/cds-facade.md
diff --git a/node.js/remote-services.md b/node.js/remote-services.md

Original file line number	Diff line number	Diff line change
`@@ -430,7 +430,7 @@ export default function custom_auth(req: Req, res: Response, next: NextFunction)`
`430`	`430`	`}`
`431`	`431`	```
`432`	`432`
`433`		`-[If you want to customize the user ID, please also have a look at this example.](/node.js/cds-serve#customization-of-cds-context-user){.learn-more}`
	`433`	`+[If you want to customize the user ID, please also have a look at this example.](cds-serve#customization-of-cds-context-user){.learn-more}`
`434`	`434`
`435`	`435`
`436`	`436`	`## Authentication in Production`