[3.3] [CDB] Delete Inactive Members

[Mike-on-Tour]

Servus,
an diesen Fall hatte ich noch gar nicht gedacht, macht aber viel Sinn.
Ich werde das dann mal nacharbeiten.

Danke für den Hinweis.

[DocSommer]

Ich bin mir anhand des ACP Screenshots nicht ganz sicher und möchte daher einmal nachhaken, ob ich diese EXT auch ausschliesslich auf "Nullposter" anwenden kann und im Umkehrschluss Nutzer von einer Löschung ausnehmen kann, die einen oder mehrere Posts verfasst haben - egal wie lange das her ist?

[Mike-on-Tour]

Erstens: Diese Ext löscht nur "Schläfer" und "Nullposter"
Zweitens: Du kannst beide Mitglieder-Kategorien gesondert ein- und ausschalten.
Drittens: Diese Ext tut nach Installation/Aktivierung noch gar nichts, die Funktion muss gesondert eingeschaltet werden (Vorsichtsmaßnahme)
Viertens: Du kannst deine jeweilige Einstellungen mittels eines Buttons "Einstellungen testen" jederzeit überprüfen und siehst so eine Liste der Mitglieder, die mit den aktuellen Einstellungen gelöscht würden.

Ich hoffe, das beantwortet deine Fragen.

[DocSommer]

Danke das klingt gut - hab mich etwas von der Beschreibung der ACP Einstellung irritieren lassen, dort steht ja in der Erläuterung zu dem Schalter Anzahl der Tage bis zum aut. löschen des Mitglieds wenn es in der Zeit .... keinen Beitrag verfasst hat. Da war ich mir nicht sicher wie das gemeint gewesen ist.

[Mike-on-Tour]

Typischer Use Case: Frist ist auf 1 Woche eingestellt, dann ist Admin 2 Wochen in Urlaub und in dieser Zeit meldet sich ein neuer User an und postet einen Beitrag, der durch die NRU Funktion erst freigegeben werden muss. Nach 1 Woche greift bei DIM aber bei diesem User die Nullposter-Regel und löscht den User raus, obwohl der User ja grundsätzlich einen Post hat, wenn auch nicht sichtbar. Das war so natürlich nicht gedacht, denn in diesem speziellen Fall darf DIM nicht aktiv werden.

Das ist so natürlich vollkommen korrekt, aber ...

Ich habe das jetzt mal nachvollzogen und bin auf einen Bug (?) in phpBB gestossen, der uns da einen Strich durch die Rechnung machen kann:
Wenn dieser User einen Beitrag verfasst hat und dieser über die bei DIM eingestellte Zeitspanne hinaus nicht freigegeben, sondern z.B. wegen Spam gelöscht wird, dann bleibt trotz user_posts = 0 der Zeitpunkt des Erstellens dieses Spambeitrages nach wie vor in der Datenbank erhalten, z.B. user_lastpost_time = 1724230244.
Von der Anzahl der Beiträge (keine) würde dieser User dann eigentlich gelöscht, durch den nicht zurückgesetzten Zeitpunkt des Erstellens dieses nicht freigegebenen und gelöschten Beitrages bleibt der User dann aber trotzdem für DIM "unsichtbar".

Ich müsste jetzt also einen Bug im Tracker von phpbb.com melden und hoffen, dass der Vorschlag zügig umgesetzt wird. Muss aber erstmal schauen, wie Beiträge gelöscht werden und dann den Code so ergänzen, dass bei einer Beitragsanzahl von 0 (der noch nicht freigegebene zählt ja noch nicht) beim Löschen auch der Zeitpunkt des letzten Postens auf 0 gesetzt wird.

[LukeWCS]

Moin Mike

Ich habe das jetzt mal nachvollzogen und bin auf einen Bug (?) in phpBB gestossen, der uns da einen Strich durch die Rechnung machen kann:

Ich glaube in dem Fall nicht, dass das ein Bug ist, denn das Feld user_lastpost_time sagt ja klar aus, das hier der Timestamp des letzten Post-Vorgangs gespeichert ist. Selbst wenn das nur 1 Post war und dieser dann gelöscht wird, ändert das ja nichts an der Tatsache, dass der User zuletzt zum Zeitpunkt X gepostet hatte.

