theforeman · Lennonka · Oct 22, 2025
diff --git a/guides/common/modules/con_applying-errata-to-hosts.adoc b/guides/common/modules/con_applying-errata-to-hosts.adoc
@@ -3,6 +3,7 @@
 [id="applying-errata-to-hosts"]
 = Applying errata to hosts
 
+[role="_abstract"]
 Use these procedures to review and apply errata to hosts.
 
 .Prerequisites

diff --git a/guides/common/modules/con_basic-content-management-workflow.adoc b/guides/common/modules/con_basic-content-management-workflow.adoc
@@ -3,6 +3,7 @@
 [id="Basic_Content_Management_Workflow_{context}"]
 = Basic content management workflow
 
+[role="_abstract"]
 This is a quick overview of the tasks involved in the basic content management workflow in {Project}.
 If you have installed {Project} with Katello and want to synchronize and manage Enterprise Linux content on your hosts, follow the steps in this chapter.
 

diff --git a/guides/common/modules/con_clearing-the-search-filter.adoc b/guides/common/modules/con_clearing-the-search-filter.adoc
@@ -3,6 +3,7 @@
 [id="Clearing_the_Search_Filter_{context}"]
 = Clearing the search filter
 
+[role="_abstract"]
 If you search for specific content types by using keywords in the *Search* text box and the search returns no results, click *Clear search* to clear all the search queries and reset the *Search* text box.
 
 If you use a filter to search for specific repositories in the *Type* text box and the search returns no results, click *Clear filters* to clear all active filters and reset the *Type* text box.
diff --git a/...es/con_comparison-of-content-view-environments-and-composite-content-views.adoc b/...es/con_comparison-of-content-view-environments-and-composite-content-views.adoc
@@ -3,6 +3,7 @@
 [id="comparison-of-content-view-environments-and-composite-content-views"]
 = Comparison of content view environments and composite content views
 
+[role="_abstract"]
 Composite content views provide an alternative method for granting hosts access to content from multiple content views.
 You can use composite content views, multiple content view environments, or a combination of both.
 The key differences between these methods include the following:

diff --git a/guides/common/modules/con_composite-content-views-overview.adoc b/guides/common/modules/con_composite-content-views-overview.adoc
@@ -3,6 +3,7 @@
 [id="Composite_Content_Views_Overview_{context}"]
 = Composite content views overview
 
+[role="_abstract"]
 A composite content view combines the content from several content views.
 For example, you might have separate content views to manage an operating system and an application individually.
 You can use a composite content view to merge the contents of both content views into a new repository.

diff --git a/guides/common/modules/con_configuring-inter-server-synchronization.adoc b/guides/common/modules/con_configuring-inter-server-synchronization.adoc
@@ -3,6 +3,7 @@
 [id="Configuring-ISS_{context}"]
 = Configuring {ISS} (ISS)
 
+[role="_abstract"]
 ifdef::satellite[]
 Configure {ISS} on your disconnected {ProjectServer} to provide content in your disconnected network.
 endif::[]
diff --git a/guides/common/modules/con_content-delivery-network-structure.adoc b/guides/common/modules/con_content-delivery-network-structure.adoc
@@ -3,6 +3,7 @@
 [id="Content_Delivery_Network_Structure_{context}"]
 = Content Delivery Network structure
 
+[role="_abstract"]
 ifdef::katello,orcharhino[]
 [NOTE]
 ====

diff --git a/guides/common/modules/con_content-filter-examples.adoc b/guides/common/modules/con_content-filter-examples.adoc
@@ -3,6 +3,7 @@
 [id="Content_Filter_Examples_{context}"]
 = Content filter examples
 
+[role="_abstract"]
 Use any of the following examples with the procedure that follows to build custom content filters.
 
 [NOTE]

diff --git a/guides/common/modules/con_content-filter-overview.adoc b/guides/common/modules/con_content-filter-overview.adoc
@@ -3,6 +3,7 @@
 [id="Content_Filter_Overview_{context}"]
 = Content filter overview
 
+[role="_abstract"]
 ifdef::satellite[]
 Content views also use filters to include or restrict certain Yum content.
 endif::[]

