Beiträge von ciwu

Mailitem im Ordner DvArchivePersonalDrafts erstellen.

Nach Zuweisen der Eigenschaften (kein Send... aufrufen):

// Delphi/Pascal
MailItem.Save(EmptyParam, DvMsgSelDirect);
S := MailItem.Fields.Item('FileName').Value;
S := 'tic://' + S + '.001';
ShellExecute(0, 'open', PChar(S), nil, nil, SW_SHOWNORMAL);

// Warten bis Fenster aufgeht, dann kann man Folgendes machen:
MailItem.Delete;

Danach kann Anwender Editieren usw. und Senden oder Abbrechen drücken.

Oh weh - sie werden es doch nicht wirklich wahr machen.

Zitat von Tobit

Rund alle zwei Wochen werden Verbesserungen, Korrekturen, Weiterentwicklungen und brandneue Features ausgerollt.

Das freut den Supporter.

Ist zwar alt, aber ggf. mal lesen:

bei Stackoverflow

Oder beim Programmausführen mit ProcMon von SysInternals protokollieren. Vielleicht taucht da ja ein "file not found" oder "access denied" auf.

Zeigt nicht TDQ die Anzahl Nachrichten (zumindest pro User) an?

DvApi32.Account accountl;
DvApi32.Archive archive;
DvApi32.DavidAPI davidapi = new DvApi32.DavidAPI();

account = davidapi.Logon("server", "", "", "", "", "NOAUTH");
archive = account.GetArchive("\\\\server\\david\\archive\\user\\12345678\\in");

Console.WriteLine(archive.MailItems.Count);

Das geht nach wie vor.

"DvISE Object API 1.0 Type Library" importiert?

Zwischenzeitlich Rollout 415 oder David-Client-Updates installiert?

Ansonsten: "Sicherheitssoftware" aktiv?

Oder mal VS 2022 probieren.

Bringt bei mir schon beim Kompilieren Fehler CS1752.

Der Interoptyp "DavidAPIClass" kann nicht eingebettet werden.

Wenn ich in Zeile 2 das "Class" weglasse, geht es.

So? FRITZ!fax für FRITZ!Box einrichten

Funktioniert bei mir mit aktuellem Windows 10.

Geht allerdings dann nur als lokaler Druckertreiber - hat mit Tobit (David/FaxWare) nichts zu tun.

Rückerstattung funktioniert ja laut dem, was bei Subject steht nicht.

Versuche bitte dann z.B. enthält "ckerstattung".

Leicht OT:

Weiß jemand, welche Features (außer o.g. Dateieigenschaften) am Zugriff auf die Freigabe hängen?

Also: was geht nicht, wenn nur Port 267 erreichbar ist (und 445 nicht)?

Ich denke nach

If oMsgItem.Type = DvEMailItem Then

könnte man

oMsgItem.Forward

aufrufen.

Hab's aber noch nicht getestet. Wenn mal viel Zeit ist...

Ausgelöst werden soll die ganze Aktion (Verschieben + Weiterleiten) aber von Hand, wenn man auf einer bestimmten E-Mail steht?

Könnte im David mit einem User-Script gehen, welches einen Button in die Leiste oben einblendet.

Siehe X:\DAVID\Code\scripts\COMMON.VBS usw.

Hier eine einfache Verteilung aller selektierten E-Mails im Eingangsordner an ein konkretes Archiv mit Rückfrage pro Eintrag.

Das Objekt MailItem müsste auch eine Methode "Forward" haben, wenn ich mich recht entsinne.

Einfach in Dvapi32.chm nachsehen.

Sub Initialize(oInfoCenter, key)
  Set oBar = oInfoCenter.GetCommandBar("Main/Global")
  oBar.Insert -1, "@support", key, "briefcase.ico", "OnSuppPressMain", true
End Sub

Sub OnSuppPressMain(oInfoCenter, oContent)

  On Error Resume Next

  Set oTree = oInfoCenter.ArchiveTree
  Set oArchive = oTree.SelectedArchive

  if oArchive.Displayname = "In" then
    Set oEntryList   = oInfoCenter.EntryList
    Set oSelection   = oEntryList.Selection
    Set oArchiveDest = oInfoCenter.Account.ArchiveFromID("\\Servername\David\Archive\0")

    for each oItem in oSelection

      Set oMsgItem = oItem.GetInterface2

      If oMsgItem.Type = DvEMailItem Then

        Dim iResult
        iResult = oInfoCenter.Msgbox("E-Mail mit Betreff" & vbCrlf & vbCrlf & oMsgItem.Subject & vbCrlf & vbCrlf & "an Support verteilen?", "YesNoQuestion")

        If iResult = DvMbYes Then
          oMsgItem.Move oArchiveDest, true
        end if

      end if
    Next

    'oInfoCenter.Msgbox "OK"
  else
    'oInfoCenter.Msgbox "--"
    dim x
    x = oInfoCenter.MsgBox("Eingangsordner ist nicht aktiv!", 48)
  end if

  If err Then
    Dim y
    y = oInfoCenter.MsgBox(Err.Description, 16)
  end if
End Sub

Gelöst!

Scheint mit den alten SIDs zusammengehangen haben.

Nach Korrektur der (ab Rollout 407 im System-Protokoll aufgelisteten) alten SIDs verbindet sich die Smart-Client-App nach Serverneustart ohne o.g. Workaround.

Die im Nutzereigenschaften-Dialog angezeigte SID änderte sich übrigens nicht nach Neuzuweisung des Windows-Accounts. Die alte SID wurde wohl intern irgendwo noch geführt, ohne dass man dies mitbekam - deshalb wohl nun auch die Anzeige im Log.

Sieht man die mehrfachen Eingänge auch mehrfach im Eingangsprotokoll im David-Admin?

