When there was only one option we the add button was disabled and
we couldn't add the one option.
This change fixes it so that we can still select the single option if
desired.
rancher/rancher#23780
When editing both single and multi-cluster apps if you modified the
Template Version or the Target Projects and then cancelled it the
underlying store was still modified which then reflected those changes
on other pages like the single and multi-Cluster Apps pages.
To change this I cloned and nested the fields into a nested object named
'editable' and updated the primarySource on willSave for the relevant
targets subfield.
rancher/rancher#21228
The node sortkey was displayname instead of node.sortName which
caused sorting to behave strangely.
I switched the sortkeys and added more to the sortkey array to
help provide a more stable sort.
rancher/rancher#21218
because we did not delay the readiness of the application when loading
translations when a user hit `update-setting` route we'd render the page before
the language had finished loading. Moving the language to the before model and
in the finally of the detect phase ensures we have our language loaded before we
remove the loading state and render the main content.
rancher/rancher#23776
When creating and editing a Project we wanted to only reveal the
PodSecurityPolicy selector if the cluster had the pspEnabled field
set to true.
rancher/rancher#21548
I think the file it self may look more verbose as I've broken several of the
confusing portions into pure(ish) functions. I think this reduces the complexity
of the logic and makes it easier to read. Hopefully this will reduce the bugs
that keep cropping up.
We want to provide the owner as additional information when showing
node templates on the node templates page. We also want to make it so
that when selecting a node template the users templates will be grouped
and sorted to the top by default.
rancher/rancher#23325
creationType was using the wrong values after refactoring to
combine two dropdowns into one. I renamed the existing
config.creationType to creationMethod and now observe
creationMethod to properly set config.creationType.
When global roles were added the front end had to make some assumptions for
non-admin users to ensure the user had login access. This role used to be hidden
but was made visible by default. With this exposed we now check before save if
the user has some kind of login access and throw an error if not. We also no
longer need to hide the custom roles which allows new user default roles to be
displayed without all the crazy logic to decide which mode to show. The old
login-access read only param was removed; This used to map to user-base and we
only displayed it because the role was hidden.
rancher/rancher#23644