HMS-9490: create templates with extended support repos#849
Draft
katarinazaprazna wants to merge 6 commits intocontent-services:mainfrom
Draft
HMS-9490: create templates with extended support repos#849katarinazaprazna wants to merge 6 commits intocontent-services:mainfrom
katarinazaprazna wants to merge 6 commits intocontent-services:mainfrom
Conversation
Reviewer's GuideExtends the templates creation/editing flow to support extended support (EUS/E4S) content versioning, updates the shared context and wizard step logic accordingly, and wires the new data fields through API types, routing, and tests. Class diagram for updated template and content modelsclassDiagram
class AddOrEditTemplateContextInterface {
+QueryClient queryClient
+NameLabel[] distribution_arches
+NameLabel[] distribution_versions
+NameLabel[] extended_release_features
+DistributionMinorVersion[] distribution_minor_versions
+Partial_TemplateRequest templateRequest
+setTemplateRequest(value)
+Set~string~ selectedRedhatRepos
+setSelectedRedhatRepos(uuidSet)
+Set~string~ selectedCustomRepos
+setSelectedCustomRepos(uuidSet)
+Set~string~ hardcodedRedhatRepositoryUUIDS
+hasInvalidSteps(index) boolean
+boolean isEdit
+string editUUID
}
class TemplateRequest {
+string arch
+string version
+boolean use_extended_support
+string extended_release
+string extended_release_version
+string date
+string description
+string name
+string[] repository_uuids
+boolean use_latest
}
class TemplateItem {
+string uuid
+string name
+string description
+SnapshotItem[] snapshots
+SnapshotItem[] to_be_deleted_snapshots
+string arch
+string version
+boolean use_extended_support
+string extended_release
+string extended_release_version
+string date
+boolean use_latest
+string created_at
}
class RepositoryParamsResponse {
+NameLabel[] distribution_versions
+NameLabel[] distribution_arches
+NameLabel[] extended_release_features
+DistributionMinorVersion[] distribution_minor_versions
}
class NameLabel {
+string name
+string label
}
class DistributionMinorVersion {
+string name
+string label
+string major
+string[] feature_names
}
class ContentItem {
+string uuid
+string name
+string url
+number package_count
+string? extended_release
+string? extended_release_version
}
class FilterData {
+string search
+string[] versions
+string[] arches
+string extended_release
+string extended_release_version
+string[] statuses
+string[] uuids
+string[] urls
}
AddOrEditTemplateContextInterface --> TemplateRequest : manages
AddOrEditTemplateContextInterface --> RepositoryParamsResponse : uses
RepositoryParamsResponse --> NameLabel : contains
RepositoryParamsResponse --> DistributionMinorVersion : contains
DistributionMinorVersion --> NameLabel : compatible labels
TemplateItem --> TemplateRequest : related shape
ContentItem --> DistributionMinorVersion : associated via extended_release_version
FilterData --> ContentItem : filters
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Contributor
katarinazaprazna
force-pushed
the
create-templates-with-extended-support-repos
branch
3 times, most recently
from
c279f94 to
31d66cd
Compare
rverdile
reviewed
Jan 27, 2026
Contributor
rverdile
left a comment
rverdile
left a comment
There was a problem hiding this comment.
This looks pretty good so far. I think we still need to hear from UX, but these are some changes that will move us in the right direction either way.
...Pages/Templates/TemplatesTable/components/AddOrEditTemplate/steps/RedHatRepositoriesStep.tsx
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
We don't want the template extended release or release version to be editable. We will make the version editable in a followup ticket.
src/Pages/Templates/TemplatesTable/components/AddOrEditTemplate/steps/ExtendedSupportStep.tsx
Outdated
Show resolved
Hide resolved
katarinazaprazna
force-pushed
the
create-templates-with-extended-support-repos
branch
4 times, most recently
from
2118b41 to
8023d2a
Compare
katarinazaprazna
force-pushed
the
create-templates-with-extended-support-repos
branch
8 times, most recently
from
b13758f to
7365801
Compare
rverdile
reviewed
Feb 12, 2026
src/Pages/Templates/TemplatesTable/components/templateHelpers.ts
Outdated
Show resolved
Hide resolved
rverdile
reviewed
Feb 12, 2026
src/Pages/Templates/TemplatesTable/components/AddOrEditTemplate/steps/ExtendedSupportStep.tsx
Outdated
Show resolved
Hide resolved
katarinazaprazna
force-pushed
the
create-templates-with-extended-support-repos
branch
8 times, most recently
from
551a936 to
8b301c4
Compare
katarinazaprazna
force-pushed
the
create-templates-with-extended-support-repos
branch
4 times, most recently
from
7b9f0d1 to
b57646b
Compare
rverdile
reviewed
Feb 24, 2026
src/Hooks/useDistributionDetails.tsx
Outdated
Comment on lines
36
to
41
| /** Converts an OS label (e.g., "9") or array of labels to a user-friendly display string (e.g., "RHEL 9" or "RHEL 8, RHEL 9"). */ | ||
| const getVersionName = useCallback( | ||
| (version?: string | string[]): string => { | ||
| if (!version) return ''; | ||
| const versions = Array.isArray(version) ? version : [version]; | ||
| const displayNames = versions |
Contributor
There was a problem hiding this comment.
I thought we would leave this conversion out of the frontend, in favor of changing what the API returns on a different ticket?
Contributor
There was a problem hiding this comment.
This change would impact more than just extended release support, so it makes sense to handle is separately
Contributor
Author
There was a problem hiding this comment.
This part was implemented before our discussion, but I'm completely on board with moving it. Even with the conversion inside getVersionName, we didn't manage to catch every instance, so handling this on the BE is definitely the way to go. Once that’s ready, I’ll strip this logic out of the FE
I'll make sure to document all these decisions and trade-offs in the PR description by Thursday
Contributor
There was a problem hiding this comment.
Why don't we remove it from here? Meaning let's just have the UI say "el" instead of "RHEL" for now. Once backend is updated then there shouldn't be any changes needed here.
Contributor
Author
There was a problem hiding this comment.
If we’re okay with this skipping the upcoming demo, I can just remove it for now to keep things clean :)
Contributor
There was a problem hiding this comment.
Yeah I think that's okay :) It came out of our UX meetings for this, but it's really an app-wide change
rverdile
reviewed
Feb 24, 2026
src/Pages/Templates/TemplatesTable/components/AddOrEditTemplate/steps/OSAndArchitectureStep.tsx
Outdated
Show resolved
Hide resolved
rverdile
reviewed
Feb 24, 2026
| ? getMinorVersionName(major, minor) | ||
| : getVersionName(major) || 'Select version', | ||
| Architecture: getArchName(arch) || 'Select architecture', | ||
| 'Core Red Hat repositories': redHatCoreRepos.size, |
Contributor
There was a problem hiding this comment.
Was changing it to "core red hat repositories" suggested by Maria? Otherwise I think we should leave it as "pre-selected"
Contributor
Author
There was a problem hiding this comment.
We touched on this during a quick UX review and there weren't any objections, but I've followed up with her now for an explicit confirmation. Will keep you posted
rverdile
reviewed
Feb 24, 2026
Contributor
There was a problem hiding this comment.
I noticed that creation fails because the label for the extended release is wrong ("RHEL-EUS-x86_64" vs "eus"). There's two issues here, one is the repository_parameters API should be updated to return the correct label. The other is that the template API should have proper validation.
I opened a ticket to address these issues: https://issues.redhat.com/browse/HMS-10252
Contributor
There was a problem hiding this comment.
Here's what I'd suggest. On your PR, let's convert "RHEL-EUS-x86_64" to "eus" for now, since it looks like you've already written a method to do that, featureNameToExtendedRelease. And assuming this PR merges first, we can update the UI again once the backend is fixed.
Contributor
Author
There was a problem hiding this comment.
@rverdile I've just noticed the architecture locator was enabled by default in the original code. With the new EUS logic, I’ve kept it disabled for all paths
The reason for this is to gate the arch selection until the Stream and OS are picked. This prevents invalid configurations. For example, RHEL 9.6 EUS wasn't available on ARM yet, so picking Stream -> OS -> Arch ensures the user only sees compatible options
The two failing tests were trying to select the Arch before the OS, which was a leftover from my earlier test fixes. I’ve updated those tests now to follow the correct order, and they should be passing
katarinazaprazna
force-pushed
the
create-templates-with-extended-support-repos
branch
5 times, most recently
from
5c9daa1 to
9e905f7
Compare
- Updated template request model to include `extended_release` and `extended_release_version` fields - Initialized template request with default extended support values to prevent undefined state - Integrated repository parameters API to fetch extended release features and distribution minor versions
Redesign the template creation modal to consolidate OS and arch selection into a single step. Rename and refactor all related components for better clarity. - Merge DefineContentStep and ExtendedSupportStep into OSAndArchitectureStep - Update step validation and context management for new workflow - Update templateHelpers for consolidated repo URL generation - Improve core repository preselection logic and timing - Refactor useDistributionDetails hook methods - Rename RedhatRepositoriesStep to RedHatRepositoriesStep (casing fix)
Rename the hook and its return values to better convey that it
checks for Insights-registered systems compatible with a template's
configuration (arch, OS version, stream), not just any registered
systems.
While working on the rename, I discovered that the Patch API returns a
404 when querying /templates/{id}/systems for templates with no assigned
systems. This caused an ugly "Unable to find systems" error notification
on every visit to such a template's Systems tab. We now catch the 404 in
the API service layer and normalize it to an empty response, so
consumers treat "no systems assigned" as an expected empty state rather
than an error.
Extend the system assignment flow to distinguish between Standard and EUS/E4S templates. Standard templates only allow systems on a major release, while EUS templates require systems pinned to a minor release. Additionally: - Show the minor version and abbreviated stream name (e.g. "EUS") in the TemplateDetails header for extended support templates. - Disable the release stream dropdown during template editing, since changing it after creation is not supported.
katarinazaprazna
force-pushed
the
create-templates-with-extended-support-repos
branch
from
9e905f7 to
fb22916
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR aligns the frontend template logic with upcoming changes in the content-sources-backend. It ensures the UI handles extended support features and point-release targeting in parity with the evolving API contract.
The frontend logic is designed to integrate with the following backend updates:
repository_parameters/endpoint.repositories/endpoint.templates/endpoint.Screenshots
User without EUS subscription
User with EUS subscription
Testing steps