user_delete

Wurde am 30. November repariert. Der Benutzer wird jetzt auf die Startseite geleitet.

--

Ja, so heisst es. Von diesem Patch rede ich oben. Der funktioniert bei Dir?!

EDIT: user_cancellation funktioniert, wobei mir noch nicht 100%ig klar ist, wie dieses Modul es im Gegensatz zu user_delete es schafft, einerseits den Drupal-Confirmation-Dialog zu verwenden und ihn andererseits so umzubiegen, dass das Löschen des Benutzers in der der moduleigenen delete_user()-Funktion mündet (also ohne Fehlermeldung).

Hat jmd. eine Erklärung dafür parat? - ich würde das wirklich gern verstehen. Wie auch immer: user_cancellation würde ich als tatsächlich verwendbares Modul bezeichnen und daher denjenigen empfehlen, die auf Ihrer Site das Feature anbieten wollen, dass User ihren eigenen Account löschen dürfen. User_delete kann ich nach meinen Erfahrungen nicht empfehlen.

Man kann Formularen zusätzliche Submit-Handler spendieren. Am Beispiel des Moduls user_delete:

Drupal ruft alle Submit-Handler nacheinander auf, sammelt die Rückgabewerte eine und leitet auf die Seite weiter, die im letzten Rückgabewert angegeben wurde.

Obige Version leitet auf die Startseite weiter, natürlich könnte auch auf anderes Seiten weitergeleitet werden.

user_cancellation gefällt mir nicht. Funktioniert zwar, ist konfigurierbar, aber der Quelltext wirkt irgendwie komisch. Zu viel arg(1), drupal_goto() in hook_menu(); wirkt nicht wirklich rund.

--

Danke für die Erklärung (muss ich noch nachvollziehen); wäre das nun die Rettung für user_delete? Weder user_delete noch user_cancellation benutzen den Hint.

Hm, mag sein. drupal_goto() in hook_menu() fand ich auch überraschend. Der Autor schien unbedingt "myaccount/13/delete" gegenüber dem erwarteten "user/13/delete" in der URL haben zu wollen. Ich vermutete, dass er damit eben die Admin-Funktionen des User-Moduls umschiffen wollte.

"Funktioniert nur mit Ach und Krach, ist nicht konfigurierbar, aber Quelltext ist sympathisch" ist nicht recht eine praktikable Alternative.

Ja.

Es steht auch weder im Forms API Quickstart Guide noch in der Forms API Reference. Und meistens, wenn man hook_form_alter benutzt, dann macht man irgendwas mit Nodes und kann hook_nodeapi verwenden. Ich kann mir vorstellen, das viele diese Methode einfach nicht kennen.

Das stimmt natürlich. Aber wenn ich wollte, das Benutzer ihre Accounts löschen könnten, dann würde ich eher user_delete reparieren und einen Patch bereitstellen, als user_cancellation zu verwenden.

--

Danke für die Blumen.

Um ehrlich zu sein hatte ich den letzten Patch nicht getestet, er schien simpel und logisch. Nachdem ich ihn jetzt getestet habe, musste ich feststellen, daß das User-Objekt zu diesem Zeitpunkt noch nicht gelöscht ist und deshalb die Bedingung so nicht funktioniert.
Ich habe gerade eben einen neuen Patch commited [1], der den Bug beheben sollte, bitte schaut euch das mal an und gebt dort Feedback.

Geplant war übrigens Anfangs ein Modul mit vielen Einstellungsmöglichkeiten, wie:
- Benutzer darf seinen Account nur blockieren
- Benutzer darf seinen Account löschen
- Benutzer darf seine Daten offline schalten
- Benutzer darf seine Daten löschen
Wobei die es ein Backup der Daten geben sollte, das nach einstellbarem Zeitraum automatisch gelöscht wird, um der deutschen Rechtsprechung zu genügen.
- Konfigurierbare Auf wiedersehen-Seite
u.ä.

Akzeptiere gerne weitere Patches, die in diese Richtung führen ;)
vg

[1] http://drupal.org/node/181373

--
sanduhrs · Stefan Auditor · Drupalcenter
http://erdfisch.de · http://audiens.de · http://drupal.org/user/28074

Der Patch (Fussnote [1], voriger Beitrag) funktioniert bei mir nicht: schlimmer sogar, der Benutzer wird nicht mehr gelöscht und es erfolgt ein Wiederaufruf der Seite user/$user->uid.