diff --git a/guides/common/modules/con_content-promotion-across-the-application-lifecycle.adoc b/guides/common/modules/con_content-promotion-across-the-application-lifecycle.adoc
@@ -3,6 +3,7 @@
 [id="Content_Promotion_across_the_Application_Lifecycle_{context}"]
 = Content promotion across the application lifecycle
 
+[role="_abstract"]
 In the application lifecycle chain, when content moves from one environment to the next, this is called _promotion_.
 
 .Example: Content promotion across {Project} lifecycle environments

diff --git a/guides/common/modules/con_content-synchronization-by-using-export-and-import.adoc b/guides/common/modules/con_content-synchronization-by-using-export-and-import.adoc
@@ -3,6 +3,7 @@
 [id="content-synchronization-by-using-export-and-import_{context}"]
 = Content synchronization by using export and import
 
+[role="_abstract"]
 There are multiple approaches for synchronizing content by using the export and import workflow:
 
 * You employ the upstream {ProjectServer} as a content store, which means that you sync the whole Library rather than content view versions.

diff --git a/guides/common/modules/con_content-types-in-project.adoc b/guides/common/modules/con_content-types-in-project.adoc
@@ -3,6 +3,7 @@
 [id="Content_Types_in_{ProjectNameID}_{context}"]
 = Content types in {ProjectName}
 
+[role="_abstract"]
 With {ProjectName}, you can import and manage many content types.
 ifdef::satellite[]
 You can use Red{nbsp}Hat content as well as custom content and organize it into {Project} products.

diff --git a/guides/common/modules/con_content-view-environment-categories.adoc b/guides/common/modules/con_content-view-environment-categories.adoc
@@ -3,6 +3,7 @@
 [id="content-view-environment-categories"]
 = Content view environment categories
 
+[role="_abstract"]
 The content view environments available in your organization fall into the following categories:
 
 Library environment::

diff --git a/guides/common/modules/con_content-view-environment-ordering-and-priority.adoc b/guides/common/modules/con_content-view-environment-ordering-and-priority.adoc
@@ -3,6 +3,7 @@
 [id="content-view-environment-ordering-and-priority"]
 = Content view environment ordering and priority
 
+[role="_abstract"]
 ifdef::satellite[]
 :example-repo-id: satellite-client-6-for-rhel-9-x86_64-rpms
 :example-repo-name: Red Hat Satellite Client 6 for RHEL 9 x86_64 (RPMs)

diff --git a/guides/common/modules/con_content-view-environments-overview.adoc b/guides/common/modules/con_content-view-environments-overview.adoc
@@ -3,6 +3,7 @@
 [id="content-view-environments-overview"]
 = Content view environments overview
 
+[role="_abstract"]
 The *Allow multiple content views* setting controls whether hosts and activation keys can be assigned to multiple content view environments.
 By default, this feature is disabled, limiting assignments to a single content view environment.
 Enable this setting to assign multiple content view environments to hosts and activation keys.

diff --git a/guides/common/modules/con_content-views-in-project.adoc b/guides/common/modules/con_content-views-in-project.adoc
@@ -3,6 +3,7 @@
 [id="Content-Views-in-{ProjectNameID}_{context}"]
 = Content views in {ProjectName}
 
+[role="_abstract"]
 A content view is a deliberately curated subset of content that your hosts can access.
 By creating a content view, you can define the software versions used by a particular environment or {SmartProxyServer}.
 

diff --git a/guides/common/modules/con_download-policies-overview.adoc b/guides/common/modules/con_download-policies-overview.adoc
@@ -3,6 +3,7 @@
 [id="Download_Policies_Overview_{context}"]
 = Download policies overview
 
+[role="_abstract"]
 ifdef::satellite[]
 {ProjectName} provides multiple download policies for synchronizing RPM content.
 endif::[]

diff --git a/guides/common/modules/con_importing-content.adoc b/guides/common/modules/con_importing-content.adoc
@@ -3,6 +3,7 @@
 [id="Importing_Content_{context}"]
 = Importing content
 
