Ergebnis des Senior-Reviews über dev/2026-07-22 (Konzept 22.07., Feedback 24.07.,
Plan 19.08.). Rechnerisch war nichts zu korrigieren: Payline-Punkte und Provision
des Prognose-Blocks (N4) stimmen exakt mit der Provisions-Engine überein
(54.718,5 P. bzw. 3.772,88 EUR gegengerechnet an User 454). Behoben sind
Darstellungs- und Konsistenzfehler, die der Beraterin als falsche Zahlen
aufgefallen wären:
- "+N neu" schrumpfte rückwirkend, der Bestand daneben nicht: newAboCount() nutzte
weiter activeAbo(), während aboStockCount() auf das Monatsende zurückrechnet.
Beide teilen sich jetzt aboStockQuery(); die Jahres-Wachstumstabelle ebenso.
- Level-Kachel widersprach sich ("Zum nächsten Level Diamant fehlen X" über
"Karriere-Level: Diamant"): Text auf die Monats-Qualifikation umformuliert
(de/en/es/fr), Überschrift "Qualifikation in diesem Monat", Karriere-Level nur
noch bei Abweichung.
- Firstlines-Kachel zählte alle direkten Partner, "Teampartner gesamt" daneben nur
aktive (F1): Kachel nutzt jetzt isActiveConsultant(), die Detailseite listet
weiter alle und weist beide Zahlen aus.
- Neupartnerzahlen vergangener Monate sanken auf dem Home-Dashboard, sobald
Jahresgebühren ausliefen: neue User::newPartnerReferenceDate() (laufender Monat =
heute, abgeschlossener Monat = Monatsende). Dabei die drei Inline-Kopien der
Neupartner-Regel auf scopeNewPartnerIn()/isNewPartnerIn() zusammengeführt.
- Top-3-Karte ließ den Betrachter aus, obwohl "ich gehört in die Liste" in der
Juli-Runde für alle anderen Ranglisten umgesetzt wurde: zählt jetzt mit, inkl.
is_self und "ich"-Badge.
- Neues Profilfoto zeigte bis zu 6 h ein totes Bild: die URL steckt nicht mehr im
Cache, sondern entsteht beim Lesen (withProfileImages()).
- Test-Regression seit der Juli-Runde: Unit/Services/BackofficeDashboardServiceTest
fiel über die fehlende Spalte status_points (kam mit nonPaylinePoints() dazu).
- Kleinigkeiten: ProfileImageController gab die komplette Exception als
Flash-Message aus (jetzt Log + Sprachkey), BackofficeDrilldownService formatierte
Datumsangaben hart auf d.m.Y statt über Util::formatDateDB().
Tests: neuer HomeMonthlyStatsTest (buildMonthlyStats war ungetestet) plus Tests für
Stichtags-Zählung und Foto-Cache. Fünf Tests kodierten das alte Verhalten
(Betrachter zählt nicht mit, abgelaufener Account zählt nie) und wurden auf die
neue Semantik umgestellt, jeweils mit Gegenprobe. Suite: 861 grün (vorher 855),
89 rot — ausschließlich die in docs/2026-06-11-test-suite-vorbestehende-fehler.md
dokumentierten Altlasten.
Offen und bewusst nicht enthalten:
- Deploy-Schritt: backoffice:store-statistics-snapshots --force (vorher dumpen).
Kein vorhandener Snapshot enthält recruiter_ranking, Mai/Juni zusätzlich weder
non_payline_points noch die Führungskräfte-"gesamt"-Spalten; der Cron überspringt
vorhandene Snapshots ohne --force. Achtung: die Neuberechnung ist nicht
verlustfrei.
- TreeHtmlRendererTest/TreeCalcBotIntegrationTest: die Abo-Badges machten den
Renderer datenbankabhängig; die Dateien waren schon vorher rot und gehören in die
separate Test-Aufräumaufgabe.
- deleteImage bleibt ein GET-Route (gleiches Muster wie das Shop-Bild).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
77 lines
2.6 KiB
PHP
77 lines
2.6 KiB
PHP
<?php
|
|
|
|
use App\Http\Controllers\HomeController;
|
|
use App\User;
|
|
use Carbon\Carbon;
|
|
use Illuminate\Foundation\Testing\RefreshDatabase;
|
|
use Illuminate\Support\Facades\Cache;
|
|
use Tests\TestCase;
|
|
|
|
uses(TestCase::class, RefreshDatabase::class);
|
|
|
|
beforeEach(function () {
|
|
Carbon::setTestNow(Carbon::parse('2026-08-15'));
|
|
Cache::flush();
|
|
});
|
|
|
|
afterEach(function () {
|
|
Carbon::setTestNow();
|
|
});
|
|
|
|
function hmsMakeUser(?int $sponsorId = null, ?string $paymentAccount = 'future'): User
|
|
{
|
|
return User::forceCreate([
|
|
'email' => 'hms-'.uniqid('', true).'@example.com',
|
|
'password' => bcrypt('secret'),
|
|
'lang' => 'de',
|
|
'm_level' => 1,
|
|
'm_sponsor' => $sponsorId,
|
|
'active_date' => '2026-01-10',
|
|
'payment_account' => $paymentAccount === 'future' ? now()->addYear() : $paymentAccount,
|
|
]);
|
|
}
|
|
|
|
function hmsMonthlyStats(User $user): array
|
|
{
|
|
Request::merge(['stats_month' => 8, 'stats_year' => 2026]);
|
|
|
|
$method = (new ReflectionClass(HomeController::class))->getMethod('buildMonthlyStats');
|
|
$method->setAccessible(true);
|
|
|
|
return $method->invoke(new HomeController, $user);
|
|
}
|
|
|
|
it('zaehlt in der Firstlines-Kachel nur aktive Berater, konsistent zu "Teampartner gesamt"', function (): void {
|
|
$root = hmsMakeUser();
|
|
hmsMakeUser($root->id);
|
|
hmsMakeUser($root->id);
|
|
// Abgelaufenes, aber gesetztes Abrechnungskonto: zaehlt wie in der
|
|
// "Berater"-Spalte weiterhin als Berater (BackofficeDashboardService::isActiveConsultant).
|
|
hmsMakeUser($root->id, now()->subMonth()->toDateString());
|
|
// Gar kein Abrechnungskonto: kein Berater
|
|
hmsMakeUser($root->id, null);
|
|
|
|
$stats = hmsMonthlyStats($root);
|
|
|
|
// Beide Kacheln stehen im selben Cluster und muessen dieselbe Basis nutzen.
|
|
expect($stats['firstline_count'])->toBe(3)
|
|
->and($stats['team_partner_count'])->toBe(3);
|
|
});
|
|
|
|
it('zaehlt Neupartner weiterhin ueber alle Firstlines, nicht nur ueber die Kachel-Menge', function (): void {
|
|
$root = hmsMakeUser();
|
|
|
|
// Im laufenden Monat aktiv geworden, Konto gueltig -> Neupartner
|
|
hmsMakeUser($root->id)->forceFill(['active_date' => '2026-08-05'])->save();
|
|
// Im laufenden Monat aktiv geworden, Konto abgelaufen -> kein Neupartner,
|
|
// aber weiterhin Berater in der Firstlines-Kachel
|
|
hmsMakeUser($root->id, now()->subDay()->toDateString())
|
|
->forceFill(['active_date' => '2026-08-06'])->save();
|
|
// Ohne Abrechnungskonto: weder Neupartner noch Berater
|
|
hmsMakeUser($root->id, null)->forceFill(['active_date' => '2026-08-07'])->save();
|
|
|
|
$stats = hmsMonthlyStats($root);
|
|
|
|
expect($stats['direct_new_partners'])->toBe(1)
|
|
->and($stats['firstline_count'])->toBe(2);
|
|
});
|