Ob. gen. Patch von traxer hingegen funktioniert ausgezeichnet: 1:1 kann man den so nehmen, kopieren und einfügen; die Funktion hook_user() lässt sich m. E. ganz streichen (getestet). Mit dem Parameter "delete" hätte diese wohl auch eher eine modulspezifische Aufräumfunktion (Löschen von Datenbankeinträgen im Zusammenhang mit dem Benutzeraccount-Ableben) - das ist ja aber als Notwendigkeit im Falle user_delete nicht gegeben.

@sanduhrs: Mein Vorschlag ist, traxers Lösung zu übernehmen. Dann stimme ich zu: die Lösung ist klarer und empfindungsmässig sauberer als user_cancellation. Auch die erwähnten Features hören sich nett an. Höher gewichten würde ich meinerseits im Sinne der kleinen, überschaubaren und vor allem benutzerfreundlicheren Lösung:

1. das Umbenennen des 'Delete'-Buttons in 'Delete My Account' gemäss diesem drupal.org-Beitrag
2. das konfigurierbare Redirect nach dem Löschen
3. konfigurierbare Integration in das E-commerce Modul (optionales Accountdaten-Löschen nach erfolgter Bestellung)

Auch ohne eine Form-API-Guru zu sein, würde ich mich trauen, die Konfigurierbarkeit des Redirects auf die "Auf Wiedersehen"-Seite zu basteln.

Hast Du die Version aus dem CVS [1] geladen, oder selbst gepatcht?

Im Gegenteil hatte ich doch in meinem letzten Post erläutert, daß die Pläne für das Modul ganz große waren ;)

Das hatte ich tatsächlich überlegt und war dem auch sehr zugeneigt, allerdings empfinde ich in Bezug auf die erwähnte Zusatzfunktionalität die momentane Umsetzung als sinnvoller.

Das ist nun wirklich ein simpler Patch!

Ist bereits integriert, bitte probiere die letzte Version aus dem CVS.

auch ein schöner Patch zum Anfangen.

Das ist ja nun leider schon passiert, vielleicht versuchst Du Dich an den anderen, oder an den Zusatzfunktionen die ich gelistet hatte ;)
Dann einfach als Patch [2] im issue queue [3] posten, dann können wir auch zentral an einer Stelle drüber diskutieren.

vg

[1] http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/user_delete...
[2] http://drupal.org/patch/create
[3] http://drupal.org/node/add/project_issue/user_delete/feature

--
sanduhrs · Stefan Auditor · Drupalcenter
http://erdfisch.de · http://audiens.de · http://drupal.org/user/28074

Vielen Dank, Sanduhrs: mit der CVS-Version der user_delete.module funktioniert es jetzt sehr gut. (Nein, zu Beginn hatte ich von Hand gepatched - da war zu aller Verwirrung wohl zusätzlich noch etwas schiefgegangen; ich kann's jetzt nicht mal mehr nachvollziehen...)

Um noch einmal auf meine Eröffnungsfrage zurückzukommen: im Core ruft user_confirm_delete_submit() die Funktion user_delete() auf. Mir war zuerst entgangen, dass innerhalb von user_delete() via module_invoke_all() ja vor dem Return gerade hook_user() aufgerufen wird, das Du nun verwendest um das drupal_goto() abzusetzen. Da dadurch die Rückkehr zu den jeweils aufrufenden Funktionen unterbleibt, wird schliesslich auch in user_confirm_delete_submit() die letzte Zeile nicht mehr aufgerufen, nämlich das hardcodierte <?php return 'admin/user/user'; ?>
Mit anderen Worten: hook_user() ist darum Deine Entscheidung gegen Traxers Lösung, weil Du für weitere Aktionen hook_user() sowieso noch brauchst, womit das dann insgesamt kompakter wäre.

Ein ganz persönliches Danke für den "Winkewinke"-Redirect. Das war ja wie unterm Weihnachtsbaum :)

Danke auch noch einmal an Traxer für den Hinweis mit den multiplen Submit Handlern - das gibt's, habe ich inzwischen gesehen, zwar im "Drupal Dev Pro" auch beschrieben, aber nur im "Kleingedruckten". Wozu so etwas gut ist, ist mir eigtl. erst jetzt klarer geworden.

Gut zusammengafasst.
Freut mich, daßes jetzt funktioniert!
vg

--
sanduhrs · Stefan Auditor · Drupalcenter
http://erdfisch.de · http://audiens.de · http://drupal.org/user/28074