Updates feature availability.
Banners is a feature that is already GA'd since Unleash 5.7, so beta
availability seems irrelevant now.
We removed the mention of planning to GA Signals & Actions in 5.12,
since that's not happening and we would prefer not to include these
mentions in the future.
Hello!
We wanted to make the docs less impersonal, so we decided to add
contributors. Now each doc page that has an `editUrl` (i.e, isn't
generated) shows a list of everyone that contributed to it.
This list is generated by:
1. Running `swizzle` on the `DocItem/Footer` in Docusaurus.
2. Grabbing metadata for the current file using an internal docusaurus
API (Thank you to @homotechsual for the help there)
3. Getting the commits to the file in question with the GitHub API
<details>
<summary> Here's the command I ran, for posterity </summary>
<code>npm run swizzle @docusaurus/theme-classic DocItem/Footer --
--wrap</code>
</details>
## Discussion points
1. Design. What do you think of the layout?
2. Right now I'm hardcoding the info of Unleash team members. This
creates a small maintenance burden, but it's something we wanted to add.
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.
Add a flag to enable/disable the new UI for project creation.
This flag is separate from the impl on the back end so that we can
enable one without the other (but uses flag dependencies in Unleash, so
that we can never enable the new UI without the new back end).
I have not set the flag to `true` in server startup because the form
doesn't work yet, so it's a manual step for now.
This PR removes the workaround introduced in
https://github.com/Unleash/unleash/pull/6931. After
https://github.com/ivarconr/unleash-enterprise/pull/1268 has been
merged, this should be safe to apply.
Notably, this PR:
- tightens up the type for the enable change request function, so we can
use that to inform the code
- skips trying to do anything with an empty array
The last point is less important than it might seem because both the env
validation and the current implementation of the callback is essentially
a no-op when there are no envs. However, that's hard to enforce. If we
just exit out early, then at least we know nothing happens.
Optionally, we could do something like this instead, but I'm not sure
it's better or worse. Happy to take input.
```ts
const crEnvs = newProject.changeRequestEnvironments ?? []
await this.validateEnvironmentsExist(crEnvs.map((env) => env.name));
const changeRequestEnvironments =
await enableChangeRequestsForSpecifiedEnvironments(crEnvs,);
data.changeRequestEnvironments = changeRequestEnvironments;
```
Hello,
As discussed with @sighphyre, there were a number of problems with the
examples docs. This addresses the most pressing ones, namely:
- Corrected the link to the Jira plugin
- Added deprecation warning to Jira Server pages
- Removed the incomplete markdown table at the end of articles, and the
references to it
---------
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
This PR improves the handling of change request enables on project
creation in two ways:
1. We now verify that the envs you try to enable CRs for exist before
passing them on to the enterprise functionality.
2. We include data about environments and change request environments in
the project created events.
- Adds support for the configuration option for SCIM taking over control
of users and groups
- Moves SCIM settings into SSO config pages (OIDC and SAML). SCIM
registers a callback to be invoked when saving in a parent SSO config
page
Due to how we handle redirects of embedded proxy, we ended up counting
the same request twice. This PR adds a boolean to res.locals which we
then check if set to avoid double counting.
