## About the changes
When checking for permissions we have 2 methods, one that is not change
request aware and one that is. We were using the one that is not aware
of CR while the feature we developed is aware of CR.
This PR switches to the correct method and documents the hooks
Fixes a bug where some variant tables did not render properly if
scrolled all the way down.
Since we are not expecting to need virtualisation in these tables
anyways (each table should hopefully have a relatively low amount of
variants), reverting the `VirtualizedTable` usage to a normal one seemed
like the most straightforward solution at this stage, fixing the issue
without any noticeable side effects.
![image](https://user-images.githubusercontent.com/14320932/214568043-038ca72e-7f23-4114-8415-fb4eb287154e.png)
## About the changes
Add warnings when we detect something might be wrong with the customer
configuration, in particular with regard to variants configuration
## Rationale
Moving from variants per feature to variants per environment will allow
users to have fine-grained permissions and more control over variants on
different environments: #2254
But because this requires an additional step of copying variants to
other environments, we identified the potential risk of users forgetting
to follow this step. To keep them informed about this, we're introducing
a warning sign after a toggle is enabled when we detect that:
1. The environment is enabled without variants
2. Other enabled environments have variants
This situation would be a problem if you rely on `getVariant` method
from the SDK, because without variants you'll receive the default
variant. Probably, not what you'd expect after enabling the toggle, but
there are situations where this might be correct. Because of the latter,
we thought that adding a warning and letting the user handle the
situation was the best solution.
## UI sketches
![image
(6)](https://user-images.githubusercontent.com/455064/213676353-112639f0-7781-42c0-8c9d-8c7eba316bae.png)
![Screenshot from 2023-01-19
08-55-10](https://user-images.githubusercontent.com/455064/213664639-7b11ff4b-048a-4a36-aa71-7df2f889adff.png)
Co-authored-by: Nuno Góis <github@nunogois.com>
https://linear.app/unleash/issue/2-563/fix-issue-with-useconditionallyhiddencolumns-and-react-table
It seems like we should add `autoResetHiddenColumns: false` to
`useTable` whenever we use `useConditionallyHiddenColumns`.
Basically the thought is that, if we're controlling column visibility in
our own way, we should not want other things to change that state
unpredictably, otherwise this may make React go _brrrrrr_. And it can be
very hard to pinpoint what exactly may be causing React to go _brrrrrr_.
![image](https://user-images.githubusercontent.com/14320932/211332339-95918c5c-e3ea-40e9-b8b4-756a798a4702.png)
First detected this issue apparently randomly while developing the new
SA table. Around 10-20 page refreshes would eventually trigger it. Was
not easy to find, but hopefully this fixes it permanently. At least I
haven't been able to reproduce it since. Maybe someone has a better idea
of where the issue could be or if this is a pretty good guess. Doesn't
seem like this change hurts us anyways.
I love React, `useEffect` and these very to-the-point error messages.
Very fun and productive.
Reference: https://react-table-v7.tanstack.com/docs/api/useTable
## About the changes
According to our docs, we only support up to 1 decimal place for
weights. This is to use integers to represent the percentages (we divide
them by 10) and supporting more decimals results in bad maths due to
floating point arithmetics.
This PRs adds Frontend and Backend validations to enforce this
restriction
Closes#2222
## Discussion points
Should we reconsider supporting more decimal places, that door remains
open, but for now we'll just adhere to our documentation because that
change would require some development.
## What
This PR fixes some broken links we had in the application. It also adds
redirects for those links so that they should work in the future.
## Why
Because it's important to have links that work 💁
## 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.
![image](https://user-images.githubusercontent.com/14320932/202286759-b9c30228-59cc-4c58-a7b0-3c6c3d0ecba6.png)
## About the changes
https://linear.app/unleash/issue/2-425/variants-crud-new-environment-cards-with-tables-inside-add-edit-and
Basically created parallel components for the **variants per
environments** feature, so both flows should work correctly depending on
the feature flag state. Some of the duplication means that cleanup
should be straightforward - Once we're happy with this feature it should
be enough to delete
`frontend/src/component/feature/FeatureView/FeatureVariants/FeatureVariantsList`
and do some little extra cleanup.
I noticed we had some legacy-looking code in variants, so this involved
*some* rewriting of the current variants logic. Hopefully this new code
looks nicer, more maintainable, and more importantly **doesn't break
anything**.
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2254
### Important files
Everything inside the
`frontend/src/component/feature/FeatureView/FeatureVariants/FeatureEnvironmentVariants`
folder.
* fix: general select component typings
* custom multi-select for projects
* autocomplete element for token projects
* project multi-select with error handling
* projects in tokens list update
* multi-project tokens - select all button
* fix conflicting typescript changes
* improve multi-projects tokens form after review
* refactor multi-project select code structure
* test api token list projects column element
* simplify test renderer
* refactor: remove unused securityLogger
* refactor: port commonStyles to TS
* refactor: port testIds to TS
* refactor: move app.css into themes
* refactor: use absolute import paths
* refactor: port LayoutPicker to TS
* refactor: port routes to TS
* refactor: port ScrollTop to TS
* refactor: update unused/missing ScrollTop exceptions
* refactor: remove unused route flags field
* refactor: change constants ext to TS
* refactor: remove unused testData file
* refactor: port styles to TS
* refactor: wait before typing in auth spec