Benutzerverwaltung - User löschen erzeugt Fehlermeldung

    Hallo,


    beim Löschen eines Benutzers erhalte ich folgende Meldung:


    Code
    SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (`dbname`.`ike46_it_issues`, CONSTRAINT `ike46_it_issues_identified_by_fk` FOREIGN KEY (`identified_by_person_id`) REFERENCES `ike46_it_people` (`id`))


    Was kann das sein? Irgendwelche Querverbindungen zum User sind noch vorhanden?


    Hat jemand einen Tipp, wie ich herausbekomme, welche Querverbindung ich noch auflösen müsste.


    Vielen Dank für Tipps.

    Hallo zusammen und vielen Dank, dass ihr mir helft:


    1.) Issuetracker hat zwar den User auch drin und sagt, wenn ich ihn dort lösche beeinflußt das die Joomla-User-Tabelle nicht, aber auch dort wird ein Fehler angezeigt. Lautet identisch, wie oben gepostet!

    2.) Debug-Modus hab ich aktiviert.

    3.) im System ist die Datenbank eine MySQL (PDO)-Datenbank


    Wenn ich jetzt im aktivierten Debug-Modus den Benutzer löschen werde, dann brauchst du sicherlich entsprechende Werte, damit dir das was sagt?

    Interessanterweise ist jetzt der Benutzer weg aus der Benutzerverwaltung, aber im IssueTracker weiterhin vorhanden - selbst wenn ich dort die Benutzer synchronisiere.


    Dann kann ich versuchen ihn zu löschen und erhalte folgende Meldung:

    Code
    23000 SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`Datenbankname`.`ike46_it_issues`, CONSTRAINT `ike46_it_issues_assigned_to_fk` FOREIGN KEY (`assigned_to_person_id`) REFERENCES `ike46_it_people` (`user_id`)) 
