Przejdź do treści

Neos IMAP

Instalacja

API zostało wydane po raz pierwszy, nie licząc prototypu w neosie w wersji 1.1.RC7. Źródła są na gitlabie w projekcie DRO/Neos. Wersja już skompilowana jest na apocu w release.candidate. Okna klienta pocztowego znajdują się w projekcie SENTE, który można znaleźć na gitlabie w repozytorium DRO/S4 np. na branchu 4.0.1. Okna oraz API wymagają zmian bazodanowych, które można znaleźć w katalogu /dbscripts na DRO/S4 np. na wspomnianym branchu.

Konfiguracja

Klient aktualnie działa tylko pod VCL wymaga konfiguracji skrzynek pocztowych bezpośrednio z poziomu okna Poczty. Nowy przycisk powinien być od razu dostępny we wstążce w Workspace. Jeśli nie jest widoczny, należy danemu użytkownikowi nadać prawa do modułu EML. Istnieje niewielka sekcja w Plik esystem.smd, która określa parametry autosychronizacji poczty.

Konfiguracja dla osobnej bazy UTF8 z mailami

Podsystem IMAP od wersji 1.1.RC8 ma możliwość działania z zewnętrzną bazą danych, która przechowuje tylko wybrane dane maila (np. treść, tytuł, adresatów), które wymagają przechowywania w UTF8. W tym celu należy uaktualnić treści funkcji bazodanowych imapa w bazie głownej esystem oraz utworzyć drugą bazę danych. Przykładowy skrypt tworzący drugą bazę znajduje się w katalogu dbscripts/emailwiaddb.sql. Oprócz tego należy odpowiednio skonfigurować pliki .smd i .app.

Budowa podsystemu imap

  • MAILBOXES - konfiguracja skrzynek
  • DEFFOLD - lista folderów skrzynek, okno BROWSE to główne okno klienta pocztowego, obsługuje prawa nadawane folderom
  • EMAILWIAD - obiekt emaili, zawiera formę BROWSE z listą maili dla wybranego folderu (osadzona w DEFFOLD.BROWSE) oraz okna dla oglądania szczegółów maila oraz edycji nowej wiadomości
  • EMAILADR, EMAILZAL - pomocnicze obiekty do edycji adresatów wiadomości i z listą załączników

Większość akcji w DEFFOLD i EMAILWIAD dotyczących synchronizacji, edycji, przesuwania wiadomości i folderów wywołuje odpowiednie funkcje znajdujące się w obiekcie Neos.Core.ImapAPI. Funkcje te działają w taki sposób, że najpierw łączą się z serwerem IMAP/SMTP i wykonują operacje na serwerze, a jeżeli nie zostanie rzucony wyjątek aktualizują struktury w bazie danych aby utrzymać spójność. Obiekt ImapAPI komunikuje się z bazą danych za pomocą obiektu Storage implementującego interfejs IImapStorage, istnieje możliwość zmiany implementacji tych funkcji względem standardu. Duża część metod obiektu Storage wykonuje na bazie danych odpowiednie procedury.

Standardowo wszystkie te obiekty działają na bazie domyślnej dla projektu SENTE. To znaczy, że klient VCL wyświetlając z nich dane czyta/zapisuje do bazy domyślnej oraz ImapAPI czyta/zapisuje do bazy domyślnej.

OAuth2 - Open Authentication 2

Od wersji 6.0.28 w oknie konfiguracji skrzynki mailowej w zakładce IMAP mamy do wyboru 2 opcje logowania. Od wersji 6.3.13 analogiczna konfiguracja dostępna jest również dla SMTP.

  • Login i hasło - domyślny sposób logowania
  • OAuth2

Aby poprawnie zalogować się za pomocą drugiego sposobu wymagane będą informacje:

  • Application (Client) Id
  • Tenant (Directory) Id
  • Client Secret
  • Scopes - dla Microsoft 365: https://outlook.office365.com/.default
  • Host
  • Port
  • SSL/TLS
  • Adres email

Wszystkie powyższe informacje muszą zostać podane w oknie konfiguracji skrzynki IMAP/SMTP.

WAŻNE (Microsoft 365): Konfiguracja OAuth2 wymaga rejestracji Service Principal w Exchange Online oraz nadania uprawnień IMAP.AccessAsApp / SMTP.SendAsApp.

Przykładowa konfiguracja dla platformy Office365: Instrukcja konfiguracji (Limilabs)

Dostosowanie osobnej bazy UTF8 z mailami do własnych potrzeb

Obsługa drugiej bazy danych na maile działa w ten sposób, że obiekt EMAILWIAD za pomocą metody GetDatabase posiada możliwość zwrócenia, że dane będzie czerpał z bazy o innym aliasie. Metoda została tak napisana, aby zwracała alias podany jako EmailContentDatabaseAlias, jeżeli różni się on od EmailMetadataDatabaseAlias. W ten sposób w warstwie prezentacji dane o skrzynkach, folderach, adresach, innymi słowy metadane są czytane z bazy głównej, a same dane wiadomości są pobierane z bazy o innym aliasie (który może mieć wtedy ustawione połączenie UTF8).

