Web: define discover resource guide ids and add discover user preference field#51672
Web: define discover resource guide ids and add discover user preference field#51672
Conversation
There was a problem hiding this comment.
Alternative is to define these as proto enums. This takes more lines of code, but advantage is probably that it's harder to modify it? And stricter typing (like you can't just store any strings, it has to be a type of enum).
I opted to go for the simpler approach and see what kind of review I get.
There was a problem hiding this comment.
i think enums client side like you have it is fine.
There was a problem hiding this comment.
Yeah looks good since there isn't extra processing done by the backend on these id values and are meant just for the UI. The downside are that we must make sure that the id names (mostly words, spells etc) are correct the first time we merge to master as changing them later risks backend data and id values going out of sync. That wont be case if we define this in backend first and then copy 1:1 to frontend.
There was a problem hiding this comment.
i think enums client side like you have it is fine.
| DatabaseAwsSqlServerAd = 'database-aws-sql-server-ad', | ||
| DatabaseAwsPostgresRedshift = 'database-aws-postgres-redshift', | ||
| DatabaseAwsRdsPostgresSql = 'database-aws-rds-postgres-sql', | ||
| DatabaseAwsRdsProxyPostgres = 'database-aws-rds-proxy-postgres', |
There was a problem hiding this comment.
i dont really know what the protocol is here if we should call it postgres or postgresql or whatever. i think weve been pretty inconsistent in the rest of the code base. feel free to skip if you want (but when using the full name, lets keep it one word postgresql)
There was a problem hiding this comment.
just realized i've been misspelling it (the extra s in postgressql), i decided to replace all postgressql with its shortened version postgres
| DatabaseAzureSqlServerAd = 'database-azure-sql-server-ad', | ||
|
|
||
| DatabaseGcpMysqlCloudSql = 'database-gcp-mysql-cloud-sql', | ||
| DatabaseGcpPostgresCloudSql = 'database-gcp-postgres-cloud-sql', |
There was a problem hiding this comment.
| DatabaseGcpPostgresCloudSql = 'database-gcp-postgres-cloud-sql', | |
| DatabaseGcpPostgresCloudSql = 'database-gcp-postgres-cloud-sql', |
PostgresqlCloud?
There was a problem hiding this comment.
keeping it as is, it's actually how its named here: https://goteleport.com/docs/enroll-resources/database-access/enroll-google-cloud-databases/postgres-cloudsql/
| message DiscoverGuidePreferences { | ||
| // pinned_guides is a list of ids of pinned guides. | ||
| repeated string pinned_guides = 1; | ||
| } | ||
|
|
||
| // DiscoverResourcePreferences holds preferences related to discovering resource. | ||
| message DiscoverResourcePreferences { | ||
| DiscoverGuidePreferences discover_guide_preferences = 1; | ||
| } |
There was a problem hiding this comment.
Curious, do we have plans to add more configuration to the guide preference?
Otherwise putting pinned guide directly in the discover resource preference seem like a better type to me.
message DiscoverResourcePreferences {
// pinned_guides is a list of ids of pinned guides.
repeated string pinned_guides = 1;
}
There was a problem hiding this comment.
Glad you pointed it out b/c i wanted to double check.
Curious, do we have plans to add more configuration to the guide preference?
probably not, i was partly following the existing pattern for pinning here and mostly because i needed a way to tell from init value vs user intentionally setting it empty
- i use the
nilvalue to render default pinned items - pinned results will only be saved if a user ever updates any pinned items
- a user can also unpin everything leading to a empty list
you could also say DiscoverResourcePreferences can also be nil? but we could add more settings later that may not affect the pinned results
let me know what you think
There was a problem hiding this comment.
i needed a way to tell from init value vs user intentionally setting it empty
Why do we want to check this?
Unless we know we need it 100% later on, I say lets settle for simple one like this. Any more settings you want to add can be added directly or wrapped in another message when necessary.
There was a problem hiding this comment.
Why do we want to check this?
we want to display default pinned guides like this (default == nil preference):
if a user wanted to just unpin all of them (empty list), i needed a way to tell if they did that, otherwise the default pins will always render which is unexpected behavior.
or, are you saying just always render default if empty list?
There was a problem hiding this comment.
actually, i think i can do something like this
DiscoverPreference {
repeated string pinned_guides `...yada yada, omitempty`
}
if i remember correctly, the omitempty allows for js to distinguish between value undefined and a empty length array. i'll test it
There was a problem hiding this comment.
Yeah my thinking was to show out set of predefined defaults if the pinned_guides choice is empty. Any issue with that?
| option go_package = "github.com/gravitational/teleport/api/gen/proto/go/userpreferences/v1;userpreferencesv1"; | ||
|
|
||
| // DiscoverGuidePreferences holds preferences related to discover resource guides. | ||
| message DiscoverGuidePreferences { |
There was a problem hiding this comment.
nit: not sure if it will be confusing in practice but just looking at it, I think we can leave out Preferences suffix as this will ultimately be used as userpreferencesv1.DiscoverGuide. userpreferencesv1.DiscoverGuidePreferences reads redundant.
| message DiscoverGuidePreferences { | |
| message DiscoverGuide { |
(same comment below)
There was a problem hiding this comment.
keeping it as is, since it's the established pattern 😅
| PinnedGuides []string `json:"pinnedGuides"` | ||
| } | ||
|
|
||
| type DiscoverResourcePreferencesResponse struct { |
| ClusterPreferences ClusterUserPreferencesResponse `json:"clusterPreferences,omitempty"` | ||
| DiscoverResourcePreferences DiscoverResourcePreferencesResponse `json:"discoverResourcePreferences"` | ||
| AccessGraph AccessGraphPreferencesResponse `json:"accessGraph,omitempty"` |
There was a problem hiding this comment.
should DiscoverResourcePreferences also define omitempty or we are ok sending empty fields?
There was a problem hiding this comment.
recording slack discussion: DiscoverResourcePreferences should always be initialized since i am using the undefined value as a way to determine if response came from an older proxy
| // accessGraphPreferencesResponse creates a JSON response for the access graph preferences. | ||
| func discoverResourcePreferenceResponse(resp *userpreferencesv1.DiscoverResourcePreferences) DiscoverResourcePreferencesResponse { |
|
|
||
| // accessGraphPreferencesResponse creates a JSON response for the access graph preferences. | ||
| func discoverResourcePreferenceResponse(resp *userpreferencesv1.DiscoverResourcePreferences) DiscoverResourcePreferencesResponse { | ||
| if resp == nil || resp.DiscoverGuidePreferences == nil { |
There was a problem hiding this comment.
nit: use GetX where possible as it adds safety from nil pointer
| if resp == nil || resp.DiscoverGuidePreferences == nil { | |
| if resp == nil || resp.GetDiscoverGuidePreferences == nil { |
| r.id === DiscoverGuideId.ApplicationSamlGeneric || | ||
| r.id === DiscoverGuideId.ApplicationSamlGrafana | ||
| ) { | ||
| return 'Teleport as IDP'; |
There was a problem hiding this comment.
where does this name show up?
| * An empty array or undefined means that the resource supports all auth types. | ||
| */ | ||
| supportedAuthTypes?: AuthType[]; | ||
| id: DiscoverGuideId; |
There was a problem hiding this comment.
curious, is is deliberate that this new field added as last item but another new field pinned?: boolean; added as first item?
There was a problem hiding this comment.
not deliberate 😅 , i updated to put both fields at top since it's more fitting
| * | ||
| * Existing enum values must not be modified. | ||
| */ | ||
| export enum DiscoverGuideId { |
There was a problem hiding this comment.
nit: In favor of shorter names (since this will be used to pin the resource internally and not exposed to users right?
Applicationcan beAppApplicationSamlcan beSamlDatabasecan be `Db
Applied to both key and values.
Feel free to ignore if you think we gain by spelling out loud.
7ae8dae to
26da534
Compare
c4435e2 to
6b1c121
Compare
…nce field (#51672) * Add discover resource preferences to user preferences * Define hard coded guide id consts * Set guide ids for resources * Add test * Address CRs * Define a new type just for SelectResource.tsx which requires id field
…nce field (gravitational#51672) * Add discover resource preferences to user preferences * Define hard coded guide id consts * Set guide ids for resources * Add test * Address CRs * Define a new type just for SelectResource.tsx which requires id field
…52176) * Web: make SelectResource.tsx component leaner (#51698) * Web: Move resource specs into resource directory * Web: move code out into separate files * Web: define discover resource guide ids and add discover user preference field (#51672) * Add discover resource preferences to user preferences * Define hard coded guide id consts * Set guide ids for resources * Add test * Address CRs * Define a new type just for SelectResource.tsx which requires id field * Wrap discover guide preference "pinned" field inside a proto message (#52017) This allows us to use "nil" value to mean no discover guide preferences set (which is used to set default values in the web UI). * Web: Add filters and pinning support for Enroll Resources page (#51893) * Minor changes - Stop propagation and default behavior when clicking on pin button - Add small or large icon option for discover icons * Add pinning guide support * Fix lint

Part of improving the enroll resources page in the web UI, which is to allow user to
pinfavored resource guides. This PR just defines the user preference fields, the UI work to allow user to pin will be in another PR.