Posts by lukas.imhof

    Hätte ich fast vergessen: Ich hab heute noch einen Fix in die aktuelle Nightly reingemacht für das clientSecret

    Dieses wurde zwar in den Preferences korrekt gespeichert. Wenn man aber danach auf dem Tab nochmal gespeichert hat, ohne das Secret erneut reinzuschreiben, wurde es mit einer internen Konstante überschrieben...
    => das ist wie gesagt in der aktuellen Nightly 10.1.1 gefixt.

    Zum Prüfen, ob das clientSecret korrekt gespeichert ist, kannst du dir die Konstante SMTP_CLIENT_SECRET über ein Template ausgeben lassen

    Die Einstellungen sehen gut aus, bis auf den Port: muss 587 sein
    => mit 993 geht bei mir auch nichts raus

    Wenn es damit immer noch nicht geht, kann es an der den Rechten und freigeschalteten Aktionen für die MS-Application liegen, was leider etwas tricky ist: hab ich jedoch auch nicht selbst eingerichtet. Ich weiß aber, dass ein neuer Exchange 365 per default gar kein SMTP mehr bedient (die rechnen mit graph/REST API). SMTP muss also extra freigeschaltet werden für das entsprechende Konto. Ist das gegeben, muss die Application nur einfach das das Recht SMTP.sendAsApp aufweisen.

    Falls es weiterhin nicht geht, kannst du erstmal in der DB checken, ob er das Token bekommen hat:
    Wenn er es bekommen hat, gibt es in tblCaptcha einen aktuellen Eintrag vom Typ mailAccessToken

    Hallo Christoph,

    das sollte ja längst ordentlich dokumentiert sein... ;)

    Ich kann dir gerne morgen deine Klassen, gemäß der aktuellen Syntax umschreiben:
    anhand dessen kannst du dir diese dann für andere Klassen-Übergaben erschließen...

    Wenn die du die im Dropdown sichtbaren Klassennamen durch sprechendere Namen ersetzen willst (gesetzt werden vom Tiny natürlich trotzdem die echten Klassen), kannst du mir auch eine entsprechende Liste noch hier mit anführen mit "Sichtbarer Name => Klasse"-Paaren.

    LG Lukas

    Wir brauchen OAuth 2.0 auch unbedingt bei astendo und ich habe dafür folgendes Ticket angelegt:
    0014404: OAuth2 für den Mailversand per SMTP - webEdition CMS - Quality Assurance

    Ich bin mir noch nicht sicher, wie generisch man das machen kann, sprich: ob wir a) für verschiedene Mailserver und b) für verschiedene Autorisierungs-Server spezifische Implementierungen benötigen.

    Bei uns geht es in erster Linie um den MS Exchange und die gängigen Autorisierungs-Server, die in Kombination damit verwendet werden (z.B. Azure), deshalb werde auch auf jeden Fall erstmal gegen den Exchange entwickeln.

    Ich hab das in 9.2.2.1 (nightly) provisorisch gefixt.

    Wichtig:
    Standard für Conditions ist eigentlich die Verwendung von Feldnamen ohne Typ-Präfix, also meinInput statt input_meinInput oder meinInt statt int_meinInt. Aufgrund des Fixes muss nun aber bei Feldern vom Typ object von dieser Regel abgewichen werden: also object_2=14233 statt 2=14233, weil bei der jetzigen Implementerung nur so der oben beschriebene Fehler verhindert werden kann.

    Ob nun die Verwendung von Object-Feldern bei Conditions noch funktioniert, die mit we:condition erzeugt werden, muss ich erst noch prüfen...
    => eine definitive Lösung wird auf weiter verbesserten Condition-Tags beruhen, was jedoch nicht per sofort gemacht werden kann.