The basic JS repository is 80kb in size, which is even compressed, too large to include as it includes an amount of stuff that isn't really required. Consider moving to hand-crafted clients only.
It is perfect for node servers but not for mobile or web apps.
It can be that a user doesn't exist and the current person wants to add them right there in the groups page. It should require you to search first and then add if they don't exist, or as you type a new email in it should indicate matches and prevent you creating a person a 2nd time.
Optimize network calls, a single move from one section to another can result in the same backend call 4 or 5 times in a row. Consider memoising or debouncing.
When the first environment gets created, the Dacha does not settle like it should. It should keep polling the MR until someone creates the first application and thus first environment, but once that happens it should settle and become master.
Currently it needs to restart.
Prerequisites
Requires NATs, MR Dacha and an e2e test that creates the basic data required to put it in the right mode. Have MR start with an in memory database, start Dacha so it keeps polling and fire the e2e test to create the organisation, portfolio and therefore application.
Expected behavior:
Dacha should setting after first environment even if there are no features.
Allow an item of configuration, JSON or YAML to store a JSON Schema and have the JSON validated against it. This will prevent bad data from being able to be entered.
Register new user - url lost once move away from register screen, should have a way of getting that URL again, like a copy-url icon in the search or something.
Add API to allow for getting the groups of an application, and have it fill in the environments with automatic ticks for all permissions for admin groups. Currently the Manage App Route bloc calls getPortfolios and asks for its groups and the members of those groups (which is the ACLs) which is an extremely heavy load.
A user should be able to set the list of hidden environments and have them persist across visits. This will require a new user data API in the backend and updates to the admin-ui to enable it to take advantage.
The user api could be structured or arbitrary, if arbitrary it could be abused.
Having the service account permission not enable you to create a new service account is somewhat confusing. Especially if the user doesn't follow the Rocket-Helper.
We should probably add a way to create a new service account from the service account permissions pagge.
Describe the bug
We have upgraded to the latest Flutter Master, commit 4aed97681233a181ef8a135ed2809338473cbe11
A run through of the Admin-UI shows an issue with saving any values. Values (i.e. not flags) are delayed update in the UI because immediate update would make the text boxes lose state and prevent editing. I relied on the framework triggering editingComplete on the text boxes when they were removed from the rendering stack, which in hindsight was not the most reliable.
This changes tracks dirty state for each of the fields and their lock states, and keeps all of the fields managing their own state, calling back to the FeatureValueBloc to compare (and pass) their internal state against the original values. The only cross signal between cells is the locked state, which turns into its own stream of locked/unlock, which causes redraw of the cell as appropriate but the state is stored in each cell as a proper stateful component.
Which area does this issue belong to?
FeatureHub Admin Web app
** testing plan:
lock/unlock each type of value ensuring it locks and unlocks and saves - YES
lock/unlock on non existent value - YES
lock and ensure can’t change - YES
unlock and ensure can change - YES
change each value - YES
reset each type - YES
clear strings, numbers and config and they reset to not set - YES
FeatureHub only needs a name and email - so supporting OAuth2 should be fairly straight forward. It is not supported now as we didn't want it as a pre-requisite for people evaluating the platform.
The UI needs to provide feedback for a user on how they can reset their password. Because the Admin-UI doees not support email, this means it needs to be clear how this can be done.
Mobile needs a GET API so it doesn't keep the radio open. Few Network operators have implemented the SSE handoff discussed in official documentation, so this periodic polling mechanism is worthwhile.
It needs to support multiple SDKURL requests in one, so it should be a simple GET /features
Ideally it should send something like: env=encoded-url,feature=version,feature=version&env=encoded-url,feature=version,feature=version so that the server can send back all the features it is missing (if any) and support multiple environments.
It was unclear to a new user how the lock/unlock interaction worked as this feature is not standard in most feature systems, particularly home grown ones.
When changing the type of a feature TO a feature flag, ensure all feature flag instances are created and they are not null (this use case wasn’t checked for)
Only applicable via Admin SDK when feature type can be changed
If none of the service accounts have access to an environment, ideally they shouldn't be displayed otherwise the UI can become cluttered. Alternatively it could show it on one line and say "none have access" so you don't miss a service account and wonder where it is.
Ideally we want this to be removed into a single location so when it detects we are building for the web, it will use this code, otherwise it will use a Flutter Mobile style (such as copy to clipboard).
When a portfolio admin tries to edit their roles in environments, they should be shown them all as being ticked and should not be able to edit them. Any changes will be ignored as portfolio admins always have all access to all environments.
When you are ordering environments it causes them to immediately update. This is not consistent with the other parts of the UI where the user is allowed to save their changes, and it can also create issues with the environment record being out of date, so saving the environment order creates a conflict error due to versions.
Backend should ensure that new environments are always inserted at the beginning of the list of environments (unless the first one). This will mean that they are never out of order and the reordering code will work as expected.
Changes required.
admin-ui removal of indicator of incomplete ordering structure
backend: when environment is saved it must ensure there is a priorEnvironmentId set if one isn't already there.
backend: remove duplicate code around backend ordering support, stop with Rob's recommended API.
Prerequisites
Put an X between the brackets on this line if you have done all of the following:
The locked status needs to be exposed in the SDK API, passing back from the Edge server so that the SDK can make intelligent decisions about FeatureValueOverrides.
There is no documentation on how to recover the superuser's password if there is only one superuser. If using OAuth this isn't an issue, but otherwise info needs to be provided.
The Assistant/Rocket (known internally as the Stepper) only takes you to the location to do the action. So if you click Create Application, it takes you to the Application screen, where you need to click Create Application again.
Ideally this would take you to the screen and click the action.