[NFC] Update testGetSiteStats to match earlier name change

[demeritcowboy]

Overview

Similar to https://lab.civicrm.org/dev/core/-/issues/3057#note_69324, if the expected entity name has changed this test will fail in betas and releases, but not in alpha versions.

Before

test fail

After

test not fail

Technical Details

Entity short name was changed recently in e45a8e7

Comments

[civibot]

(Standard links)

• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[seamuslee001]

This seems fine to me

[totten]

Do I understand correctly that this sort of locks-in the rename as part of the wire-protocol and kicks the problem over to backend? So reports like this would need to be revised as well:

https://lab.civicrm.org/infra/stats-collection/-/blob/4a7b8616c044b76f211e3b812d05fec89d397fea/bin/pingback/getdata.php#L30

I would guess:

-   LEFT JOIN " . DBPING . ".entities e5 ON e5.stat_id = s.id AND e5.name = 'Delivered'
+   LEFT JOIN " . DBPING . ".entities e5 ON e5.stat_id = s.id AND e5.name IN ('Delivered', 'MailingEventDelivered')

Not sure who the best person is to look at the repo - maybe @bgm knows who?

[demeritcowboy]

I saw your comment in chat but was more interested in fixing the issue and I don't know who even has access to these stats. And to be honest if they aren't public it enters into contentious territory.

[totten]

Yeah, I suppose you sometimes see news stories where stats-reporting becomes contentious if it's forced on folks -- but in Civi, this report is optional. Moreover, as I understand, the key things are public (github.com / lab.c.o / stats.c.o). If there is some general issue with arrangement, then it should probably go on lab.c.o.

AFAICS, the test here isn't about that. It merely says, "When stat reports are generated, they should behave consistently/predictably."