Dann hätte diese ja der Grabbing-Server tatsächlich mehrmals abgeholt.

Muss ja erst abholen und dann den DELE-Befehl senden. Wenn das Abholen gelingt, das DELE aber im Nirvana verschwindet, ist die Mail beim nächsten LIST/RETR wieder dabei.

Steht die E-Mail nur einmal im Protokoll, dann fällt mir auch nichts weiter ein.

Verteilregeln mit Zirkelbezug?

Es geht um eingehende Mails, die per POP3 (von wo?) abgeholt werden?

Sind denn die Duplikate vollkommen identisch? Als EML speichern (z.B. per Drag&Drop zum Explorer) und alle Kopfeinträge vergleichen.

Dass eXpurgate irgendwie reinfunkt kann ausgeschlossen werden?

Die Prüfer sollen mehrere David-Nutzer sein?

Sonst könnten ja die wartenden E-Mails im Kontext des Prüfers in den Transit gestellt werden.

Die Transit-Mail liegt im Out-Verzeichnis des Absenders.

Wenn dort Schreibzugriff für die Prüfer existiert: soweit gut.

Ich vermute in den "Pseudo-Ordner" Transit des aktuellen Nutzer kommt es nur mit der von Dir erwähnten Option.

Möglicherweise könnten auf das Unterverzeichnis des Service-Nutzers unterhalb "X:\DAVID\Archive" mehr NTFS-Rechte gesetzt werden, so dass dieser im Client im Baum unter "Servername\Users" auftaucht, wo man sich dann zu "Out" durchhangeln könnte.

Direkte Manipulationen an NTFS-Berechtigungen würde ich allerdings nur als "letztes Mittel der Gewaltanwendung" ansehen und dann auch nur nach vorheriger ausgiebiger Prüfung in einer Testumgebung.

Nun ja, Windows-Updates gibt es schon ewig jeden Monat.

Ja, auch da wird es manchmal schlimmer.

Mein Kommentar bezog sich auf die hier geäußerten Unmut über zu niedrige Updatefrequenz in letzter Zeit.

Und zu Beginn der Rollouts (oder Sitecare?) stand da wirklich - nach meiner Erinnerung - "aller 14 Tage" und "überraschen" und so etwas macht mir Angst.

Die Anwender sind mit monatlichen Designänderungen usw. überfordert.

Ich hab nichts gegen monatliche Bug-Fixes - eine Art "rolling release" ohne Trennung von Bug-Fix, neuen Features (mag noch gehen) und GUI- oder Verhaltensänderungen in einem Paket generiert nur unnötigen Supportaufwand - und zwar nicht bei Tobit.

Dass die Meldung der Altlasten-SID sinnvoll ist und zur Lösung meines Smart-Client-Problems führte, habe ich ja bereits geschrieben.

Wenn mir David nicht (mehr) gefallen würde, würden wir es nicht (seit Faxware unter Novell) heute immer noch einsetzten.

Da war scheinbar doch vor einigen Jahren mal ein Neuaufsetzen des Servers.

Die gemeldeten SID waren nicht alle Nutzer sondern die "alten". Die nach dem Umzug neu angelegten Accounts wurden nicht bemängelt.

Habe über den Drei-Punkte-Knopf die Nutzernamen erneut ausgewählt, angezeigte SID änderte sich nicht. Beim nächsten Neustart kamen aber keine SID-Meldungen mehr.

Außerdem scheint das auch die Ursache für meine Probleme mit dem smart client gewesen zu sein.

siehe dort

Changelog sagt:

Der Service Layer prüft nun beim Start ob die bei den david Benutzern gespeicherte Windows SID mit deren wirklicher SID übereinstimmt. Im Fehlerfall wird ein Eintrag im david Ereignis Ordner mit Hinweisen zur Korrektur erstellt. Bei einer falschen SID kann es z.B. zu Problemen im smart client kommen. Weiterhin konnte es in einer Domäne zu einem Fehlverhalten kommen, wenn ein david User mit falscher SID dem richtigen Windows User zugewiesen werden sollte, in dem Fall konnte die SID weiterhin falsch bleiben.

Die Nutzer wurden aber nie geändert.

Was nun? Über den Drei-Punkte-Knopf alle noch einmal zuordnen?

Hoffen, das dann nicht irgendwelche NTFS-ACL verfriemelt werden?

Gerade eingespielt: "Unknown SID" bei allen Nutzern (in "DAVID/System/David/Events") und im Post-Eingang vom Admin (gesendet von David Service Layer).

Hab die Einträge doppelt, da ich nach Rollout-Install Server neugestartet habe. Scheinen also bei jedem Start vom Service-Layer erzeugt zu werden.

Client auf Client-PC zeigt jedoch Mails bei Normal-Nutzer an und bringt auch keine Fehlermeldungen.

Senden und Empfangen geht auch.

Das "Otherwise delete and, if necessary, recreate this david user." ermuntert ungemein.

Soeben Service-Layer nochmal neugestartet. Wieder x mal "Unknown SID".

Wer hatte hier vor Kurzem noch nach mehr Rollouts gefragt?

Stand nicht in der Mail, als das mit den "Rollouts" los ging, so etwas wie "Lassen Sie sich aller 14 Tage mit/von neuen Features überraschen"?

Wenn die Kommunikation mit dem Teil funktioniert (zeigen ja die Antworten auf die AT-Befehle), würde ich auch eher GSM-Netz-Probleme vermuten.

Die bei SO genannten Gründe für Error 500 wurden sicher bereits geprüft?

• No or weak network coverage - move modem somewhere with a better signal reception
• Insufficient SIM card credit - charge SIM
• International phone number required - send recipient's number to modem with country code