Beiträge von SLM

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.

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.

Moin Denny Die Nachricht hab ich (noch) nicht bekommen. Welche App-Version verwendest du?

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

Sebijk Wäre es eventuell möglich das Update ohne die Update-Routine, dann aber manuell durchzuführen? Bei manchen Installationen wäre das m.E. die sinnvollere Variante, da man dann die einzelnen Schritte selbst in der Hand hat.

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.

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?

Jetzt komm ich wieder um die Ecke und nerve noch ein wenig mit diesem Thema: https://board.b1gmail.com/threads/dkim.16045/page-3

> (Noch) Fehlende Quarantäne-Funktion im Zusammenhang mit DKIM / DMARC.

Dann wäre das ganze rund und ein Update würde sich eher lohnen.

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

            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:

            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 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?

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:

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

Danach muss die App neu erstellt werden.

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.

Wir haben viele internationale User, daher ist die Angabe der internationalen Vorwahl bei der Handynummerverifizierung zwingend notwendig.

Alle Vorwahlen dieser Erde in das Gruppenfeld SMS-Vorwahlen einzutragen ist auch nicht zielführend.

Leider vergessen viele Nutzer die führenden Nullen anzugeben oder checken einfach nicht, wie man seine Handynummer korrekt im internationalen Format angibt. Die Folge: SMS die zur Verifizierung versendet werden (und Kosten verursachen), aber im Nirvana landen. Und wenn der Kunde mal die SMS-Passwortanforderung nutzt, findet das System die Handynummer logischerweise nicht.

Da das Feld mail2sms_nummer über die prefs.php im Template generiert wird, kann man das Feld selbst auch nicht mit einer Regex ergänzen. Hat jemand ne Idee? Mit schwebt vor, dass die führenden Nullen bereits angezeigt werden.

prefs.contact.tpl:

{if $f_mail2sms_nummer!="n"}<tr>
            <td class="listTableLeft">{if $f_mail2sms_nummer=="p"}*{/if} {lng p="mobile"}:</td>
            <td class="listTableRight">    
                {mobileNr name="mail2sms_nummer" value=$mail2sms_nummer size="280px"}
            </td>
        </tr>
{/if}

OK, trotzdem vielen Dank. Darf man hier dann trotzdem ein Thema darüber beginnen, z.B. im AddON-Forum oder ist das dann auch nicht gewünscht? Geht ja nur um den Austausch darüber.

Die Native App von @möp / Martin darf jeder Lizenznehmer für sich weiterentwickeln, nur eben nicht verkaufen. Es wäre toll wenn es möglich wäre einen eigenen Bereich (statt einem Thread) außerhalb des AddOn-Bereiches hier im Forum bekommen zu können.

Man könnte sich mit Tipps & Tricks zu Ionic-Framework, Angular, Cordova etc. oder bei der Fehlerbehebung oder Weiterentwicklung gegenseitig helfen.

Merci

Gibt es Bestrebungen die Toolbox zu aktualisieren, damit sie auch wieder auf neueren macOS-Systemen bzw. auch auf neueren Windows-Systemen ohne Fehlermeldung lauffähig ist? Patrick hat eine GPL-Version unter https://github.com/b1gMail/BMToolbox/ veröffentlicht.

Hat die schon mal jemand getestet? Wenn ja, gibt es hierfür evtl. eine Anleitung?

Zitat von Sebijk

hab den auszug erhalten. Wenn also nach dem TLS direkt die Verbindung getrennt wird, dann liegt es daran dass die DANE Validierung fehlschlägt.

Interessant. DANE hat nicht jeder aktiviert (auf meinem System zumindest nicht), hoffentlich unterscheidet MS-365 das auch.

Aktiviert (nur Domain) habe ich auf meinem System auch eingestellt. Hin und wieder bekomme ich ebenfalls Mails bezügl. des Topics. In vielen Fällen stellt sich raus, dass die Absender Microsoft Exchange-Systeme verwenden oder sehr verschachtelte Domain- und Mailserverkonfigurationen. Meist sind deren Admins zu faul den EHLO/HELO-Eintrag richtig zu setzen

ManDal Anregung: Für eingehende Tickets das Markieren als "Spam" kennzeichnen ermöglichen.

Es häufen sich Tickets, die entweder über das Formular oder per Mail eingehen und durch den Spamfilter gerasselt sind. Wenn man eine solche Mail als Spam im Nachhinein deklarieren, muss man in das jeweilige Postfach und dort aus dem Ticketarchiv die Mail als Spam markieren. Eine Option wäre es, wenn man solch eine Nachricht als Spam deklarieren könnte. Funktion könnte ähnlich oder analog "Absender blocken und löschen" ausgeführt sein.

Zitat von ManDal

Naja ich habe einen 49" Bildschirm da kann alles etwas kleiner sein als sonst wo und die Schriftart sollte gleichgross sein wie im neuen ACP.

49 Zoll sind natürlich ein Argument Ich arbeite prinzipiell mit Mindestanforderungen, dann kann man eher darauf schließen, dass auch es auf HighEndsystemen funktioniert. Umgekehrt wird das eher schwierig.

Btw.: Die Top 5-Bildschirmauflösungen von Nutzern laut meinen Aufzeichnungen:

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

Mir persönlich ist die Schriftgröße im neuen ACP aktuell auch zu klein, aber da spielt es nicht die gleiche Rolle wie im UCP. Aber man kann die Schriftgröße ja später jeder selbst wieder anpassen.

Wenn man dich in irgendeiner Weise unterstützen kann, sag Bescheid. Denke wenn die Grundstruktur steht, ist das Anpassen der restlichen Templates nicht mehr so kompliziert und die Entwicklung könnte durch Teamwork beschleunigt werden.