+[role="_abstract"]
 This chapter outlines how you can import different types of {customcontent} to {Project}.
 For example, you can use the following chapters for information on specific types of {customcontent} but the underlying procedures are the same:
 

diff --git a/guides/common/modules/con_introduction-to-application-lifecycle.adoc b/guides/common/modules/con_introduction-to-application-lifecycle.adoc
@@ -3,6 +3,7 @@
 [id="introduction_to_application_lifecycle_{context}"]
 = Introduction to application lifecycle
 
+[role="_abstract"]
 The _application lifecycle_ is a concept central to {Project}'s content management functions.
 The application lifecycle defines how a particular system and its software look at a particular stage.
 For example, an application lifecycle might be simple; you might only have a development stage and production stage.

diff --git a/guides/common/modules/con_introduction-to-content-management.adoc b/guides/common/modules/con_introduction-to-content-management.adoc
@@ -3,6 +3,7 @@
 [id="Introduction_to_Content_Management_{context}"]
 = Introduction to content management
 
+[role="_abstract"]
 In the context of {Project}, _content_ is defined as the software installed on systems.
 This includes, but is not limited to, the base operating system, middleware services, and end-user applications.
 ifdef::satellite[]

diff --git a/guides/common/modules/con_limitations-to-repository-dependency-resolution.adoc b/guides/common/modules/con_limitations-to-repository-dependency-resolution.adoc
@@ -3,6 +3,7 @@
 [id="Limitations_to_Repository_Dependency_Resolution_{context}"]
 = Limitations to repository dependency resolution
 
+[role="_abstract"]
 With {Project}, using incremental updates to your content views solves some repository dependency problems.
 However, dependency resolution at a repository level still remains problematic on occasion.
 

diff --git a/guides/common/modules/con_managing-activation-keys.adoc b/guides/common/modules/con_managing-activation-keys.adoc
@@ -3,6 +3,7 @@
 [id="Managing_Activation_Keys_{context}"]
 = Managing activation keys
 
+[role="_abstract"]
 Activation keys provide a method to automate system registration.
 You can create multiple keys and associate them with different environments and content views.
 For example, you might create a basic activation key that enables certain Red Hat repositories and associate it with the appropriate content view.

diff --git a/guides/common/modules/con_managing-alternate-content-sources.adoc b/guides/common/modules/con_managing-alternate-content-sources.adoc
@@ -3,6 +3,7 @@
 [id="Managing_Alternate_Content_Sources_{context}"]
 = Managing alternate content sources
 
+[role="_abstract"]
 Alternate content sources define alternate paths to download content during synchronization.
 The content itself is downloaded from the alternate content source, while the metadata is downloaded from the {ProjectServer} or the upstream URL, depending on the configuration.
 You can use alternate content source to speed up synchronization if the content is located on the local filesystem or on a nearby network.

diff --git a/guides/common/modules/con_managing-ansible-content.adoc b/guides/common/modules/con_managing-ansible-content.adoc
@@ -3,6 +3,7 @@
 [id="Managing_Ansible_Content_{context}"]
 = Managing Ansible content
 
+[role="_abstract"]
 You can import Ansible collections from several sources to {ProjectServer}.
 
 For more information about Ansible integration in {Project}, see {ManagingConfigurationsAnsibleDocURL}[_{ManagingConfigurationsAnsibleDocTitle}_].
diff --git a/guides/common/modules/con_managing-application-lifecycles.adoc b/guides/common/modules/con_managing-application-lifecycles.adoc
@@ -3,4 +3,5 @@
 [id="Managing_Application_Lifecycles_{context}"]
 = Managing application lifecycles
 
+[role="_abstract"]
 This chapter outlines the application lifecycle in {Project} and how to create and remove application lifecycles for {Project} and {SmartProxy}.
diff --git a/guides/common/modules/con_managing-container-images.adoc b/guides/common/modules/con_managing-container-images.adoc
@@ -3,6 +3,7 @@
 [id="Managing_Container_Images_{context}"]
 = Managing container images
 