Dieser Umstand war mir zum Zeitpunkt meines Beitrags gestern Abend bereits bekannt, nachdem ich speziell das Nullposter-Problem beleuchtet hatte. Dieses Feld hatte ich auch nur erwähnt, weil man damit die Last reduzieren kann. Denn wenn das Feld auf 0 steht, brauchts die zusätzliche Abfrage der posts Tabelle nicht. Ist dieser Wert aber nicht 0, brauchts auf jeden Fall die zusätzliche Abfrage in der posts Tabelle, weil in der users Tabelle nur die Anzahl der sichtbaren Posts gespeichert wird, aber leider nicht die Anzahl der unsichtbaren. Das wäre schön gewesen, aber, ist halt nicht.

Ich bin mir anhand des ACP Screenshots nicht ganz sicher und möchte daher einmal nachhaken, ob ich diese EXT auch ausschliesslich auf "Nullposter" anwenden kann

Zusätzlich zu den Kategorien Schläfer und Nullposter gibts noch die dritte Kategorie Account-nicht-aktiviert. Diese Accounts werden nach Ablauf der Frist auf jeden Fall gelöscht. Siehe meine Liste die ich Mike gepostet hatte. Das sind die 3 Kategorien die von DIM behandelt werden.

Du kannst DIM gefahrlos installieren und einstellen, solange du den Hauptschalter deaktiviert lässt. So habe ich es z.Z. auch, um risikolos mit DIM vertraut zu werden. Und genau so bin ich ja jetzt auf das NRU-Nullposter Problem gestossen.

[DocSommer]

Jo danke Luke, ich check das auf jedem Fall mal aus, auch wenn mein Admin Kollege sich vor kurzem erst komplett "per Hand zu Fuß" die Mühe gemacht hat die rund 200 Karteileichen auszumisten.

[LukeWCS]

Wie besprochen, Rückmeldung zur 1.0.1 Beta:

Alle Vorgänge mit dem User dim_nopost. Nach jedem Vorgang wurde die Vorschau aktualisiert um die Aktion zu prüfen. Zu Beginn hatte der User 0 Posts.

1. Erster Schnelltest mit 1 nicht-freigegebenen Beitrag:
Sichtbare Posts: 0
Unsichtbare Posts: 1
In Vorschau: Nein

Dann Freigabe des Beitrags verweigert:
Sichtbare Posts: 0
Unsichtbare Posts: 0
In Vorschau: Ja

2. Zwei neue Beiträge in Warteschlange gesetzt:
Sichtbare Posts: 0
Unsichtbare Posts: 2
In Vorschau: Nein

Ersten Beitrag verweigert:
Sichtbare Posts: 0
Unsichtbare Posts: 1
In Vorschau: Nein

Zweiten Beitrag verweigert:
Sichtbare Posts: 0
Unsichtbare Posts: 0
In Vorschau: Ja

3. Einen neuen Beitrag in Warteschlange gesetzt:
Sichtbare Posts: 0
Unsichtbare Posts: 1
In Vorschau: Nein

Jetzt diesen Beitrag aber freigegeben:
Sichtbare Posts: 1
Unsichtbare Posts: 0
In Vorschau: Nein

DIM verhielt sich in allen Situationen wie es sollte. Merci Mike.

Habe mir dann auch angeschaut wie du es gelöst hast. Ich bin erstaunt, dass das durch Erweiterung des bestehenden Querys machbar war. Mein Ansatz wäre ein zusätzlicher Query gewesen und deutlich aufwendiger/umständlicher.

@DocSommer

Den gleichen "Spass" hatte Crizzo hier auch, allerdings waren das 31k.

Darum ist DIM hilfreich um zu verhindern, dass sich die lästigen Spam-Accounts überhaupt ansammeln können. Durch meine Recherchen bei der Entwicklung von Force Account Reactivation im Rahmen von Accountsicherheit - Neue Maßnahmen habe ich ein paar interessante neue Dinge im Bereich Accounts erfahren. Auch aus dem Grund will ich solche Spam Accounts schnellstmöglichst und automatisiert loswerden.

[Mike-on-Tour]

Danke für die Rückmeldung. Freut mich sehr, dass es auch bei dir funktioniert wie geplant.
Ich musste einfach eine funktionierende Ergänzung für das Query finden, sonst hätte ich Probleme mit der Paginierung bekommen.

Werde ich dann morgen veröffentlichen und auf .com zur Validierung einreichen.

[IMC]

... Ich bin erstaunt, dass das durch Erweiterung des bestehenden Querys machbar war. ...

Ich bin auch auch immer wieder davon fasziniert was man mit einer etwas komplexeren Abfrage erreichen kann. Bin ich darin aber nicht so gut, wie ich es gern sein würde.

Leider musste ich in einer meiner Erweiterungen wieder auf einfache Standardabfragen zurückgreifen, da die von mir gewählte nicht in allen von phpBB unterstützten Datenbanken eine Antwort lieferte.