Utworzona przykładowa druga baza danych zawiera pewną ilość pól które przechowują dane w UTF, ale które pola są w taki sposób przechowywane i na której bazie można dostosować do swoich potrzeb. Silnik ImapAPI w takiej konfiguracji działa w ten sposób, że wszystkie procedury które dotykają danych trzymanych w drugiej bazie są uruchamiane dwa razy, raz na bazie głownej a raz na bazie wiadomości. Dzięki czemu można wygodnie sterować tym jakie dane trafiają do której bazy.

Przykładowo, jeżeli chcemy trzymać treść wiadomości tylko w drugiej bazie, możemy usunąć kolumnę FULLHTMLBODY z tabeli EMAILWIAD w bazie ESYSTEM, oraz zmodyfikować procedury EMAILWIAD_GET i inne tak, aby zwracały tam zawsze NULL, natomiast pole to istnieje w drugiej bazie i tam procedura EMAILWIAD_GET będzie je poprawnie zwracać. Jeżeli np. podejmiemy decyzję aby pole DOKOGO trzymać na bazie głownej a nie w osobnej, tak jak jest to robione w przykładowej drugiej bazie, wystarczy odpowiednio zmodyfikować procedury tego pola używające na obydwu bazach. Wybrane rozwiazanie wymaga jednak, aby sygnatury metod były na obydwu bazach takie same, zmianie mogą ulegać jedynie ich implementacje.

Ponieważ silnik wykonuje niezbędne zapytania dwukrotnie, raz dla bazy głownej a raz dla bazy z wiadomościami, do bazy głownej mogą iść zapytania tylko po WIN1250, a do drugiej bazy tylko UTF8.

Ustawienie własnego szablonu odpowiedzi

Od wersji NEOSa 5.0 (teneum) istnieje możliwość ustawienia własnego szablonu @ który jest używany podczas generowania odpowiedzi. Od wersji 5.2 można również ustawić własny szablon na przekazanie @ (forward). Aby przeciążyć szablon dla forward\'a należy utworzyć plik o nazwie forwardTemmplate.txt. Aby tego dokonać wystarczy utworzyć następujący plik w ścieżce: "neos\templates\imap\replyTemplate.txt" Przykład pliku:

<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>[Subject]</title>
</head>
<body>
[Html]
<br /><br />
On [Original.Date] [Original.Sender.Name] wrote:
<blockquote style="margin-left: 1em; padding-left: 1em; border-left: 1px #ccc solid;">
    [QuoteHtml]
</blockquote>
</body>
</html>

Ważne!

Serwer NEOS jednorazowo pobierze zawartość pliku i zapisze go w pamięci. Po każdej aktualizacji pliku należy zrestartować serwer w celu pobrania nowej zawartości.

Instrukcja użycia

  1. Utworzyć foldery w NEOSie (obok exe'ca): "template\imap"
  2. W folderze imap tworzymy plik o nazwie: "replyTemplate.txt", "forwardTemplate.txt". (wielkość liter ma znaczenie!!!)
  3. W pliku przekopiować w/w szablon (lub utworzyć własny) i zapisać z kodowaniem UTF bez BOM.
  4. Uruchomić NEOSa. Po kliknięciu odpowiedz lub przekaż dalej NOES odczyta szablon z pliku i wygeneruje odpowiedź.

Własny szablon html - mail do resetowania hasła WWW

Od wersji Neos 6.0.10 istnieje możliwość ustawienia własnego szablonu html dla maila, wysyłanego podczas resetowania hasła na panelu www. Można również podpiąć kilka szablonów w różnych językach.

Aby wysyłać własny szablon należy:

  1. Utworzyć foldery w NEOSie (obok exe'ca): template\imap\changePassword.
  2. Utworzyć tyle podfolderów, ilu używamy języków np. template\imap\changePassword\pl, template\imap\changePassword\en.
  3. W każdym z podfolderów changePassword\ tworzymy plik o nazwie: changePasswordTemplate.html.
  4. W plikach changePasswordTemplate.html utworzyć własne szablony html.
  5. WAŻNE!!! W szablonie changePasswordTemplate.html musi znajdować się fragment: %VAL1%. W tym miejscu Neos wstawi wygenerowany link do zmiany hasła. Bez tego fragmentu w mailu nie pojawi się link.

Wysyłanie maili spod Schedulera

Od wersji Neos 6.1.XX istnieje mozliwość wykorzystania mechanizmu IMAP do wysyłania maili wykorzystując do tego Schedulera. Należy przy tym pamiętać, aby do maila, z którego będziemy korzystać był przypisany operator!