+[role="_abstract"]
 With {Project}, you can import container images from various sources and distribute them to external containers by using content views.
 
 ifndef::orcharhino[]

diff --git a/guides/common/modules/con_managing-content-view-environments.adoc b/guides/common/modules/con_managing-content-view-environments.adoc
@@ -3,6 +3,7 @@
 [id="managing-content-view-environments"]
 = Managing content view environments
 
+[role="_abstract"]
 A content view environment combines a specific lifecycle environment with a content view and describes which version of the content view to use.
 You can assign hosts and activation keys to one or more content view environments instead of assigning lifecycle environments and content views separately.
 When you assign a host to multiple content view environments, the host gains access to the combined repositories from all its associated content view environments.

diff --git a/guides/common/modules/con_managing-content-views.adoc b/guides/common/modules/con_managing-content-views.adoc
@@ -3,6 +3,7 @@
 [id="Managing_Content_Views_{context}"]
 = Managing content views
 
+[role="_abstract"]
 {ProjectName} uses content views to allow your hosts access to a deliberately curated subset of content.
 To do this, you must define which repositories to use and then apply certain filters to the content.
 

diff --git a/guides/common/modules/con_managing-custom-file-type-content.adoc b/guides/common/modules/con_managing-custom-file-type-content.adoc
@@ -3,6 +3,7 @@
 [id="Managing_Custom_File_Type_Content_{context}"]
 = Managing {customfiletype} content
 
+[role="_abstract"]
 In {Project}, you might require methods of managing and distributing SSH keys and source code files or larger files such as virtual machine images and ISO files.
 To achieve this, {customproduct}s in {ProjectName} include repositories for {customfiletype}s.
 This provides a generic method to incorporate arbitrary files in a product.

diff --git a/guides/common/modules/con_managing-errata.adoc b/guides/common/modules/con_managing-errata.adoc
@@ -3,6 +3,7 @@
 [id="Managing_Errata_{context}"]
 = Managing errata
 
+[role="_abstract"]
 ifdef::satellite[]
 As a part of Red Hat's quality control and release process, we provide customers with updates for each release of official Red Hat RPMs.
 Red Hat compiles groups of related packages into an *erratum* along with an advisory that provides a description of the update.

diff --git a/guides/common/modules/con_managing-flatpak-repositories-in-project.adoc b/guides/common/modules/con_managing-flatpak-repositories-in-project.adoc
@@ -3,6 +3,7 @@
 [id="managing-flatpak-repositories-in-project"]
 = Managing Flatpak repositories in {Project}
 
+[role="_abstract"]
 Flatpak allows users to install, manage, and run portable applications on {Project}, primarily for desktop environments.
 In {Project}, you can integrate Flatpak repositories to distribute and control Flatpak applications across managed hosts. 
 By configuring Flatpak repositories, you ensure that systems have access to the necessary application packages while maintaining centralized control over application deployment.

diff --git a/guides/common/modules/con_managing-iso-images.adoc b/guides/common/modules/con_managing-iso-images.adoc
@@ -3,5 +3,6 @@
 [id="Managing_ISO_Images_{context}"]
 = Managing ISO images
 
+[role="_abstract"]
 You can use {Project} to store ISO images, either from Red{nbsp}Hat's Content Delivery Network or other sources.
 You can also upload other files, such as virtual machine images, and publish them in repositories.
diff --git a/guides/common/modules/con_managing-ostree-content.adoc b/guides/common/modules/con_managing-ostree-content.adoc
@@ -3,6 +3,7 @@
 [id="managing-ostree-content"]
 = Managing OSTree content
 
+[role="_abstract"]
 You can use OSTree to manage bootable, immutable, versioned file system trees.
 
 OSTree makes it easy to install and update Linux-based operating systems on hosts and to switch between versions of operating systems on hosts.

diff --git a/guides/common/modules/con_managing-python-type-content.adoc b/guides/common/modules/con_managing-python-type-content.adoc
@@ -3,6 +3,7 @@
 [id="Managing_Python_Type_Content_{context}"]
 = Managing Python type content
 
