26.1 fixes

docs-data/property-overrides.json

@@ -2245,7 +2245,7 @@
     "write.caching": {
       "description": "The write caching mode to apply to a topic.\n\nWhen `write.caching` is set, it overrides the cluster property xref:cluster-properties.adoc#write_caching_default[`write_caching_default`]. Write caching acknowledges a message as soon as it is received and acknowledged on a majority of brokers, without waiting for it to be written to disk. With `acks=all`, this provides lower latency while still ensuring that a majority of brokers acknowledge the write. Fsyncs follow <<flushms, `flush.ms`>> and <<flushbytes, `flush.bytes`>>, whichever is reached first.",
       "related_topics": [
-        "xref:develop:config-topics.adoc#configure-write-caching[Write caching]",
+        "xref:develop:manage-topics/config-topics.adoc#configure-write-caching[Write caching]",
         "xref:manage:tiered-storage.adoc[Tiered Storage]",
         "xref:reference:properties/cluster-properties.adoc#write_caching_default[`write_caching_default`]",
         "xref:cluster-properties.adoc#write_caching_default[`write_caching_default`]"
@@ -2255,7 +2255,7 @@
     "write_caching_default": {
       "related_topics": [
         "xref:reference:properties/topic-properties.adoc#writecaching[`write.caching`]",
-        "xref:develop:config-topics.adoc#configure-write-caching[Write caching]"
+        "xref:develop:manage-topics/config-topics.adoc#configure-write-caching[Write caching]"
       ],
       "config_scope": "cluster",
       "description": "The default write caching mode to apply to user topics. Write caching acknowledges a message as soon as it is received and acknowledged on a majority of brokers, without waiting for it to be written to disk. With `acks=all`, this provides lower latency while still ensuring that a majority of brokers acknowledge the write. \n\nFsyncs follow <<raft_replica_max_pending_flush_bytes,`raft_replica_max_pending_flush_bytes`>> and <<raft_replica_max_flush_delay_ms,`raft_replica_max_flush_delay_ms`>>, whichever is reached first.\n\nThe `write_caching_default` cluster property can be overridden with the xref:reference:properties/topic-properties.adoc#writecaching[`write.caching`] topic property."

modules/deploy/pages/redpanda/kubernetes/k-production-readiness.adoc

@@ -529,7 +529,7 @@ Ensure storage classes provide adequate IOPS and throughput for your workload by
 * Use NVMe-based storage classes for production deployments
 * Specify a minimum 16,000 IOPS (Input/Output Operations Per Second)
 * Consider provisioned IOPS where available to meet or exceed the minimum
-* Enable xref:develop:config-topics.adoc#configure-write-caching[write caching] to help Redpanda perform better in environments with disks that don't meet the recommended IOPS
+* Enable xref:develop:manage-topics/config-topics.adoc#configure-write-caching[write caching] to help Redpanda perform better in environments with disks that don't meet the recommended IOPS
 * NFS (Network File System) is not supported
 * Test storage performance under load
 

modules/develop/pages/manage-topics/config-topics.adoc

@@ -1,5 +1,6 @@
 = Manage Topics
 :page-categories: Clients, Development
+:page-aliases: develop:config-topics.adoc
 :description: Learn how to create topics, update topic configurations, and delete topics or records.
 tag::single-source[]
 

modules/develop/pages/produce-data/leader-pinning.adoc

@@ -178,8 +178,14 @@ If a higher-priority rack recovers and the topic's replication factor ensures th
 
 == Suggested reading
 
-// TODO: Add link to Cloud Topics
-// * For latency-tolerant, high-throughput workloads where cross-AZ networking charges are a major cost driver, also consider xref:develop:manage-topics/cloud-topics.adoc[Cloud Topics]
+ifndef::env-cloud[]
+* For latency-tolerant, high-throughput workloads where cross-AZ networking charges are a major cost driver, also consider xref:develop:manage-topics/cloud-topics.adoc[Cloud Topics]
+endif::[]
+ifdef::env-cloud[]
+* For latency-tolerant, high-throughput workloads where cross-AZ networking charges are a major cost driver, also consider xref:develop:topics/cloud-topics.adoc[Cloud Topics]
+endif::[]
+
+
 * xref:develop:consume-data/follower-fetching.adoc[]
 
 // end::single-source[]

modules/get-started/pages/licensing/overview.adoc

@@ -128,6 +128,10 @@ Continuous Intra-Broker Partition Balancing is enabled by default for all new cl
 | Enables compliance with FIPS security standards for cryptography.
 | No change.
 
+| xref:manage:security/authorization/gbac.adoc[Group-Based Access Control (GBAC)]
+| Manages permissions using OIDC group memberships for ACLs and role assignments.
+| ACLs with `Group:` principals cannot be created. Existing group ACLs continue to be evaluated and can be deleted.
+
 | xref:manage:iceberg/topic-iceberg-integration.adoc[Iceberg Topics]
 | Enables Iceberg integration for Redpanda topics.
 | Topics cannot be created or modified with the `redpanda.iceberg.mode` property.

modules/manage/pages/disaster-recovery/shadowing/overview.adoc

@@ -171,7 +171,7 @@ The filtering system you configure determines the precise scope of replication a
 To ensure reliable disaster recovery with Shadowing:
 
 ifndef::env-cloud[]
-* **Avoid write caching on source topics**: Do not shadow source topics that have xref:develop:config-topics.adoc#configure-write-caching[write caching] enabled. Write caching can result in data loss on the source cluster during broker resets, causing cluster divergence if shadow links replicate data before it's lost on the source.
+* **Avoid write caching on source topics**: Do not shadow source topics that have xref:develop:manage-topics/config-topics.adoc#configure-write-caching[write caching] enabled. Write caching can result in data loss on the source cluster during broker resets, causing cluster divergence if shadow links replicate data before it's lost on the source.
 endif::[]
 
 * **Do not modify shadow topic properties**: Avoid modifying synced topic properties on shadow topics, as these properties automatically revert to source topic values.

modules/manage/pages/iceberg/about-iceberg-topics.adoc

@@ -122,7 +122,7 @@ The link:/api/doc/cloud-controlplane/operation/operation-clusterservice_updatecl
 endif::[]
 ifndef::env-cloud[]
 +
-When multiple clusters write to the same catalog, each cluster must use a distinct namespace to avoid table name collisions. This is especially critical for REST catalog providers that offer a single global catalog per account (such as AWS Glue), where there is no other isolation mechanism. By default, Redpanda creates Iceberg tables in a namespace called `redpanda`. To use a unique namespace for your cluster's REST catalog integration, set config_ref:iceberg_default_catalog_namespace,true,properties/cluster-properties[`iceberg_default_catalog_namespace`] at the same time. This property cannot be changed after you enable Iceberg topics on the cluster.
+When multiple clusters write to the same catalog, each cluster must use a distinct namespace to avoid table name collisions. This is especially critical for REST catalog providers that offer a single global catalog per account (such as AWS Glue), where there is no other isolation mechanism. By default, Redpanda creates Iceberg tables in a namespace called `redpanda`. To use a unique namespace for your cluster's REST catalog integration, also set config_ref:iceberg_default_catalog_namespace,true,properties/cluster-properties[`iceberg_default_catalog_namespace`] when you set `iceberg_enabled`. This property cannot be changed after you enable Iceberg topics on the cluster.
 +
 [,bash]
 ----