Beiträge von SLM

    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:

    Code
    {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}


    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 :)

    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.

    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.

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

    Hatte wieder ein paar Minuten Zeit mich um b1gMail zu kümmern und so könnte in Zukunft der LI bereich in b1gMail ausschauen.

    Es ist alles noch nicht pefekt und auch die Top Navigation gefällt mir noch nicht zu 100% aber so als erster einblick...

    Danke für den Anfang :)

    Könnten wir uns eventuell auf eine größere Schriftart einigen, z.B. min. 14px. Eigentlich ist im UI-Design mittlerweile schon 16px Standard, um auch auf mobilen Geräten gut bedienbar und lesbar zu sein. Vergleich bitte mal mit Proton oder Tutanota. Oder sieht das hier nur so klein aus?

    Aktuell kann man Gutscheine so konfigurieren, dass man bei Einlösung des Gutscheins in eine bestimmte Gruppe verschoben wird.

    Das Problem ist, dass dies nicht gleichzeitig für die Gruppen im PremiumPlugin gilt.

    Für Aktionen (z.B. Gutscheincode "XY2023" = 1 Jahr gratis Gruppe XXX) kann man Gutscheine also nicht verwenden. Man müsste bei der Einlösung des Codes dafür sorgen, dass der Account gleichzeitig in die Premiumgruppe verschoben und ein Ablaufdatum gesetzt wird, damit die Erinnerungsmail greift.

    Hat jemand eine Idee dafür?

    Wenn die erste Abo-Ablauf-Benachrichtigungsmail übersehen wird (z.B. wegen Urlaub) kann es für den Kunden hilfreichs ein, dass man ihn nochmal dran erinnert. Deshalb wäre es super wenn man zusätzlich eine 2. Erinnerungsmail nachsenden könnte.

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


    Vorschlag:

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

    ManDal Mir ist heute folgendes aufgefallen:

    Bei der Freigabe eines Datenschutz-Reports wird für die Generierung des Reports immer immer die Sprache verwendet, die im ACP eingestellt ist. Der Report müsste idealerweise aber in der Sprache erstellt werden, die der User in seinen Einstellungen im UCP gewählt hat. Das gleiche gilt auch für den AV-Vertrag.

    Den Beitrag habe ich in diesem Forum gepostet da es alle Plugins betrifft die Daten aus der DB verwenden. Beispielhaft nenne ich hier nur mal eines.

    Zum Thema: Aktuell übersetze ich gerade meine Sprachdateien und Plugins in weitere Sprachen. Das funktioniert mittlerweile mit diversen AI-Tools ganz gut. Ob das immer richtig und grammatikalisch richtig ist, wird man sehen :)

    Alle aktuellen Plugins sind i.d.R. in Deutsch und zumindest in englischer Sprache übersetzt, die zugehörigen Texte in der Datenbank ebenfalls. Nun tritt aber folgendes Problem auf: Hat man im UCP eine andere Sprache gewählt (z.B. französisch) und der Inhaltstext, der in der Datenbank dafür vorgesehen ist, ist noch nicht übersetzt, werden die Inhaltestexte nicht angezeigt.

    Hier wäre es m.E. sinnvoll, dass das System oder das Plugin entweder auf eine Standardsprache zurückgreift. Ein Beispiel hierfür wäre z.B. das Supportsystem-Plugin mit den FAQ (die ja je nach Sprache in der DB gespeichert werden) von dir ManDal.

    Deutsch:

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

    Französisch:

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

    Ich hoffe ich hab mich einigermaßen verständlich ausgedrückt :)

    ManDal Der Newsletterversand funktioniert nicht. Zu allererst werden keine Empfänger ermittelt.

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

    Im nächsten Step bitte auch mal die Aktualisierungsanzeige für den Versand prüfen.

    Wäre jetzt in dem falle da ich Tabler.io verwende für ACP, NLI und LI praktisch, man verliert aber die Individualität mit den verschiedenen Templates.

    Daher sollen die Daten direkt zum Template und nicht ausserhalb...

    Kleiner Nachtrag, bei einem Update muss dann auch immer alles komplett durchgetestet werden was dann auch immer darauf zurückgreift.

    Wäre es zumindest möglich, alle Verweise, Links etc. immer als vollständige URL auszuführen? Damit könnte dann jeder selbst entscheiden, wie er seine Struktur aufbaut - zumindest als Option wäre das sinnvoll.

    Beispiel aus der common.js / common.uncompressed.js:

    Alt:

    MakeXMLRequest('start.php?action=getNotificationCount&sid='+currentSID, function(e)

    Neu:

    MakeXMLRequest('+selfurl+start.php?action=getNotificationCount&sid='+currentSID, function(e)

    Ist eine variante nur schwirrt dann wieder Code rum der einem später das leben schwer macht...

    Aber ja soll jeder selber wissen und das ACP ist ja noch nicht offiziell im OSS Repo integriert...

    -> Evtl. baue ich den bereich noch um das er kompatibler wird mit Bootstrap3 oder schlicht einen Switch mit einbauen der prüft welches Template geladen ist.

    Alles gut. Ich möchte eben beide Varianten nutzen, auch um das Tabler-Template kennenzulernen. Hab ja eh noch mit die reguläre 7.4er Version in Produktion. Wenn jemand ne ähnliche Konfiguration hat kann er es ja nutzen, ist ja kein muss ;)

    Bootstrap 5 bringt bei meinem /li-Template leider einiges durcheinander. Ich hab das jetzt temporär anders gelöst und eine neue Klasse in die serverlib/template.class.php integriert:

    Zusätzlich muss man die Klasse noch registrieren:

    In den jeweiligen li- und plugins/templates/ - Dateien ersetzt man dann folgendes:

    Code
    {progressbar 
    
    mit 
    
    {progressbarOld

    Dann kann man Tabler.io + das reguläre b1g-Template gleichzeitig verwenden.

    Wird dann irgendwann auf das neue li-Template umgestellt ist man schon vorbereitet.

    Frage bzw. eine Bitte. Ich verwende das Branding-Plugin um Inhalte für unterscheidliche Domains bereitzustellen. Das Problem mit dieser Methode ist, dass die Style-Anweisungen, JS-Dateien etc. mehrfach im Ordner /templates/meintemplate liegen. Dabei bleibt das Grunddesign immer gleich, lediglich Grafiken, Angebot und Inhaltstexte sind z.B. sprachlich angepasst.

    Könnte man die grundlegenden Style- und Funktionsdateien (css + js) in ein übergeordnetes Verzeichnis legen? Beispiel:

    root

    root/assets/css/

    root/assets/js

    root/assets/images

    .

    root/templates/x1/li/

    root/templates/x1/nli/

    root/templates/x2/li/

    root/templates/x2/nli/

    ..

    Die Zentralisierung der Style-Aweisungen würde insgesamt weniger Pflegeaufwand und weniger Fehleranfälligkeit bedeuten.