+[role="_abstract"]
 You can use {Project} to manage Python type repositories.
 To achieve this, {customproduct}s in {ProjectName} include repositories for Python type content.
 This provides a generic method to incorporate Python packages in a product.

diff --git a/guides/common/modules/con_managing-red-hat-subscriptions.adoc b/guides/common/modules/con_managing-red-hat-subscriptions.adoc
@@ -3,6 +3,7 @@
 [id="Managing_Red_Hat_Subscriptions_{context}"]
 = Managing Red Hat subscriptions
 
+[role="_abstract"]
 {ProjectName} can import content from the Red{nbsp}Hat Content Delivery Network (CDN).
 {Project} requires a Red{nbsp}Hat subscription manifest to find, access, and download content from the corresponding repositories.
 You must have a Red{nbsp}Hat subscription manifest containing a subscription allocation for each organization on {ProjectServer}.

diff --git a/guides/common/modules/con_managing-suse-content.adoc b/guides/common/modules/con_managing-suse-content.adoc
@@ -3,4 +3,5 @@
 [id="Managing_SUSE_Content_{context}"]
 = Managing SUSE content
 
+[role="_abstract"]
 You can use the SCC Manager plugin to manage content from SUSE on your {Project}.
diff --git a/guides/common/modules/con_mirroring-policies-overview.adoc b/guides/common/modules/con_mirroring-policies-overview.adoc
@@ -3,6 +3,7 @@
 [id="Mirroring_Policies_Overview_{context}"]
 = Mirroring policies overview
 
+[role="_abstract"]
 Mirroring keeps the local repository exactly in synchronization with the upstream repository.
 If any content is removed from the upstream repository since the last synchronization, with the next synchronization, it will be removed from the local repository as well.
 

diff --git a/.../common/modules/con_multiple-activation-keys-and-content-view-environments.adoc b/.../common/modules/con_multiple-activation-keys-and-content-view-environments.adoc
@@ -3,6 +3,7 @@
 [id="multiple-activation-keys-and-content-view-environments"]
 = Multiple activation keys and content view environments
 
+[role="_abstract"]
 Registering a host with multiple activation keys assigns different attributes from each key, and their combined settings determine the configuration of the host.
 Note that multiple activation keys and multiple content view environments are not the same.
 Activation keys assign specific attributes to hosts during registration.

diff --git a/guides/common/modules/con_products-and-repositories.adoc b/guides/common/modules/con_products-and-repositories.adoc
@@ -3,6 +3,7 @@
 [id="Products_and_Repositories_{context}"]
 = Products and repositories in {Project}
 
+[role="_abstract"]
 ifdef::satellite[]
 Both Red Hat content and custom content in {Project} have similarities:
 endif::[]

diff --git a/guides/common/modules/con_registering-a-centos-stream-host.adoc b/guides/common/modules/con_registering-a-centos-stream-host.adoc
@@ -3,4 +3,5 @@
 [id="Registering_a_CentOS_Stream_Host_{context}"]
 = Registering a CentOS Stream host to {Project}
 
+[role="_abstract"]
 Use the following procedure to register an existing CentOS Stream host to {Project}.
diff --git a/guides/common/modules/con_resolving-package-dependencies.adoc b/guides/common/modules/con_resolving-package-dependencies.adoc
@@ -3,6 +3,7 @@
 [id="Resolving_Package_Dependencies_{context}"]
 = Resolving package dependencies
 
+[role="_abstract"]
 {Project} can add dependencies of packages in a content view to the dependent repository when publishing the content view.
 To configure this, you can enable _dependency solving_.
 

diff --git a/guides/common/modules/con_restricting-hosts-access-to-content.adoc b/guides/common/modules/con_restricting-hosts-access-to-content.adoc
@@ -3,6 +3,7 @@
 [id="Restricting_Hosts_Access_to_Content_{context}"]
 = Restricting hosts' access to content
 
+[role="_abstract"]
 {Project} offers multiple options for restricting host access to content.
 To give hosts access to a specific subset of the content managed by {Project}, you can use the following strategies.
 {Team} recommends to consider implementing the strategies in the order listed here:

