Context
Since the 3.0 cleanup in kumahq/kuma, every policy is targetRef based and the from-style targetRef is gone. The policy object returned by GET /_resources reflects that:
policy.hasFromTargetRef and policy.isFromAsRules were hardcoded to false and are now removed from the response (kumahq/kuma PR linked below).policy.isTargetRef is now true for every policy. It is kept on the wire for now only because the GUI still reads it, and will be removed in a follow-up once the GUI no longer depends on it.policy.hasToTargetRef and policy.hasRulesTargetRef are the real signals for "applies to outbound" and "applies to inbound".
What the GUI does today
packages/kuma-gui/src/app/resources/views/ResourceListView.vue shows the Inbound badge from type.policy?.hasFromTargetRef. That badge has never rendered against a 3.0 control plane because the value was always false.ResourceListView.vue and packages/kuma-gui/src/app/data-planes/views/DataPlanePolicySummaryView.vue read policy.isTargetRef to decide whether to show the zone column / search key and whether to render a policy as legacy. Once the field is removed from the response, undefined is falsy and every policy would be treated as legacy.packages/kuma-http-api/mocks/src/_resources.ts and mocks/src/policies.ts still generate the removed fields.
Requested changes
- Show the Inbound badge from
policy.hasRulesTargetRef instead of policy.hasFromTargetRef.
- Stop reading
policy.isTargetRef. Every policy is targetRef based, so the legacy rendering path and the isTargetRef conditions on the zone column and search keys can go.
- Drop
hasFromTargetRef, isFromAsRules and isTargetRef from the _resources and policies mocks.
After this lands and the GUI is bumped in kuma, policy.isTargetRef will be removed from the control plane response as well.
References
Context
Since the 3.0 cleanup in
kumahq/kuma, every policy is targetRef based and thefrom-style targetRef is gone. Thepolicyobject returned byGET /_resourcesreflects that:policy.hasFromTargetRefandpolicy.isFromAsRuleswere hardcoded tofalseand are now removed from the response (kumahq/kuma PR linked below).policy.isTargetRefis nowtruefor every policy. It is kept on the wire for now only because the GUI still reads it, and will be removed in a follow-up once the GUI no longer depends on it.policy.hasToTargetRefandpolicy.hasRulesTargetRefare the real signals for "applies to outbound" and "applies to inbound".What the GUI does today
packages/kuma-gui/src/app/resources/views/ResourceListView.vueshows the Inbound badge fromtype.policy?.hasFromTargetRef. That badge has never rendered against a 3.0 control plane because the value was alwaysfalse.ResourceListView.vueandpackages/kuma-gui/src/app/data-planes/views/DataPlanePolicySummaryView.vuereadpolicy.isTargetRefto decide whether to show the zone column / search key and whether to render a policy aslegacy. Once the field is removed from the response,undefinedis falsy and every policy would be treated as legacy.packages/kuma-http-api/mocks/src/_resources.tsandmocks/src/policies.tsstill generate the removed fields.Requested changes
policy.hasRulesTargetRefinstead ofpolicy.hasFromTargetRef.policy.isTargetRef. Every policy is targetRef based, so thelegacyrendering path and theisTargetRefconditions on the zone column and search keys can go.hasFromTargetRef,isFromAsRulesandisTargetReffrom the_resourcesandpoliciesmocks.After this lands and the GUI is bumped in kuma,
policy.isTargetRefwill be removed from the control plane response as well.References