/www/htdocs/lokalerwebserver/domainname/libraries/joomla/database/driver/pdo.php:410


    Darunter ist der Call-Stack abgebildet:


    Call stack
    # Function Location
    1 () JROOT/libraries/joomla/database/driver/pdo.php:410
    2 PDOStatement->execute() JROOT/libraries/joomla/database/driver/pdo.php:410
    3 JDatabaseDriverPdo->execute() JROOT/administrator/components/com_issuetracker/models/itpeople.php:329
    4 IssueTrackerModelItpeople->delete() JROOT/libraries/src/MVC/Controller/AdminController.php:132
    5 Joomla\CMS\MVC\Controller\AdminController->delete() JROOT/libraries/src/MVC/Controller/BaseController.php:710
    6 Joomla\CMS\MVC\Controller\BaseController->execute() JROOT/administrator/components/com_issuetracker/issuetracker.php:47
    7 require_once() JROOT/libraries/src/Component/ComponentHelper.php:382
    8 Joomla\CMS\Component\ComponentHelper::executeComponent() JROOT/libraries/src/Component/ComponentHelper.php:357
    9 Joomla\CMS\Component\ComponentHelper::renderComponent() JROOT/libraries/src/Application/AdministratorApplication.php:101
    10 Joomla\CMS\Application\AdministratorApplication->dispatch() JROOT/libraries/src/Application/AdministratorApplication.php:159
    11 Joomla\CMS\Application\AdministratorApplication->doExecute() JROOT/libraries/src/Application/CMSApplication.php:195
    12 Joomla\CMS\Application\CMSApplication->execute() JROOT/administrator/index.php:51



    damit kann ich gerade nichts anfangen, was mir das sagen soll.

    Hilft dir wahrscheinlich nicht viel. Hab getestet.


    Ein existierendes Joomla. Tabellen wurden angelegt unter MySQLi.

    Umgestellt auf MySQL (PDO). Issue Tracker installiert. Benutzer synchronisiert. In den Optionen jeweils ausprobiert "Delete Mode" "Hard" und "Soft" und kann sowohl Joomla-Nutzer als auch Issue-Tracker-People löschen ohne Fehler. Egal, welche Reihenfolge

    ganz ehrlich... das hilft mir gerade nicht. Da hätte ich tatsächlich drauf gewettet, dass du die zündende Idee hast...

    Vielen Dank aber trotzdem, dass du dir das angeschaut hast.

    komisch auf jeden Fall...


    Der Joomla-User ist ja jetzt auch aus einem nicht erklärbaren Grund weg, aber der IssueTracker-User ist nicht löschbar :(


    Hab auch sonst eigentlich nix installiert, was selbst User verwaltet.

    ehrlich, ich hab noch weniger Plan gerade, was das Problem sein sollte :(

    ich betreibe das ganze unter Windows... habe das ganze aber auch, weil ich es mal so auf die richtige Domain kopiert hab, bei einem Hoster.

    Problem bleibt leider das gleiche... nur die Pfade sind entsprechend andere.

    einzige Information, dich ich eben auch festgestellt habe.

    wenn ich mittels PHPmyAdmin auf die Datenbank direkt gehe und mir die Tabelle _it_people anschaue, dann könnte ich dort den User ja direkt löschen.

    Aber auch das dauert so lange, dass es irgendwann abbricht bzw. nicht abgeschlossen werden kann... warum, dass direkt auf einer Datenbank auch nicht möglich wäre, weiß ich allerdings gerade nicht.


    Ich hätte gedacht, dass ich dort zumindest den User direkt löschen könnte.

    Vielleicht sollte ich bei Joomla den User in der DB nochmal anlegen, damit im IssueTracker die Verbindung zum Joomla User erneut erstellt werden könnte - auch wenn IssueTracker behauptet, dass es unabhängig von der Joomla User-Tabelle wäre.


    Ist nur so eine Idee...

    Bringt sowas überhaupt theoretisch was?

    Der Fehler tritt auf, wenn das System versucht, Issues an denen der Benutzer beteiligt ist, zu aktualisieren.


    EDIT: Und ähnlich, wenn du versuchst den User direkt in DB zu löschen.


    Dabei wird versucht in der Tabelle it_issues

    die Spalte assigned_to_person_id auf den in der konfiguration eingestellten User unter "Default assignee" zu setzen,

    die Spalte identified_by_person_id auf den in der konfig. eingestellten User unter "Deleted Issues User" zu setzen.


    Also versucht ein "UPDATE ..." zu machen. Auch, wenn die Einstellung "Delete Mode" suggeriert, dass Issues des Users gleich mitgelöscht werden können, ist das codeseitig nicht der Fall, sondern immer wird das UPDATE gemacht.


    Die Spalte assigned_to_person_id hat aber eine Fremdschlüsselbeziehung auf "it_people.user_id", die dieses Update verhindert. In der Strukturansicht der Tabelle it_issues findet sich bei mir ein unscheinbarer Link "Beziehungsübersicht" mit folgendem Eintrag:


    Laienhaft ausgedrückt (weil ich es nicht anders kann): Es ist dir nicht erlaubt, die Spalte dieses Datensatzes (child row) auf diesem Wege zu updaten, da eine RESTRICT-Fremdschlüsselbeziehung zur people-Tabelle (parent) besteht. Hier dazu ein bisschen Hintergrundwissem.


    Und (so verstehe ich es zumindest): Erst müsste der User in people gelöscht werden, dann erst, kann die Tabelle it_issues geupdatet werden.


    Der Code um "JROOT/administrator/components/com_issuetracker/models/itpeople.php:329" macht es aber umgekehrt.


    Was ich also versuchen würde um dem Bug(?) auf die Spur zu kommen bzw. um Rauszukriegen, ob das die Ursache ist.


    Test 1)

    Verschieben des User-Löschens vor das Update:



    Oder Test 2:

    In Zeile 327 einfügen (Fremdschlüsselprüfung deaktivieren):

    Code
    $this->_db->setQuery('SET FOREIGN_KEY_CHECKS=0')->execute();

    was die DB/das System aber erlauben muss. Nicht immer der Fall.


    Aber auch hier stellt man wieder fest, dass Issue-Tracker mit "händisch formulierten" SQL arbeitet anstatt zukunftsicher die Joomla-DB-API zu verwenden. Wär aber wohl wurst für dieses Problem.

    Erklärt sich aber natürlich dann, wenn die anderen User keine Issues eingereicht haben :( Dann gibt es kein Problem mit dem Restrict usw.


    Weiteres dazu... es hängen aber noch mehr dran, wenn ich die Beziehungsanzeige von _it_people anschaue.

    Mindestens unter it_projects muss ich die ID noch kontrollieren und in it_roles, denke ich.

    Dann könnte es tatsächlich klappen. den User direkt in der DB zu löschen, oder?

    Kann nur "Vermutlich." sagen.


    Aber dann würde ich doch zuvor mal die Variante "Test 2" oben ausprobieren und noch mal aus Backend versuchen.


    Ich persönlich halte die zahlreichen Fremdschlüssel von Issue-Tracker für etwas verquer. Ich würde so was über PHP-Code lösen. Abfrage, ob Querverbindungen existieren. Dann anständige Meldung. "Geht nicht, weil aktive Issues/Rollen existieren und ähnlich".


    Mir erklärt sich jetzt aber auch, warum ich bei Testläufen mit Issue-Tracker und späterem Neuaufsetzen der Testseite beim Ausputzen der DB häufiger mal Meldungen bekam, wenn ich Tabellen zuvor löschen oder leeren wollte. Musste dann häufiger mehrfach ansetzen. Irgendwann war dann auch die letzte Tabelle gelöscht.