Integration tests for visitor id vs user id scenarios

[michalkleiner]

Description:

Please include a description of this change and which issue it fixes. If no issue exists yet please include context and what problem it solves.

Review

• Functional review done
• Potential edge cases thought about (behavior of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• Documentation added if needed
• Existing documentation updated if needed

[sgiehl]

I had a look through the test cases. In general I think they should reflect the described cases, but we need to improve the checks at some point, so we also test that the actions are assigned to the correct visit.

What is currently completely untested is using the config enable_userid_overwrites_visitorid = 0, which we should also test, so we can later document the exact behavior of it.

And the biggest part we might also need to (maybe manually) test is, if the javascript tracker behaves the same.
I think there are a some edge cases, that are currently not really tested. But I also don't exactly know how the javascript tracker would behave in combination with a user id if e.g.:

• cookies are fully disabled or cookie consent is given after some actions
• browser feature detection is disabled (or activated after some actions)

[sgiehl]

With my latest changes PHP and UI tests now should behave identical in terms of expected results. So for an initial test set this should be good to merge.
What we at some point could also consider to test are additional UI tests in combination with things like requireConsent, requireCookieConsent and similar.

In terms of "unexpected" behavior there are these cases we might later need to have a closer look at:

matomo/tests/PHPUnit/Integration/Tracker/UserIdVisitorIdTest.php

Lines 367 to 399 in c963f5c

	public function testUserLoggedInOnMultipleDevicesWithoutActions(bool $userIdOverwritesVisitorId)
	{
	$this->configureUserIdOverwritesVisitorId($userIdOverwritesVisitorId);
	$trackerDevice1 = $this->getTracker();
	$this->trackPageview($trackerDevice1, 'page-1');
	$this->trackPageview($trackerDevice1, 'page-2');
	$this->logInUser($trackerDevice1);
	$this->trackPageview($trackerDevice1, 'page-3');
	$this->assertCounts([3], 1);
	$trackerDevice2 = $this->getTrackerForAlternateDevice();
	$this->trackPageview($trackerDevice2, 'page-4');
	$this->trackPageview($trackerDevice2, 'page-5');
	$this->logInUser($trackerDevice2);
	$this->trackPageview($trackerDevice2, 'page-6');
	if ($userIdOverwritesVisitorId) {
	// TODO: It may be unexpected that the last action of the second visit(or) is actually attributed to the first
	// visit(or). This is caused by the way how existing visits are looked up.
	// After the login a userid is provided. Therefor Matomo tracker looks for an existing visit by prioritizing the
	// userid (=visitorid). As a visit is found it will be resumed - instead of updating the actually running one
	$this->assertCounts([4, 2], 2);
	} else {
	$this->assertCounts([3, 3], 2);
	}
	$this->assertVisitorIdsCount(2);
	// multiple devices, multiple config IDs
	$this->assertConfigIdsCount(2);
	}

matomo/tests/PHPUnit/Integration/Tracker/UserIdVisitorIdTest.php

Lines 480 to 528 in c963f5c

	public function testNewVisitWithLoginAndLogoutCombination(bool $userIdOverwritesVisitorId)
	{
	$this->configureUserIdOverwritesVisitorId($userIdOverwritesVisitorId);
	// track a first visit (without login)
	$tracker = $this->getTracker();
	$this->trackPageview($tracker, 'page-1');
	$this->trackPageview($tracker, 'page-2');
	$this->assertCounts([2], 1);
	// force a new visit of the same visitor (with login and logout)
	$tracker->setForceNewVisit();
	$this->trackPageview($tracker, 'page-1');
	$this->assertCounts([2, 1], 1);
	$visitorId1 = $this->getVisitProperty('idvisitor', 2);
	$this->logInUser($tracker);
	$this->trackPageview($tracker, 'page-3');
	$visitorId2 = $this->getVisitProperty('idvisitor', 2);
	if ($userIdOverwritesVisitorId) {
	$this->assertNotEquals($visitorId1, $visitorId2);
	// logging in causes the visitor id to change, therefore we afterwards have 2 different
	$this->assertCounts([2, 2], 2);
	} else {
	$this->assertEquals($visitorId1, $visitorId2);
	// forcing a visit so we have two visits with 2 actions each
	$this->assertCounts([2, 2], 1);
	}
	$this->logOutUser($tracker);
	$this->trackPageview($tracker, 'page-5');
	if ($userIdOverwritesVisitorId) {
	// TODO: It may be unexpected that the last action of the second visit is actually attributed to the first
	// visit. This is caused by the way how existing visits are looked up.
	// After the login a userid is provided. Therefor Matomo tracker updates the visitorid of the second visit,
	// while the visitorid of the first visit remains. As the php tracker still has the original visitorid set,
	// after logout this visitorid will be used again to look for an existing visit.
	// This causes the last action to be attributed to the first visit.
	$this->assertCounts([3, 2], 2);
	} else {
	$this->assertCounts([2, 3], 1);
	}
	}