diff --git a/guides/common/modules/con_rolling-content-views.adoc b/guides/common/modules/con_rolling-content-views.adoc
@@ -3,6 +3,7 @@
 [id="rolling-content-views"]
 = Rolling content views
 
+[role="_abstract"]
 A rolling content view is a curated subset of content that your hosts can access.
 It is a subset of the Library environment and contains the latest synchronized content from one or multiple repositories.
 You can use a rolling content view to provide a continuous stream of synchronized content to hosts.

diff --git a/guides/common/modules/con_standardizing-content-view-empty-states.adoc b/guides/common/modules/con_standardizing-content-view-empty-states.adoc
@@ -3,6 +3,7 @@
 [id="Standardizing_Content_View_Empty_States_{context}"]
 = Standardizing content view empty states
 
+[role="_abstract"]
 If there are no filters listed for a content view, click *Create filter*.
 A modal opens to show you the next steps to create a filter.
 Follow these steps to add a new filter to create new content types.
diff --git a/guides/common/modules/con_structured-apt-content.adoc b/guides/common/modules/con_structured-apt-content.adoc
@@ -3,6 +3,7 @@
 [id="Structured-apt-content"]
 = Structured APT content
 
+[role="_abstract"]
 With structured APT content, Deb repositories on {Project} use the same structure as the upstream Deb repository.
 This allows features that attach to the repository structure to work the same way as they would with the upstream repository, for example:
 

diff --git a/guides/common/modules/con_subscribing-to-errata-notifications.adoc b/guides/common/modules/con_subscribing-to-errata-notifications.adoc
@@ -3,6 +3,7 @@
 [id="Subscribing_to_Errata_Notifications_{context}"]
 = Subscribing to errata notifications
 
+[role="_abstract"]
 You can configure email notifications for {Project} users.
 Users receive a summary of applicable and installable errata, notifications on content view promotion or after synchronizing a repository.
 For more information, see {AdministeringDocURL}Configuring_Email_Notification_Preferences_admin[Configuring Email Notification Preferences] in _{AdministeringDocTitle}_.
diff --git a/guides/common/modules/con_synchronizing-content-between-servers.adoc b/guides/common/modules/con_synchronizing-content-between-servers.adoc
@@ -3,6 +3,7 @@
 [id="Synchronizing_Content_Between_Servers_{context}"]
 = Synchronizing content between {ProjectServer}s
 
+[role="_abstract"]
 In a {Project} setup with multiple {ProjectServer}s, you can use {ISS} (ISS) to synchronize content from one upstream server to one or more downstream servers.
 
 There are two possible ISS configurations of {Project}, depending on how you deployed your infrastructure:

diff --git a/guides/common/modules/con_using-activation-keys-for-host-registration.adoc b/guides/common/modules/con_using-activation-keys-for-host-registration.adoc
@@ -3,6 +3,7 @@
 [id="Using_Activation_Keys_for_Host_Registration_{context}"]
 = Using activation keys for host registration
 
+[role="_abstract"]
 You can use activation keys to complete the following tasks:
 
 * Registering new hosts during provisioning through {ProjectName}.

diff --git a/guides/common/modules/con_using-content-views.adoc b/guides/common/modules/con_using-content-views.adoc
@@ -3,6 +3,7 @@
 [id="Using_Content_Views_{context}"]
 = Using content views
 
+[role="_abstract"]
 {Project} uses the concept of content views to create snapshots of a set of repositories and make them available to hosts registered to it.
 For example, if you want a group of hosts to have access to a specific version of a set of repositories, add those repositories to a content view, publish and promote to a lifecycle environment.
 You can then register hosts to this content view.

diff --git a/guides/common/modules/proc_adding-an-http-proxy.adoc b/guides/common/modules/proc_adding-an-http-proxy.adoc
@@ -3,6 +3,7 @@
 [id="Adding_an_HTTP_Proxy_{context}"]
 = Adding an HTTP proxy
 
+[role="_abstract"]
 Use this procedure to add HTTP proxies to {Project}.
 You can then specify which HTTP proxy to use for products, repositories, and supported compute resources.