SayAdmin

Nenne Objektart, sichtbaren Namen und gewünschte Änderung möglichst konkret.

Bei fehlgeschlagenen Mutationen bzw. Tests wird – soweit implementiert – der vorherige kontrollierte Zustand wiederhergestellt oder die Transaktion zurückgerollt.

Eine Löschung unterliegt Abhängigkeits- und Risikoprüfungen; Default-/verwendete Styles benötigen besondere Vorsicht.

`media.delete` entfernt eine Datei nur über den dafür vorgesehenen Sicherheitsweg.

Assignment-Actions verwalten die vorgesehenen Workflow-Zuordnungen.

`categories.structure` liefert eine lesende Sicht auf die Hierarchie.

Die Usage-/Audit-Funktionen können bekannte Zuordnungen sichtbar machen.

`system.alerts` aggregiert sichere Administratorwarnungen aus mehreren Bereichen.

Eine Send-Action bereitet eine neue Joomla-Nachricht vor.

`users.batch_block` unterstützt eine Batch-Sperränderung.

`articles.state` ändert den Veröffentlichungszustand eines vorhandenen Beitrags nach Bestätigung.

Nutze die Field-Trash-Action statt einer endgültigen Löschung.

Nur wenn die Remote-Funktion, die globale Red-Freigabe und die erforderliche Remote-ACL dies zulassen.

Lesende Remote-Aktionen sind möglich, sofern Remote-Zugang, Chat und die jeweilige Joomla-/SayAdmin-Berechtigung dies erlauben.

Ja, sofern der Benutzer eindeutig ermittelt und die notwendige Berechtigung geprüft werden kann.

Ja, sofern der entsprechende Menüeintragstyp im Action-Vertrag unterstützt wird.

Ja. Das Sicherheitsmodell trennt reine Leseaktionen von bestätigungspflichtigen und besonders kritischen Mutationen.

Für die zugehörigen Webservice-/Remote-Funktionen muss das Plugin verfügbar und entsprechend aktiviert sein. Reine Backend-Funktionen sind davon getrennt zu betrachten.

Damit die Vorschau den tatsächlichen Istwert zeigt und ein anschließender Readback die gespeicherte Änderung verifizieren kann.

Clientschalter allein sind keine Sicherheitsgrenze. Die API muss jede Anfrage anhand der serverseitigen Rechte validieren.