Beiträge von SLM

  • 2FA-Plugin auch für Mobileversion

    Zitat von Sebijk

    Ja, ich habe sie für die mobile Oberfläche auch im Einsatz. Geht natürlich nur mit der OSS-Variante, weil die 7.4-Version kein Plugin-Hook für die mobile Oberfläche dafür hat.

    Danke für die Info. Der Filehandler ist, soweit ich das erkennen kann leicht auch für die 7.4.0 noch nachrüstbar:


    Code
        serverlib/plugin.class.php:
    
    /**
    * user page handler for mobile interface.
    */
   public function FileHandlerMobile($file, $action)
   {
   }


    Code
    m/alle PHP-Dateien:

/**
 * file handler for modules
 */
ModuleFunction('FileHandlerMobile',
	array(substr(__FILE__, strlen(__DIR__)+1),
	isset($_REQUEST['action']) ? $_REQUEST['action'] : ''));


    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.


    Kannst du uns eventuell nen Tipp geben, was am 2fa-Plugin und ggfls. noch an der mobilen Version angepasst werden muss damit das funktioniert? Geht ja nur ums Login. Die Aktivierung soll weiterhin nur im UCP möglich sein.

    Dann wäre das System zumindest ein Stück weit sicherer. Wäre echt toll..

  • b1gMailServer ist nun OpenSource

    Zitat von PhiGi

    Hi Sebijk,

    das Problem hat sich beim warten auf eine Antwort von selbst gelöst. Plötzlich - einige Stunden nachdem ich es aufgegeben habe - wurde die Warteschlange abgearbeitet. Ich kann nicht mehr Nachvollziehen warum das so ist. Schade.

    Update: Ich sehe es hängen wenige Mails nun wieder in der Warteschlange mit dem Fehler: Inbound pipe: b1gMail pipe rejected message data (keep-alive: 1).

    Aber andere werden Zugestellt. Langsam werd ich irre =)

    LG,
    PhiGi

    Prüf mal deine Grundeinstellungen, Wir haben damit gute Erfahrungen gemacht:

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

  • b1gMail 7.5 - Vorschläge

    Sebijk Wichtig wäre es, die Datenbankarchitektur bzw. die Archtitektur, wie Daten gespeichert werden in Angriff zu nehmen. Aktuell werden z.B. die E-Mails (bzw. die Verweise) für alle User in der Tabelle _mails gespeichert. Das kann größeren Systemen Probleme verursachen, von eventuellen Datenbank-Crashs bei Ausfällen ganz zu schweigen. Man kann dem Kunden in dieser Form auch schlecht ein eigenes Backup anbieten (könnte man z.B. optional, gegen Aufpreis).

    Im alten Forum hatten wir mit patrick und informant schon mal darüber diskutiert. Welche Lösungen hier sinnvoll sind, darüber sollten wir sprechen. Eventuell pro User eine Tabelle / Datenbank oder welche Möglichkeiten auch immer. Vorschläge sind hier gerne willkommen.

  • b1gMail 7.5 - Vorschläge

    Ganz wichtig: Ein Update der SabreDAV-Integration. Die aktuelle Version macht wirklich Probleme bei Terminen, wenn man das über verschiedenen Geräte hinweg synchronisiert und managed.

    Ich hatte es schon mehrfach erwähnt: ich kann nicht programmieren. Wenn es aber jemand gibt der das mal in Angriff nehmen will, unterstütze ich wo ich kann.

  • b1gMail 7.5 - Vorschläge

    Zitat von Sebijk

    Meine aktualisierte Planungen für b1gMail 7.5:

    Kernprodukt sollte die E-Mail sein....

    Es wäre m.E. sinnvoll wenn man b1gMail, im Speziellen auch die Funktion E-Mail, unter Sicherheitsaspekten weiter entwickelt. Wenn man b1gMail mit Anbietern wie Proton oder Tuta vergleicht - die mittlerweile Millionen von Usern verzeichnen, fehlt uns etwas Entscheidendes, die Verschlüsselungsmöglichkeit. Dazu gibt es verschiedene Ansatzpunkte:

    - Vollständige Integration von PGP für den Mailaustausch
    - Daten verschlüsselt speichern, sowohl die Files als auch die Inhalte der Datenbank

    Tuta fährt hier einen sehr interessanten Ansatz, nämlich auch Open Source.

    Zumindest diskutabel, wie ich finde.

  • App für iOS / Android

    Die letzte Version von Martin ist die 2.4.0 und funktioniert bis android-targetSdkVersion 31 (=Android 12). Hab meine Version schon an API 33 / Android 13 Stückweise angepasst. Ist aber alles nicht so einfach wenn man keine Ahnung hat :D

    Im Firebase Menü unter Cloud Messaging wird mir nun auch das angezeigt:

    Falls Sie bisher die HTTP API oder XMPP API (Legacy, wurde am 20.06.2023 verworfen) genutzt haben, müssen Sie bis zum 20.06.2024 zur aktuellen Firebase Cloud Messaging API (HTTP v1) migrieren.

    Die Legacy Api verwende ich scheinbar auch. Hab im Script bzw. in der App schon nachgesehen, wie das implementiert ist, werde aber noch nicht schlau draus. Eventuell können wir das ja zusammen angehen und herausfinden? Bis Juni 2024 ist nicht mehr so viel Zeit.

  • Fehler beim Update auf die aktuell RC

    Zitat von patrick

    Ein DB-Update im Hintergrund ist schwierig, da der neue Code ja schon das geänderte Schema vorausetzt. ..

    Verstehe ich. Das DB-Update könnte man aber auch manuell durchführen, wenn man die SQL-Anweisungen zur Verfügung hat. Damit könnte man zumindest den Fortschritt selbst steuern, eventuell ja schon vorbereiten, während man dann das Script updatet.

    Das betrifft Systeme nicht die nur wenige Nutzer haben. Bei mir klingeln sämtliche Kanäle, wenn das System mal ne halbe Stunde nicht zur Verfügug steht.

  • Fehler beim Update auf die aktuell RC

    Zitat von Denny

    Wie ich geschrieben habe denke ich, dass hier ein timeout vorliegt oder das Update ein zweites mal durchgeführt wurde. Ich würde den Punkt für Datenbankoptimierung komplett raus nehmen, dauert bei mir 6 Stunden

    Das ist auch mit ein Grund warum ich bislang kein Update gemacht habe. Einen mehrstündigen Ausfall kann ich meinen Kunden nicht zumuten. Deshalb wäre es eben wünschenswert, das Update manuell und ggfls. das DB-Upgrade im Hintergrund ausführen könnte.

  • Entscheidungsfreiheit bei Anrede ggf. mit Pronomen

    Sprache ist lebendig, Sprache hat sich schon immer gewandelt. Deshalb gibt es kein Gut oder Böse.

    Das Thema Anrede muss im Kontext gesehen werden, wann und in welchen Fällen sie tatsächlich verwendet wird. In erster Linie ist (nur) eine Angabe in den Kontaktdaten. Natürlich kann die Anrede dann vom System an unterschiedlichen Stellen verwendet werden (z.B. Newsletter). Und letztendlich kommt es auch auf dein Publikum an.

    Ich hatte ja vor einiger Zeit einen Fix dafür angeboten, der auch übernommen wurde: Firma + SteuerNr. / Ust-ID + Anrede ergänzt

    Wenn es dein Publikum verlangt oder notwendig macht, kannst du ja jederzeit erweitern :)

  • Support System

    ManDal

    Wenn man mehr als 2 Sprachen nutzt, ist der VARCHAR-Wert 100 in der Tabelle mod_supportsystem_department für die Spalten Name und Short zu klein. Ich musste bei mir den Wert anpassen (aktuell 500). Sonst lassen sich die Abteilungen nicht mehr speichern und die DB-Einträge werden abgeschnitten.

  • Nur für Login: Sprache wählen

    Gibt es eine Möglichkeit nur beim Login die Sprache zu wählen? Mit dem switchLanguage-Befehl wird der gesamte NLI-Bereich geswitcht und der Sprachbefehl in den LI-Bereich übernommen. Bei Templates mit vielen NLI-Seiten ist das problematisch.

    Ich suche daher nur eine Möglichkeit beim Login die Sprache auszuwählen, ohne den NNLI-Bereich zu aktualisieren. Jemand ne Idee?

  • Signup: Domains im Signup nur bei ausgewählten Gruppen

    Im ACP kann man unter Einstellungen > Allgemein > Domains bereits einstellen, an welcher Stelle die eingetragenen Domains verfügbar sein sollen:

    Code
                prefs.common.php
            isset($_REQUEST['in_login']) ? 1 : 0,
            isset($_REQUEST['in_signup']) ? 1 : 0,
            isset($_REQUEST['in_aliases']) ? 1 : 0,

    Leider kann man nicht auswählen, in welcher Gruppe die Domain im Signup verfügbar sein sollen. Manche Domain möchte man aber nur Premiumnutzern zur Verfügung stellen, daher wäre eine solche Möglichkeit cool ( z.B. index.php?action=signup&paccPackage=4 ).

    Vorstellbar wäre sowas in der Art:

    Code
                isset($_REQUEST['in_groupsignup']) ? 1 : 0,

    Die Frage ist auch, ob man das (zusätzlich) ins PremiumPlugin integrieren muss. Eventuell können wir das ja gemeinsam weiterspinnen, falls jemand Interesse hat.

  • Alias-Adressen abhängig vom gewählten Paket deaktivieren

    Alias-Adressen biete ich nur in meinen kostenpflichtigen Tarifen an. Wenn der Kunde aber in den Standardtarif zurückgestuft wird (Laufzeit beendet, keine Laufzeitverlängerung), sind die Alias-Adressen zwar nicht mehr in den Einstellungen zu finden (Gruppeneinstellung: Aliase 0). Der Empfang und auch der Versand mit Alias-Adressen ist aber weiterhin möglich.

    Als erster Workaround wäre es wichtig, dass Alias-Adressen nicht mehr zum Versand genutzt werden können, sobald die Laufzeit abgelaufen und der Kunde in den Standardtarif zurückgestuft wurde. Besser wäre es natürlich, alle Funktionen die mit Alias-Adressen zusammenhängen zu blockieren bzw. zu sperren.

    M.E. ist die Alias-Verwaltung diesbezüglich nicht ganz zu Ende gedacht gewesen. Hat jemand ne Idee hierzu?

  • App für iOS / Android

    Dann fange ich mal mit einem Thema an:

    Android 13 - Dropdown zur Absenderauswahl funktioniert nicht mehr

    Unter Android 13 / SDK 33 lässt sich das Dropdown zur Absenderauswahl im Menü E-Mail Verfassen nicht mehr öffnen. Beim Tipp auf das Dropdown wird scheinbar der Layer aktiviert, aber das Dropdown nicht geöffnet und die Liste der Aliasadressen nicht angezeigt.

    Lösung:

    In die ../src/theme/variables.scss folgendes einfügen:

    Code
    /*
  Bugfix Android 33 popover not working
*/
ion-popover [popover]:not(:popover-open):not(dialog[open]) {
  display: contents;
}

    Danach muss die App neu erstellt werden.

  • App für iOS / Android

    Unter diesem Thema können Tipps zur Fehlerbehebung, zu selbst entwickelten Erweiterungen oder Anpassungen zur Smartphone-App von Martin / @möp gepostet werden. Da die App nicht unter einer öffentlichen Lizenz steht aber von jedem Lizenznehmer weiterentwickelt werden darf, freue ich mich auf einen konstruktiven und sachlichen Austausch.

    Danke an Sebijk, dass wir das Thema hier in diesem Board diskutieren dürfen.