Das Notes Forum

Domino 9 und frühere Versionen => ND9: Administration & Userprobleme => Thema gestartet von: smokyly am 13.08.13 - 08:29:21

Titel: zweites "persönliches" Adressbuch im Traveler
Beitrag von: smokyly am 13.08.13 - 08:29:21
Hallo,

seit Freitag haben wir nun auch einen Traveler, welcher Zug um Zug den Blackberry Enterprise ablösen soll.
Soweit so gut, prinzipiell funktioniert fast alles, nur bei einer Geschichte stehen wir völlig im Regen:

Im BES konnte man zum persönlichen Adressbuch noch ein weiteres übergeben, in dem man auch dem BB dann suchen konnte.
Dieses Adressbuch ist im Grunde nur ein Telefonverzeichnis der Firma und beinhaltet keine adressierbaren Informationen, ist also für Mail völlig nebensächlich.

Gibt es beim Traveler auch eine Möglichkeit, dieses Adressbuch auf dem Endgerät zur Verfügung zu stellen?

Beste Grüße
Titel: Re: zweites "persönliches" Adressbuch im Traveler
Beitrag von: Driri am 13.08.13 - 08:33:11
Nein.

Die persönlichen Kontakte aus dem Mailfile des Users werden synchronisiert.

Ansonsten kann man höchstens am Server über Directory Assistance zusätzliche Directories einbinden. Die sind dann aber für alle Benutzer durchsuchbar.

Zusätzliche, persönliche Adressbücher lassen sich nicht einbinden.
Titel: Re: zweites "persönliches" Adressbuch im Traveler
Beitrag von: smokyly am 13.08.13 - 08:38:19
Vielen Dank,

dachte ich mir schon. DA scheidet leider aus.

Dann werde ich mir mal beim Chef heiße Ohren holen müssen...

Titel: Re: zweites "persönliches" Adressbuch im Traveler
Beitrag von: schroederk am 14.08.13 - 08:11:47
Es gibt aber einen "Trick" um weitere Adressbücher über Traveler auf das Smartphone zu synchronisieren.

Für einen User gibt es nur sein eigenes persönliches Adressbuch, das auf das Gerät synchronisiert wird, das Globale Adressbuch ist nur online durchsuchbar.
Es gibt aber die Möglichkeit mehrere User auf ein Gerät einzurichten.

Wir haben einen Dummy-User erstellt, der in seinem persönlichen Adressbuch immer eine Kopie des Globalen Adressbuchs beinhaltet.
Jeder der ein synchronisiertes Globales Adressbuch haben möchte, bekommt dann zusätzlich zu seinem User auch noch den Dummy-User angelegt.

Nachteil: Es muss dafür Sorge getragen werden, dass Änderungen nicht möglich sind, nicht übernommen oder wieder überschrieben werden.
Für jedes weitere Adressbuch, jeweils ein weiterer Drummy-User.


Titel: Re: zweites "persönliches" Adressbuch im Traveler
Beitrag von: umi am 14.08.13 - 08:51:16
@Schroederk Das funktioniert soweit ich weiss nur mit iPhone oder ?
Titel: Re: zweites "persönliches" Adressbuch im Traveler
Beitrag von: schroederk am 14.08.13 - 16:53:08
Ehrlich gesagt habe ich es auf anderen Geräten bisher nicht testen können, da wir wir ausschließlich iPhones verwenden.
Auf dem iPhone wird allerdings auch keine Anwendung installiert, wie es bspw. bei Android-Geräten der Fall ist.
Sollte sich auf einem Android eine Anwendung mehrmals installieren lassen, dürfte es auch auf solchen Geräten funktionieren.
Nach einer schnellen Suche bei Google sollte es funktionieren und damit stehen die Chancen gut, dass zusätzliche Adressbücher
auch auf dem Android installiert werden können.
Titel: Re: zweites "persönliches" Adressbuch im Traveler
Beitrag von: ascabg am 14.08.13 - 17:02:36
Hallo,

Zitat
... Sollte sich auf einem Android eine Anwendung mehrmals installieren lassen ...
Nein.
Der Traveler-Client laesst sich nur einmal installieren.


Andreas
Titel: Re: zweites "persönliches" Adressbuch im Traveler
Beitrag von: schroederk am 15.08.13 - 09:34:14
Ich würd das nicht so pauschal verneinen, die Frage ist eher, inwieweit das rechtlich in Ordnung ist, wenn man mit einem speziellen Programm (Apktool) die AndroidManifest.xml der App bearbeitet und damit den Paketnamen ändert.
Da die App kostenlos ist, vermute ich, dass es keinen Kläger gibt, wenn die App mehrfach installiert wird.

Ohne Manipulation des Installationspakets für Android gehts in der Tat nicht. Übrigens bei keiner App.
Titel: Re: zweites "persönliches" Adressbuch im Traveler
Beitrag von: Driri am 15.08.13 - 10:20:16
Das dürfte dann aber auch unsupported sein. Sprich, im Problemfall wird IBM für so ein Konstrukt mit Sicherheit keine Unterstützung gewähren.