Closed asoorm closed 2 years ago
I think anything that is optional and impacts performance should stay optional.
This is quite contentious. I personally agree with you @gernest hence the reason that the way it was implemented was by default to turn everything off, and explicitly enable capabilities. This is also a UX focus to explicitly turn things on, rather than having things on by default.
The problem is that this decision is causing confusion with customers because of the design of the apidefinition in the Gateway.
If we decide that it should stay as-is, maybe we should alternatively provide clear documentation on how to turn on analytics for the API?
Alternatively, maybe we could/should open a ticket in the Gateway repo to fix the actual API and deprecate do_not_track
. e.g. rather than do_not_track
, the field could be called enable_analytics: bool
. Then it is up to the GUI to turn it on by default if it wants to.
Customers are complaining because they had to explicitly enable analytics in the API Definition.
This is different from Default Tyk Dashboard - where analytics are enabled by default.
Remove this part of the defaulting webhook to automatically enable analytics again.
https://github.com/TykTechnologies/tyk-operator/blob/master/api/v1alpha1/apidefinition_webhook.go#L50-L53
NB - this will cause a performance penalty, and customers will explicitly need to turn analytics OFF, rather than ON.