-
Notifications
You must be signed in to change notification settings - Fork 343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Profile Parameter Page Should List Profile(s) #1363
Comments
just adding some notes here this is referring to the /parameters and /parameters/:id page in the Traffic Portal this would require a change to /api/parameters and /api/parameters/:id endpoints, specifically adding a key called "profiles" or something that is an array of profile hashes (id, name). @dangogh is rewriting these apis in Golang so maybe he can look at that. once that information is appended to each parameter, it can be displayed in the UI |
@elsloo - imo this would muddy up the UI. If you are trying to see all the parameters associated with a given profile, you could always go to https://localhost:8443/#!/profiles then click on the desired profile and then view the associated parameters. Does this not satisfy your use case? You are trying to see all the parameters associated with a given profile, right? If we add a "profile" column to the parameters table at https://localhost:8443/#!/parameters you'll end up duplicating rows like you said (as parameters belong to multiple profiles). I'm not fond of that idea. I'd be more inclined to add a comma-seperated profile list like you mentioned but, again, muddies up the UI a bit because of a column potentially packed with data. |
nm @elsloo, i read this wrong. i missed this piece: "it should be easy to quickly see what profiles a parameter is mapped to" |
I added a profile count to each parameter that when hovered over it will show you a list of profiles for the parameter. this profile list can also be used to filter parameters for a given profile. |
The profile parameter page should list profiles associated with each parameter. The existing (legacy) UI does this by simply adding a profile column, and if the parameter is mapped to multiple profiles, multiple rows will exist for each mapping. We could take this approach, or possibly change it to a comma separated list of profiles to reduce duplication. No matter what approach we take, it should be easy to quickly see what profiles a parameter is mapped to, and that should also hold true when using the search box to find a specific parameter.
The text was updated successfully, but these errors were encountered: