Update tracker script idempotency

[aerosol]

Normally when a site is created, it provisions goals for extra measurements (e.g. 404).

Those goals are also provisioned when WordPress is requesting tracker script update, but only if the server-kept state is false and transitions to true as per WP's request. However, when goals are deleted manually in the meantime, no script configuration is ever updated, so the remembered state is "true" and transition that occurs is "true->true", in which case no goals are re-created.

I propose to always attempt to re-create goals in case the requested state is "true" - unless that violates some original design.

cc @apata @RobertJoonas @ukutaht

[apata]

@aerosol, I believe there's some risk with frustrating users when deploying this. This does not distinguish between intentional delete or rename of one of the "system" (more accurately, "system-created") goals and an accidental delete (one that the user wants to revert on every "Review installation" check).

This change would make the goal appear unexpectedly after a "Review installation" flow for those that managed it intentionally with Settings > Goals UI. I think we should work on a solution that handles these system goals better, e.g. maybe have a separate section in Settings > Goals list where they can be toggled on-off (which actually updates tracker script config, rather than deletes the goal directly).

[aerosol]

I think I get what you're saying. It's either way a trade-off in terms of syncing the state. Deleting a goal as mean of toggling its visibility (yet still having the script configured to track special measurements) is probably a not so common use case? Not sure if it's even documented.

And we can assume that if the extra measurement checkbox is checked, your intention is to actually use that auto-created goal, even more so when reviewing the installation.

@ukutaht what are your thoughts?

[aerosol]

And with regards to renames, we're thinking of disallowing them for special goals as per https://3.basecamp.com/5308029/buckets/36789884/card_tables/cards/9834018285

[ukutaht]

@ukutaht what are your thoughts?

Either way it's not perfect and it's hard to know which behaviour creates more/less frustration.

Currently there are ~200 goals in database where event_name is a 'special goal' but the display name has been changed. For these customers this is a risk of creating a duplicate when they review their installation or touch wordpress installation. It's good at least that we're not allowing these to be changed anymore.

On the other side, did this request come from a WP customer who was confused?

[aerosol]

@ukutaht the request came from Daan