Druckbare Version
Zum ersten, beim empfang steht bei An: der erste der Liste die man bei den Einheiten eingibt, nicht der eigentliche Empfänger. Wäre gut wenn man das ändern kann, wegen Datenschutz.
zum zweiten, werden nicht alle sonderzeichen übertragen somit leseprobleme im alarmtext der mail. >> fehlen z.b.
Wird daran gearbeitet?
Gruß
Punkt ein:
Wir überprüft. Eigentlich sind wir der Meinung, das dieser Fehler bereits behoben wurde (und zwar schon vor langer Zeit). Falls dass doch nicht der Fall gewesen sein sollte, werden wir dies ändern.
Punkt zwei:
Das ist kein Fehler unserer Software. > werden in Konsolenanwendungen unter Windows als Steuerzeichen verwendet (Ausgabe umleiten). Deswegen kommen die fälschlich bei firEmergency an.
"Punkt zwei:
Das ist kein Fehler unserer Software. > werden in Konsolenanwendungen unter Windows als Steuerzeichen verwendet (Ausgabe umleiten). Deswegen kommen die fälschlich bei firEmergency an. "
Kann man bzw ich was daran ändern dass > in den Text übernommen werden oder geht da nichts?
gruß, Frohe Weihnachten
Zitat:
Zitat von Schkeuderhans
Mit der Textersetzung im Alarmablauf durch "nichts" lassen.
Bitte was?
Wie soll das gehen?
------------------------------------------------------------------------
Im übersendeten Text der LST,
Ort>>Ort
In der Alarmierungsmail
OrtOrt
Wie kann ich das machen dass auch in der Alarmierungs email
Ort>>Ort
wieder Steht?
MFG
Achso, hab ich dann wohl falsch verstanden. dachte du möchtest die steuerzeichen löschen. bei mir kommen die nähmlich bei bosmon immer mit =)
Werden die beiden Orte als Parameter übergeben?
Wenn ja dann kannst du die beiden Orte als Parameter setzen und die >> als Fixtext.
Mache das mit FMS32 da kommen die auch noch mit erst der firemergency Server übernimmt die nicht. Der komplette meldungugstext ist nur ein parameter, daher wird das mit fixtext nichts.
Hast du denn bei der Übergabe wirklich Ort>>Musterstadt oder Musterstadt>>Ortsteil klein Musterstadt ? Weil sonst könnte man ja mal mit Ersetzen versuchen...
Oder nimm ein anderes Zeichen:
Textersetzung:
>>;--
"
Im übersendeten Text der LST,
Ort>>Ort
In der Alarmierungsmail
Ort--Ort
"
Danke für die Hilfe firEmergency,
aber selbst die Textersetzung bringt keine besserung, immer noch das gleiche Ergebnis.
--------------------
Manuelle Einheiten Alarmierung Mit Text funktioniert:
Hilfeleistung Musterort, L1XXX Musterort>>Ortsteil
da funktioniert die Textersetztung,
aber der selbe Text mit BOStool an FMS gesendet:
Hilfeleistung Musterort, L1XXX MusterortOrtsteil
-----------------------
Der gleiche test mit Alarmierungstool ergebnis:
Hilfeleistung Musterort, L1XXX Musterort>>Ortsteil
greetz
Ok. Wir werden dass mal nachstellen und ausprobieren.
Danke euch, über eine Antwor würde ich mich freuen wenn Ihr was rausfindet. Bis dahin alles gute :-)
also übermittlung von >> sollte ab nächstem update gehen.
grundsätzlich:
wir bekommen die meldungen von bosmon per XML.
da sind < und > Steuerzeichen. man sollte also im allgemeinen diese zeichen eher nicht verwenden.
wir hams jetzt mal geändert dass es klappen dürfte.
Noch ein Zusatz:
Auch bei FMS32, RadioOperator und POC32 läuft alles über XML.
Da die Steuerzeichen wahrscheinlich von der Leitstelle kommt, lassen die sich wahrscheinlich nicht vermeiden...
Hallo zusammen,Zitat:
Zitat von Schkeuderhans
sollte dieses Problem eigentlich behoben sein? Bei mir ist es immer noch so!
Gruß Hausen
Ist aus folgendem Grund nicht "behoben":
Wir verschicken aus Zeitgründen nicht für jeden Empfänger eine Email, sondern nur eine einzige für alle.
Deswegen wird der Erste in der Liste als "AN" hinzugefügt und alle weiteren als "BCC".
Wenn wir jetzt keinen Empfänger als "AN" kennzeichnen würden (sondern alle als "BCC"), dann würde als Empfänger überhaupt nichts dastehen, was auch blöd ist.
Deswegen diese Entscheidung.
Was ihr machen könnt:
Legt euch eine Email-Adresse an ("feuerwehXY@gmail.com") und schickt alle Emails als erstes an diese Adresse.
Dann habt ihr Datenschutztechnisch nichts zu befürchten, da alle Empfänger nur diese eine "allgemeine" Email-Adresse sehen können.