Guten Abend,
habe ein kleines sr_feuser_register Problem.
Wenn ich als angemeldeter User mein Profil ändere und
es abspeichere wird mein Konto nach erfolgreichem Speichern auf disable gesetzt.
Also nach dem Speichern schmeißt er mich raus weil er mich dann nicht mehr als angemeldeter User erkennt.
Muss dann ins Backend und in den SysOrdner und ihn dann wieder freischalten.
Hat irgendjemand vielleicht eine Idee ?
Gruß
Hallo,
also bin nach wie vor noch nicht drauf gekommen.
Habe mir den Hook registrationProcess_afterSaveEdit mal
angesehen, aber irgendwie finde ich da nix.
Werde nach dem Edit automatisch ausgeloggt und der Benutzer-Account
wird disabled (fe_users->disable=1 ).
Seltsam da es vor einiger Zeit ja noch ging....
Gruß
Hallo Scoop,
habe exakt dasselbe Problem... Ist natürlich im Live-Einsatz undenkbar, dass Benutzer nach jeder Änderung erst wieder freigeschaltet werden müssen - oder ist es ein Sicherheitsfeature o.O
Hast du mittlerweilen eine Lösung gefunden?
Im Quelltext der fertig gerenderten EDIT-Seite ist disable auf 0 gesetzt (im Javascript), dennoch schreibt er disable=1 in die DB und setzt die usergroup zurück auf die ID der "userGroupUponRegistration".
Hab schon in vielen Foren gestöbert deswegen - leider ohne Erfolg.
Grüße,
Michael
P.S. Habe mir nochmals den gerenderten Quelltext vorgenommen: Auf der Seite mit den Formularfeldern (EDIT) ist im JS disable=1 und usergroup=4 (Bestätigte) gesetzt (wie es sein sollte) und auf der EDIT_PREVIEW-Seite steht dann plötzlich disable=0 und usergroup=3 (Unbestätigte). Und so werden die Werte auch in die DB geschrieben. An welcher Stelle werden die Werte rückgesetzt? Kann in der class.tx_srfeuserregister_pi1.php nichts finden...
Hallo mspindler,
sorry habe den tread ganz vergessen.
also es war ein dummer fehler bei mir. Habe in dem template das für die edit
seite zuständig ist, die befindet sich im passwortgeschützten bereich, im typoscript object browser unter tx_srfeuserregister_p1 dann wieder unter dem
edit bereich und dort unter default values u. override value disable = 1 stehen gehabt, geändert auf 0 und es ging.
gruß
Hallo Scoop,
das Problem bleibt, ich hatte im Setup bereits
edit {
defaultValues {
disable = 0
usergroup >
}
}
overrideValues {
disable = 0
username =
usergroup >
}
}
eingetragen.
Meine Konfiguration sieht jedoch etwas anders aus:
Eine übergeordnete Seite hält die allg. Plugin-TS-Konfiguration (siehe oben). Eine erste Unterseite ist fürs Registrieren zuständig (CREATE). Das Editieren der Userdaten ist auf mehrere Unterseiten verteilt, d.h. jeweils das Plugin mit Code "EDIT" und ein TS-Template mit den nötigen formFields und requiredFields:
meinBereich <- generelle TS-Konfiguration
|
|- Registrieren <- TS-Konfiguration für CREATE (formFields, requiredFields)
|
|- Zugangsdaten <- Plugin (EDIT) und TS-Template (formFields=password)
|
'- Teamleitung <- Plugin (EDIT) und TS-Template (formFields=username, password, first_name, last_name, address...)
usw.
Liegt es an dieser verteilten Form? Sollte doch eigentlich kein Problem darstellen, oder? #paralyzed#
Grüße,
Michael