Adds icons to sidebar documentation and removes the link when you can't
interact with it.
I'm a little concerned that this won't be very accessible at the moment,
because we don't announce that anything has changed (i.e. there's no way
to find out that the text has changed if you can't see it), and the text
isn't labeled as describing anything. (this is being addressed in #7110
)
There's a few caveats to this:
1. we don't set a min height at the moment. I've avoided this because we
use the sidebar a number of other places and I wanted to touch as little
as possible. This means we can still get height adjustments
2. The new project icon doesn't have the same proportions as the mui
icons. This adds some additional jank. We should probably look at this,
though.
I've marked the project creation dialog as "compact", so that it's only
as tall as it needs to be.
However, by default, compact forms don't scroll because they have
overflow set to hidden. This is a problem on very short windows. To get
around this, I've set overflow to unset on compact forms.
I've also removed `min-height: 0` which has some weird side effects on
the centered dialog. Instead, I'm setting `min-height` to `unset` if
it's compact.
This task also uncovered some inconsistencies and some borders that only
show up sometimes, so I've removed them too.
I realized that, in an oversight, the form now shows and sends project
CR config, even if the new form isn't active. The API just ignores it if
it doesn't understand it, so it's not very harmful, but it's better if
we don't send it at all. This PR does that.
It does not actually test that change request info isn't included (but
it does test ID inclusion). This is because:
- change request info is only included if we're enterprise. The rendered
version of the hook isn't by default.
- Setting up module mocking and making it work seems like a lot of work
for a small gain, considering we're probably going to be removing the
old form anyway.
- I've tested it locally.
Also adds some testing for the hook related to name validation and
payload creation
Instead of using the `required` attribute, we manually make it
required. This is indicated visually by red error text if the value is
empty (or whitespace only). To indicate to screen readers that it is
required, we add the `aria-required` attribute.
We didn't previously validate if the name
was whitespace only.
Also: if no envs are selected, indicate that all will be included
This prevents this form value from ever being invalid.
It seems the code that was copied was copied from before we changed
the validation logic, so it wouldn't submit. This fixes that to remove
any ID validation in the new form.
This PR adds the ability to configure CRs when creating a project.
The design is unfinished, and the code certainly needs cleanup, but I'd
like to get this into sandbox so we can look at it.
Things that still need to be done:
1. What do we do about this button when the user has no environments
selected? As a rough draft, I've disabled it. However, we should make it
possible to navigate to and give you an explanation why it was disabled,
e.g. "You have no project environments selected. Please select at least
one project environment.".
2. The form design is not done: the width should be constant and not
jumpy the way it is now. Also, the search field is too wide.
3. I've made the desicion that if you deselect a project env, we also
remove that env from your CR config it it's in there.
4. Potential improvement: if you enable and then disable CRs for an env,
we *could* probably store the data in between, so that if you set
required approvers 5 and then disabled it, it'd still be 5 when you
re-enabled it. That sounds like a good user experience. We should also
be able to extend that to adding/removing environments from project
envs.
This PR is a combination of two PRs:
This PR adds a functioning environment selection button to the new project creation form. Selected environments are added to the payload and to the API preview.
The implementation is mostly lifted from the existing FilterItem component we have for search filters. However, our need here is less complex, so I've removed some of the things we don't need. There is still more cleanup to be done, however, but I'd like to implement the rest of the submenus first, to see what we really do need in the end.
---
This PR adds support for stickiness and project mode in the new project
creation form.
Achieve this, it does a few things:
1. Moves `resolveStickinessOptions` from
`frontend/src/component/feature/StrategyTypes/FlexibleStrategy/StickinessSelect/StickinessSelect.tsx`
and into a separate hook. This component was used by the old project
creation form. Because the new form has a different input, but needs the
same option, moved that code into a reusable hook.
2. It adds functioning buttons for project stickiness and mode.
3. It adds labels to the search inputs for the dropdowns. Inputs *must*
have labels to meet a11y requirements. However, the designs don't have
labels, so we can hide them visually. Though that leads to another issue
(refer to the screen shot below).
4. It updates the `SelectionButton` component to handle both single- and
multiselect cases. It instead exports these two subcomponents. These are
currently in one file, but I'll split them out into their separate files
in a later PR.
As a side effect of working with the selection buttons, it also improves
how we handle keyboard interaction for these buttons.
Here's what it looks like for single-select lists. Notice the missing
part of the input's border around the top (where the label *would* be if
we showed it). We should figure out how best to handle it. I've done
like this for now, but we can sort it out later.
This PR allows very simple project creation. You can add a name and
description. The ID is generated for you at the moment (we'll fix this
later). Nothing else works, but the project is created successfully.
This PR adds a very rough first implementation of the look of the new
project form. *It is not final and does not work yet*.
The important part here is that the layout is roughly right (we'll
adjust spacing etc later) and that we've got all the basic elements
present.
I'll hook it up to actually work in an upcoming PR.
The missing icon, text alignment, etc, will also be solved later.
This adds replace: true to navigate on the create feature toggle screen
and create project screen. This will make it so you don't go back to the
form after you have created the resource, replacing the entry in the
history with the new url. We can do this in more places, but some of
them require a bit more thought. For example when creating a user, you
navigate from the admin screen to the user page, and then back to the
same screen. Adding `{ replace: true }` in this context makes it so that
when you press back you end up on the same screen, because it's recorded
twice in history.
Another discussion point:
* Would you expect the edit screens to also replace the history?
This PR adds a feature naming pattern description to the project form.
It's rendered as a multi-line input field. The description is also
stored in the db.
This adapts most of @andreas-unleash's PR #4599 with some minor changes
(using description instead of prompt). Actually displaying this data to
the users will come in a later PR.
Adds a first iteration of feature flag naming patterns. Currently behind a flag.
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Co-authored-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
Adds plausible tracking when default project stickiness is changed
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
This PR replaces localStorage with api calls for getting/setting project
scoped stickiness
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Project scoped stickiness
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
Adds `projectScopedStickiness` flag to experimental.ts
Refactor Stickiness select for reusability
Modify FlexibleStrategy to respect the setting.
Modify EnvironmentVariantModal to respect the setting
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
