Registrierung Aktivierungzeit (WCF 2.1)

  • Für das WCF1.1 hatte ich ein Plugin installiert, welches nicht aktivierte Benutzer nach einer einstellbaren Zeit (in Tagen) automatisch löschte. Damit wurden Benutzeraccounts gelöscht von Benutzern die nach z.B. 30 Tagen ihren Account nicht aktiviert haben. Zur Zeit (WCF2.1) löscht das Administrationsteam von uns alle 30 Tage diese Accounts von Hand. Leider nehmen diese nicht abgeschlossenen Registrierungen zu (von ca. 4 pro Monat auf nun mehr ca. 20). Auch wenn diese Account bekanntlich kein "Brot fressen", sind sie uns unangenehm da sie unsere Statistiken verfälschen.


    Beschreibung der gewünschten Funktion:
    Eine Löschung von nicht aktivierten Benutzeraccounts sollten via ACP in einstellbaren Tagen automatisch erfolgen.


    Würde mich freuen wenn es Anklang finden würde.

  • Naja, irgendwer hatte etwas derartiges bei mir mal angefragt und schwer umzusetzen isses ja wirklich nicht.


    Ist übrigens auch Bestandteil meiner nächsten Erweiterung.

  • Hab die Datei mal ausgetaucht nachdem ich gemerkt habe, dass ich mal wieder die cronjob file nicht bearbeitet hatte. :disappointed_relieved:

  • Entschuldige, aber ich erhalte eine Fehlermeldung, wenn ich den Cronjob manuell auslöse:

  • Wenn jemand sicherheitshalber drüber schauen möchte bitte, nicht, dass ich etwas nicht bedacht habe und anschließend zu viele Nutzer raus fliegen.

    Aktivierte Benutzer haben einen activationCode = 0. Wenn ich das richtig verstehe, löscht also der Cronjob alle aktivierten Benutzer, deren Registrierung mindestens UNACTIVATED_USERS_REMOVE_AFTER Tage her ist. Macht das Forum auf Dauer ziemlich leer ;-)
    Nicht aktivierte Benutzer haben einen Code > 0 unabhängig davon, ob frisch registriert oder später durch Admin deaktiviert. Eine (spätere) Deaktivierung durch Admin führt bei der Bedingung > 0 also mit dem Cronjob auch zur Löschung des Benutzers. Auch nicht gut.


    Letztlich genügen die WCF-Daten nicht für den Zweck. Ich habe z.B. für meinen Bot eine zusätzliches Bedingung/Tabellenspalte eingeführt, um zumindest ein versehentliches Löschen (durch den Bot) zu verhindern, wenn Admin 'nur' deaktiviert hat.


    Die Bedingung IS NULL ist m.E. überflüssig, weil der activationCode nicht NULL sein darf.

    Gruß, UdoZ

    Einmal editiert, zuletzt von UdoZ ()

  • Das kann immer noch zu ungewollten Löschungen führen. activityPoints = 0 und ggf. lastActivityTime < registrationDate + eine Stunde oder so verhindern als zusätzliche Bedingungen dann das Schlimmste. Damit können aber nach Registrierung nicht aktivierte Benutzer übersehen werden.


    Wenn es zuverlässig sein soll, müsste für jeden Benutzer getrackt werden, ob er schon mal aktiviert war. Aber eigentlich sollte das WCF die Möglichkeit bieten, solche Registrierungen ohne anschließende Aktivierung zuverlässig zu erkennen...

    Gruß, UdoZ

  • Upsi. Deswegen sollte jemand drüber schauen.

    Überhaupt kein Problem für mich. Fehler passieren und sind völlig Normal. Ich hatte meine Erwartungen gar nicht hoch geschraubt somit ist alles Gut.

  • Wenn es zuverlässig sein soll, müsste für jeden Benutzer getrackt werden, ob er schon mal aktiviert war.

    Das geht rückwirkend aber schlecht. ;)



    Das kann immer noch zu ungewollten Löschungen führen.

    Das ist relativ unwahrscheinlich. Bzw. mit fällt kein Fall ein, in dem der activationCode != 0 ist. Bei einer Adressänderung wird reactivationCode genutzt.

  • Das geht rückwirkend aber schlecht.

    Muss auch nicht, weil ja zunächst nur verhindert werden soll, dass die falschen Benutzer gelöscht werden.
    Mit activityPoints und lastActivityTime kann man aber recht gut feststellen, ob und wann ein Benutzer nach der Registrierung aktiv war, und kann man das durchaus rückwirkend 'entscheiden'.

    Das ist relativ unwahrscheinlich. Bzw. mit fällt kein Fall ein, in dem der activationCode != 0 ist. Bei einer Adressänderung wird reactivationCode genutzt.

    Wenn ein Benutzer im ACP oder durch ein Plugin deaktiviert wird, wird u.a. der activationCode auf UserRegistrationUtil::getActivationCode(), also auf !=0 gesetzt - und bald danach von Deinem Plugin gelöscht.
    Aber eigentlich ist es doch egal, wie wahrscheinlich oder unwahrscheinlich es ist. Solange die Möglichkeit besteht, dass der Code nach 1. Aktivierung wieder !=0 wird, was unstrittig der Fall ist, würde ich das nicht als einziges Kriterium für eine Löschung nutzen.

    Gruß, UdoZ

  • Wie stellt WoltLab es denn im ACP fest ob ein Benutzeraccount aktiviert wurde oder nicht? Vielleicht sollte man dort ansetzen bzw. sich diesen Prozess ansehen. Das ist ja der Moment an dem der Benutzer das Registrierungsformular ausgefüllt und abgesendet hat und eine Mail an den Benutzer gesendet wird. So lange der Benutzer die E-Mail nicht gelesen hat und die Freischaltung nicht vorgenommen hat gilt dieser als nicht aktiviert. (Wollte hiermit nur etwas dazu beitragen.) ;)

  • Wie stellt WoltLab es denn im ACP fest ob ein Benutzeraccount aktiviert wurde oder nicht?

    Die Frage geht nach meiner Bewertung am Problem vorbei. Das WCF kann nicht feststellen, bzw. stellt keine Funktion zur Prüfung zur Verfügung, ob ein Benutzer noch von der Registrierung deaktiviert ist oder irgendwann später nach erfolgreicher Aktivierung deaktiviert wurde. Die Datenbankeinträge zu registrationCode in wcf1_user sind in beiden Fällen identisch. Auch die Gruppenzuordnung ist in beiden Fällen identisch (deaktiviert = nicht in registrierte Benutzer, aber in Gäste). Und auch das WCF müsste nach anderen Daten schauen und daraus Schlüsse zum Status des Benutzers ziehen.
    Der einzige und 100 % zuverlässige Ansatz ist das Protokollieren des Aktivierungsstatus. Die Betrachtung von activityPoints und lastActivityTime ist nicht ganz so zuverlässig, aber trifft bei geeigneter Wahl der Zeit in der Regel die Richtigen. Worst case rutscht mal einer durch, der eigentlich gelöscht gehört. In der Kombination könnte man das Löschen dann auch rückwirkend erledigen.


    Und so wird aus einer auf den ersten Blick trivialen Sache eine Großbaustelle ;-)

    Gruß, UdoZ

  • Und so wird aus einer auf den ersten Blick trivialen Sache eine Großbaustelle


    Jein. Mein Plan war es ursprünglich nicht, rückwirkend zu arbeiten, sondern ab dem Zeitpunkt der Paket-Installation. Zu entscheiden, wer vor der Installation der Erweiterung die Kriterien zur Löschung erfüllt oder nicht, sehe ich nicht als meine Aufgabe. Natürlich kann man sich dazu etwas überlegen, aber wenn die Gefahr zu groß ist, dass hier automatisch Fehlentscheidungen aufgrund von schwammigen Informationen getroffen werden, lässt man es besser :)


    Andererseits spricht m.M. nach nichts dagegen, betreffende User erst per Mail darüber in Kenntnis zu setzen, dass ihr Account in naher Zukunft gelöscht wird, sollte er nicht binnen einer festgelegten Zeit aktiviert werden.


    Diese Lösung kann zwar dazu führen, dass auch Nutzer angeschrieben werden, die die Kriterien zur Löschung "eigentlich" nicht erfüllen, aber es wird eben niemand sofort und ohne Vorwarnung gelöscht, was die o.g. Probleme zumindest um ein Vielfaches relativiert.

  • Ein kleines Plugin, das sich auf diese Sache beschränkt, dürfte recht viel Anklang finden. Der Bot ist einigen sicherlich zu mächtig, und ein Konfigurationsmonster ist er sowieso.

    Gruß, UdoZ