This updates the Registration step as per recent mocks.
There is now only one checkbox which switches between (register everything now / register later). When the checkbox is not checked "register later" option gets selected, activation key dropdown gets disabled and information about activation keys is hidden to support the fact that no activation key will be used.
When the checkbox is checked it either loads previously used activation key in the case of "on edit" scenario, looks for a recently used activation key in localStorage or in a case there are no activationKeys automatically creates and selects one.
The Next button gets disabled only when "register-now" is selected, but there is no activationKey selected. As the option to clear the dropdown got removed this should occur only when fetching/creating activation key.
When a package got selected and deselected again, landing on 0 for selected packages, the information shown in the package recommendations was "Select packages to generate recommendations.No recommendations found for the set of selected packages", this updates the logic to separate the messages.
Before, in the Oscap step, the drop down select menu was only listing profile_ids
Now, it shows the profiles names. When the user selects one, the details about the
profile are displayed under the selection, improving user experience.
FIXES# HMS-3087
The "Activation keys page" link on the Registration step previously led to prod from both prod and stage envs.
This fixes the problem and ensures that the button in stage links to the activation key management in stage and the prod one to prod.
This commit extends the supported architectures to aarch64. In the image
output step (the first one of the wizard) the user is now faced with a
new select choices to pickup the architecture they want to build.
Now the set of compatible targets to build is dynamically loaded from
the backend and the UX changes what's accessible on the fly depending on
what's the user has been selected.
Refs HMS-1135
There was a mixup on our side between what is a profile and what is a
policy. Long story short, a policy a super set of rules including a
profile. For now the wizard is only able to apply profiles and no
policies on images. So let's fix the terminology there.
When the user has selected a profile to customize their distribution,
the FSC step now shows immediately the manual configuration opened up
with the partitions coming from the profile already filled in.
If the user goes back to the Compliance step and changes anything, the
FSC step is going to be reinitialized.
HMS-2077
Do not show the oscap step outside of beta. Only protecting the step
itself is sufficient since the FSC and the Packages steps wont load any
profile data if no entry point allows to get one.
HMS-2077
wizardrecreatebeta
This commit adds the Compliance step to the wizard. In this step the
user can select a policy from the list of available policies. Their
image is going to be updated with the necessary changes on the later
steps.
IB and The compliance endpoint are both returning the list of policies a
user has access to. The oscap step computes the intersection of the
policies accessible before showing the select list to the user.
HMS-2077
Adding GCP image sharing option according to the discussion on slack(https://redhat-internal.slack.com/archives/C03AZ0264LW/p1692789579814619) and mocks(https://issues.redhat.com/browse/HMS-2352).
In summary, within our GCP sources, we store the project ID. Images cannot be shared directly with a project ID, but they can be shared with a service account or a Google account. Consequently, to launch instances in GCP, users are not required to provide their Google account; instead, the images should be shared with the provisioning service account. This ensures that the provisioning team has access to the necessary images, as sharing them with individual users would not allow that.
After a thorough discussion, we have collectively decided to introduce an option. This option allows users to exclusively utilize the Launch service without the need to share the image with a Google account.
This updates the Repositories and Review step as per [mocks](https://www.sketch.com/s/d7aa6d29-fca0-4283-a846-09cc5fd10612/a/MyEbDz7).
Repositories with the unavailable or invalid status have a popover that allows for further inspection. The time of the last introspection and the counter of failed attempts was added to the popover, together with the "Go to Repositories" button.
On Recreate the payload repositories are checked against "freshly" fetched list of repositories. In case any of the previously checked repositories is no longer available in content sources an Alert is rendered on both Repositories and Review steps. The unavailable repository is checked, but the checkbox is disabled and the information is dashed out. Since the information about the repository is stored in the Repository type, the only information available to be rendered is the baseurl.
Create image button is also disabled when recreating an image with unavailable repositories.
This moves Beta only features to stable environment:
- Sharing Images through Sources
- Launch button
This tries to avoid any refactoring, just moving components from Beta to stable with minimal changes.
This adds validation of an image name based on a pattern, which was chosen as an intersection of the naming constrains of hyperscalers.
The pattern is based on the one for naming GCP images as those naming guidelines are the most restrictive. With added minimal length restriction of AWS.
