Posts by Fighter456

    Guten Abend,


    die Box für die letzten Aktivitäten zieht die Metadaten aus der Tabelle wcf1_user_activity_event. Dort sind die von dir genannten Informationen (userID, time) gesondert vorgehalten und müssten deinerseits dann auch dort geändert werden.


    Bitte denke aber daran, dass dort wirklich alles an letzten Aktivitäten festhalten wird und sich nur anhand der objectTypeID auseinanderhalten lässt. Deine Einträge solltest du aber mit einer absteigenden Sortierung ORDER BY time DESC schnell ausfindig machen können. Schließlich entspricht userID auch noch deiner Benutzer-ID (daraus lässt leitet sich technisch dann der entsprechende Benutzername ab).


    Ich hoffe ich konnte dir mit meiner Antwort helfen.

    Klicke mal auf Benutzer online und schaue nach, welcher UserAgent bzw. welche IP-Adresse hinter diesen Besuchern steckt. Mit Hilfe einer Suchmaschine deiner Wahl kannst du anhand dieser Informationen herausbekommen um welche Art von Besuchern es sich handelt und diese ggf. blockieren.


    Es ist definitiv kein Bug in der Software!

    Hallo!


    1. Wie ist es möglich dass man „Standard Titel“ für Beiträge erstellen kann. Damit meine ich, wenn man beispielsweise in einem Forum eine Bewerbung als Supporter absenden will, dass der Titel automatisch zu „Supporter Bewerbung | *Name des Users* | *heutiges Datum*“ geändert wird und dass der User den Titel nicht ändern kann.

    Das ist über den Standardumfang der Software nicht abgedeckt und bedarf eines Plugins, wenn du es wie gewünscht umgesetzt haben willst.

    Zudem würde mich interessieren ob es möglich ist, die 2 Faktor Authentifizierung für bestimme Gruppen zu erzwingen? Sodass beispielsweise Teamler eine 2 Faktor Authentifizierung aktivieren müssen.

    Ja, das ist möglich:

    Auf Basis von Benutzergruppen kann die Nutzung von Mehrfaktor-Authentifizierung erzwungen werden, um so vor allem sensible Benutzerkonten (wie Administratoren oder Moderatoren) besser zu schützen.

    Ich selber konnte den Fehler bisher zweimal aus vielen Versuchen lokal reproduzieren. Der Kunde kann es wohl mehrfach hintereinander reproduzieren.


    Kann dir die Pakete gerne zur Verfügung stellen, wenn dich das zur Fehleranalyse weiterbringt. Du musst aber ein klein wenig Einrichtungszeit mit einplanen, da der Worker von unserem Paketserver zur Verfügung gestellt wird und der komplett mit dem Shop verzahnt ist. Ein sofort lauffähiges Konstrukt könnte ich dir über einen MAMP Export zur Verfügung stellen, falls du MAMP im Einsatz hast. Sag mir bitte, was du gerne hättest.


    Dann als kurze Info nebenbei:

    Der Kunde nutzt PHP 8.0.11 mit und als DB-Server das unter Ubuntu verfügbare MySQL-Paket 8.0.26-0ubuntu0.20.04.3. Ich nutze aktuell PHP 8.0.0 unter MAMP und MySQL 5.7.32.

    Hallo,


    nein, so doof bin ich definitiv nicht, lieber Tim! Das zeigt auch ein Blick in euren Quellcode, dass das nicht die Ursache1 sein kann.


    Und doch, ich bin mir nach meiner Recherche ziemlich sicher, dass das die Lösung ist. Diese Prüfung haben größere Frameworks ebenfalls implementiert.


    In der entsprechenden Klassendatei unseres Shop wird keine Anweisung genutzt, die ein implizites Commit verursacht. Kann den Quellcode aufgrund der Lizenz nicht posten, aber das kannst du mir gerne glauben.


    Das ist auch kein Verstecken eines Programmierfehlers unsererseits. PHP 8.0 arbeitet an dieser Stelle anders und bringt die entsprechende Meldung zum Vorschein währenddessen Versionen <8 dies geflissentlich hingenommen und ignoriert hat. Nutze die Suchmaschine deines Vertrauens und lese dich ein. Zwischen Meldung vom Kunden und dem heutigen Tag sind insgesamt auch 3 Tage bei mir vergangen, da ich sicher sein wollte, dass das kein Problem im KittMedia Shop ist.


    1: Ihr inkrementiert in beginTransaction() (pro Aufruf) die Variable activeTransactions und führt PDO::commit() bzw. RELEASE SAVEPOINT level innerhalb von commitTransaction() nur aus, wenn activeTransaction > 0 bei Aufruf ist.

    Hallo,


    bei einem unserer Kunden trat in Verbindung mit dem KittMedia Shop und WSC 5.4 das Problem auf, dass eine Datenbank-Transaktion die automatisch übernommen/ausgeführt (autocommit=1; Standardwert) wird, nun unter PHP 8.0 zu der Fehlermeldung "Could not commit transaction" mit der ursprünglichen PDO-Fehlermeldung "There is no active transaction" führt.


    Eine kurze Recherche zeigte auf, das PHP 8.0 diese vormals unterdrückte Meldung nun ans Tageslicht bringt. Wir haben dem Kunden eine angepasste Database.class.php zur Verfügung gestellt, wo jeweils bei Database::beginTransaction(), Database::commitTransaction() sowie Database::rollBackTransaction() explizit überprüft wird, ob man sich tatsächlich noch in einer laufenden Transaktion befindet (PDO::inTransaction()) und diese nicht schon automatisch übernommen/ausgeführt wurde.


    Das Problem dürfte in allen WSC Version auftreten können die mit PHP 8 kompatibel sind und darunter ausgeführt werden.


    Die ursprüngliche Fehlermeldung lautet wie folgt, ist aber eigentlich für die Erforschung der Ursache uninteressant, da oben genannt:

    Requested URL
    POST /acp/index.php?worker-proxy/&t=REDACTED
    Referrer
    https://REDACTED/acp/index.php?rebuild-data/
    Error Message
    Could not commit transaction
    Type
    wcf\system\database\exception\DatabaseTransactionException
    File (Line)
    /var/www/REDACTED/lib/system/database/Database.class.php (243)
    Stacktrace
    1. /var/www/REDACTED/shop/lib/system/worker/PackageServerRebuildDataWorker.class.php (113): wcf\system\database\Database->commitTransaction(…)
    2. /var/www/REDACTED/lib/acp/action/WorkerProxyAction.class.php (104): kpps\system\worker\PackageServerRebuildDataWorker->execute(…)
    3. /var/www/REDACTED/lib/action/AbstractAction.class.php (53): wcf\acp\action\WorkerProxyAction->execute(…)
    4. /var/www/REDACTED/lib/action/AJAXInvokeAction.class.php (65): wcf\action\AbstractAction->__run(…)
    5. /var/www/REDACTED/lib/system/request/Request.class.php (89): wcf\action\AJAXInvokeAction->__run(…)
    6. /var/www/REDACTED/lib/system/request/RequestHandler.class.php (119): wcf\system\request\Request->execute(…)
    7. /var/www/REDACTED/acp/index.php (11): wcf\system\request\RequestHandler->handle(…)
    Error Message
    There is no active transaction
    Type
    PDOException
    File (Line)
    /var/www/REDACTED/lib/system/database/Database.class.php (226)
    Stacktrace
    1. /var/www/REDACTED/lib/system/database/Database.class.php (226): PDO->commit(…)
    2. /var/www/REDACTED/shop/lib/system/worker/PackageServerRebuildDataWorker.class.php (113): wcf\system\database\Database->commitTransaction(…)
    3. /var/www/REDACTED/lib/acp/action/WorkerProxyAction.class.php (104): kpps\system\worker\PackageServerRebuildDataWorker->execute(…)
    4. /var/www/REDACTED/lib/action/AbstractAction.class.php (53): wcf\acp\action\WorkerProxyAction->execute(…)
    5. /var/www/REDACTED/lib/action/AJAXInvokeAction.class.php (65): wcf\action\AbstractAction->__run(…)
    6. /var/www/REDACTED/lib/system/request/Request.class.php (89): wcf\action\AJAXInvokeAction->__run(…)
    7. /var/www/REDACTED/lib/system/request/RequestHandler.class.php (119): wcf\system\request\Request->execute(…)
    8. /var/www/REDACTED/acp/index.php (11): wcf\system\request\RequestHandler->handle(…)

    {$BedList|wcfDebug} bzw. wcfDebug($BedList); oder var_dump($BedList); innerhalb von PHP, insofern die Variable dort den selben Namen hat.


    Das Problem wird $BedList[$meetingRoom->roomID] sein.


    Mal ins Blaue geraten:

    PHP
    {if $BedList[$meetingRoom->roomID]|isset && $meetingRoom->beds - $BedList[$meetingRoom->roomID]["beds"]>0}


    Solche Logik würde ich persönlich übrigens in Methoden auslagern. Beispielsweise hieße die bei dir MeetingRoom::canBeBooked() welche dir entweder true oder false zurückliefert und ggf. auch schon $meetingLocked mit einbezieht.

    Die Erstellung bzw. Pflege der package.xml fühlt sich aber noch nicht wirklich rund an…

    Man kann sich halt nicht wirklich darauf verlassen. Wenn die GUI einem suggeriert, dass das geändert übernommen worden ist und ein Blick in die package.xml allerdings das Gegenteil beweist, dann ist es definitiv keine Erleichterung bei der Arbeit. Das selbe gilt auch für den aktuellen Fall, wo ich erst einmal in die Dokumentation schauen muss und zu wissen, was überhaupt die GUI von einem erwartet.


    Wäre super, wenn das zukünftig noch verbessert werden könnte.


    Gerade eine Änderung an der de.xml vorgenommen und versucht über die GUI zu synchronisieren. "Bitte in die Browserkonsole schauen, da die Antwort vom Server leer ist". Änderungen wurden in dem Fall allerdings übernommen.

    Handhabe das bisher genauso wie du und wollte die Entwickler-Tools nur einmal getestet haben. Gerade da ich das PiP für die Datenbank noch nicht kannte und mir daher überhaupt nicht sicher war, was erwartet wird. Das wollte ich mir dann "kurz über die GUI" zusammenklicken. Aber Pustekuchen.


    Habe gerade auch festgestellt, dass das "In eigenem Schritt ausführen" aus der GUI nicht in die package.xml übertragen wird. Wird gespeichert und nach dem Neuladen ist alles beim Alten.

    Hallo,


    ich versuche gerade das neue "database"-PiP in einem Plugin einzusetzen. Laut Beschreibung soll das Plugin die Dateien an folgender Stelle suchen:

    Quote from Overlay - GUI vom PiP

    Wenn keine Datei angegeben wird, wird folgende Datei verwendet: acp/database/*.php.

    Sende ich das Formular allerdings ab, wird versteckt im Reiter "Anweisungen" die folgende Fehlermeldung beim Schritt für das "database"-PiP angezeigt.


    Quote

    Die angegebene Skript-Datei konnte an keiner der folgenden Stellen gefunden werden: LOKALER_PFAD_ZUM_PROJEKT/files

    Bearbeite ich den Schritt und gebe den Pfad acp/database/setup.php manuell an, kann ich das Formular problemlos absenden und die Änderung wird in der package.xml übernommen.


    Bei dem Projekt handelt es sich um eine eigenständige Anwendung für Suite Core. Installiert ist Suite Core 5.4.4.

    Nein, eine Ausführung der unter Anzeigen aktualisieren verfügbaren Aktionen ist im Regelbetrieb nicht notwendig. Eine Notwendigkeit besteht zum Beispiel nach der Durchführung eines Imports und/oder nach der Durchführung eines Upgrade auf eine neue Version.

    Die letzten Aktivitäten ließen sich durch Entwicklung eines entsprechenden Plugins sicherlich rekonstruieren, allerdings ist mir bisher kein Plugin in dieser Richtung bekannt. Und ob sich alle Aktivitäten rekonstruieren lassen, lässt sich pauschal auch nicht beantworten.

    Insofern du ältere Datensicherungen von der Datenbanktabelle hast, könnte man sogar damit arbeiten. Dies würde auch für eine Wiederherstellung von dem Veränderungsverlauf der Beiträge gelten.


    Beides ist allerdings nur mit entsprechenden Kenntnissen möglich.


    Die 365 Tage zählen ab dem aktuellen Tag (bzw. Ausführungsdatum vom Cronjob) minus 365 Tage oder dem entsprechend eingestellten Wert.

    Das heisst also, ich kann keine Aktivitäten, die älter als 30 Tage (aktuelle Einstellung) sind, anzeigen lassen, selbst wenn ich den Wert jetzt auf 60 erhöhe? Und gibt es da ein Limit für den Wert? Dann würde ich den auf 365 Tage einstellen.

    Insofern die Daten nicht (mehr) in der Datenbank vorliegen, könnten diese rückwirkend dann natürlich nicht mehr angezeigt werden.

    Ich habe jetzt im ACP mehrere Optionen für "letzte Aktivitäten" gefunden - auch unter "Mitglieder" - muss ich das dann überall ändern?

    Von welchem Bereich redest du? Ich finde über die Suche nach "Aktivität" keine Option die unter "Mitglieder" einsortiert ist. Ist das bei dir eventuell eine Option, die durch ein Plugin kommt?

    Ich habe die Option für "letzte Aktivitäten" im Benutzerprofil jetzt auf 365 Tage erhöht. Gilt das dann auch gleichzeitig für das Dashboard unter "Aktivitäten aller Benutzer"?

    Das sind die letzten Aktivitäten, korrekt. Hast du hier im Dashboard ebenfalls.

    Eine andere Option habe ich auch noch von 30 auf 365 Tage erhöht: "Änderungen" - worauf bezieht sich das? Auf die Anzeige im globalen Änderungsprotokoll des ACPs?

    Die "Speicherzeit für Änderungen" bezieht sich auf die Aufbewahrung im globalen Änderungsprotokoll, korrekt.

    Im ACP findest du die Option "Letzte Aktivitäten". Anhand des Wertes (standardmäßig 60) wird festgelegt, nach wie vielen Tagen die letzten Aktivitäten durch den vorgenannten Cronjob verworfen werden.


    Die Tabelle mit den Aktivitäten füllt sich übrigens nur, wenn es neue Aktivitäten gibt. Eine rückwirkende Befüllung der Tabelle mit älteren Datensätzen ist nicht vorgesehen.