[klugscheiss}
wenn du den events runterfährst, ist die events4 nicht mehr im Zugriff, dann geht auch der compact durch...
[/klugscheiss]
Beiträge von RockWilder
-
-
Aloha!
Hmm, heikle Sache das. Warum nimmste nicht den LEI? Oder wenigstens den DECS; der ist ja schon eingebaut. Bin mir zwar über den Funktionsumfang des DECS nicht ganz sicher, aber lieber erstmal da rein schauen, bevor du das Rad neu erfindest
greetz
RW -
Aloha!
Private Ordner denke ich sind in der Desktop.dsk gespeichert. Die kriegste IMHO nicht auf ne CD...
greetz
RW -
Aloha!
Ist denn bei den Design-Elementen der Haken gesetzt, dass die von einer Gestaltungsänderung unberührt bleiben sollen? Haste denn, alls du eine andere Schablone drüber gekippt hast, das Design kontrolliert? War da alles Mailkorb-artige weg? Haste die die Mailschablone mal angesehn, ob die überhaupt i.O. ist?
greetz
RW -
Sametime 6.5? Das muss ja ne ganz neue Version sein. Naja, wenn du auch Pre-Alpha-Releases nimmst... :lol:
j/k
-
Aloha!
Ist es auch nicht ;-P
Du kannst versuchen, die Sametime-eigenen DBs selbst zu erstellen (STAuthS, STAuthT, STLog, ..). Am einfachsten wird es wohl, wenn du eine "versaute" Inst. nimmst, die die Templates wegkopierst, den Domino neu aufsetzt, die DBs anlegst und versuchst den Sametime neu zu installieren.Aber ob das tut, weiß ich auch nicht. 6.5 ist auch nicht supportet. Die einzige Version ist 6.0.2CF1, wenn ich nicht irre. also, wenn es nicht ums Verrecken eine 6.5 sein muss, lass es lieber...
greetz
RW -
Tach nochmal!
Wenn das mit der leeren Schablone zu aufwendig wird, kipp halt irgendeine rüber. Adressbuch, Catalog, Log, dingsbumstralala. Irgendeine eben. Es geht nur darum, die alten Gestaltungselemente der Mail-DB rauszufeuern. Komplett. Mit alles und zwei Sosse. Das ist der einzige Sinn der Sache...
greetz
RW -
Aloha!
Jupp, das wird wohl etwas viel, aber wozu hat man Azubis
Nee, ernsthaft: was ACLs und so angeht, kann man über den Katalog viel sehen, aber wenn es dann und Leser-/Autorenfelder und Profildokumente geht, haste gelitten. Das packste nicht "zu Fuß"...
greetz
RW -
Aloha!
Kipp doch einfach mal leere Schablone über die DBs. Dann nochmal die Mailschablone drüber nageln und gut ist. Holzhammer-Methode aber funzt meist...
greetz
PM -
Moijns!
Also, ich persönlich würde ja die "MS Office Library" dafür nehmen. Zum Einen sieht die nicht so gemein aus (auch nicht wesentlich besser ;-)), zum anderen hast du durch die Response-To und Response-To-Response gleich eine Art Kategorisierung und Einrückung der Kapitel bzw. Unterkapitel.
Für die Änderungshysterie kannste 2 shared fields in die Forms Documents, Response und Response to Response einbauen:
ein mal für createdBy:
@If(@IsAvailable(@Created) & @IsAvailable($UpdatedBy);@Name([Abbreviate]; $UpdatedBy) + " am " + @Text(@Created);@Return(""))und für changedBy:
@If(@IsAvailable(@Created) & @IsAvailable($Revisions);@Name([Abbreviate]; $UpdatedBy) + " am " + @NewLine;@Return(""))Der Rest ist dann eignetlich nur noch Kosmetik... Auch wenn's keine Schönheit wird, es tut jedenfalls...
btw: die Farben umzubiegen wird etwas heftiger, weil durch die ganzen frames, framesets, pages und ähnlichem Quatsch es teilweise etwas unübersichtlich wird. Für mich jedenfalls.
Wer hat sich den Kohl eigentlich ausgedacht??greetz
RW -
Aloha!
Stell in der MailIn-DB im Kalenderprofil einfach einen User ein. Im Memo siehst du dann den eingestellten User und darunter "gesendet von: wer-auch-immer". Der Adressat sieht als Absender nur den MailIn-User.
greetz
RW -
Aloha!
Das geht doch rein logisch nicht. Der Server schreibt rein, wer als letztes dran rumgemacht hat. Wenn du in das Feld irgendwas reinschreibst, bist du der letzte Bearbeiter und damit in der TextList.
btw: einfach so was reinschreiben oder es zu löschen, funzt bei mir nicht. Das Feld scheint also gegen Manipulationen geschützt zu sein. Is ja auch der Witz der Sache...
greetz
RW -
Also doch...
Ok, Firma dankt
-
Aloha!
Mal ne Frage: ich habe einen Server, den ich von einer O in eine OU umziehen lassen will. Also von Srv/O nach Srv/OU/O.
Einen User kann ich ja beim Umbenennen in eine neue OU hängen. Wie krieg ich das am Einfachsten beim Server hin?
Oder muss ich einen neuen Serve rregistrieren und dem alten dann die Id unterschieben?
greetz
RW -
Aloha!
Doch, das tut definitiv auch beim 6er...
greetz
RW -
Aloha!
Tja, wie war das mit der Putze, die jeden Tag daher geht, den Stecker zieht, um den Staubsauger einzustöpseln?
Keine wirkliche Hilfe, ich weiß...
greetz
RW -
Aloha!
Versuchs mal im QueryOpen-Event der Form "Memo" mit
FIELD ReturnReceipt:=@DeleteFieldSollte helfen. Wenn nicht, schreibt einen Agent, der "Bei Eingang neuer Mail", das Feld löscht...
greetz
RW -
[edit]
sorry, double-post
[/edit] -
Aloha!
Du warst schon dicht dran: es reicht aber nicht aus, nur den ini-Eintrag umzubiegen, sondern musst ihm auch ne neue server-ini unterschieben. Von hinten durch die Brust ins Auge; klappt imemr wieder
greetz
RW -
Aloha!
Hmmm, hört sich an, als könnte das gesamte NAB mal eine Politur vertragen... Ich will mal beschreiben, wie wir das haben:
Die User U1 bis U(nn) sind in (genau einer) Abteilung A(nn). Übergeordnet sind die Einheiten E1 bis E(nn), wobei jede Einheit mindestens eine Abteilung beinhaltet und jede Abteilung Mitglied genau einer Einheit ist. Eine Einheit E(nn) ist Mitgleid genau eines Bereiches B(nn).
Wenn du dann eine Gruppe hast, die z.B. "Firma alle" heißt, kannst du alle Einheiten reinschreiben und hast plötzlich einen Verteiler, in dem alle MA über die Gruppenhierarchien verschachtelt sind.
Was die automatische Aktualisierung der User angeht: naja, beim Erstellen gibst du an, dass der User Heino Meier Mitglied der Abteilung XYZ wird und Lieschen Müller Mitglied der Abteilung ABC. Löschen tust du ja eh per AdminP; User fliegen automatisch raus.Dieses Konzept wird nicht durch User-definierte Gruppen aufgebrochen; die können definieren, was sie wollen. Hauptsache: beim Anlegen der User fügst du sie gleich einer der Organisationsgruppen hinzu und User haben nur Leserechte auf deine neuen Gruppen.
Sollte ein User aus z.B. der Buchhaltung in die Kantine zum Tellerabwaschen wechseln, hängst du ihn in den Abteilungsgruppen um, über die Verschachtelungen ist er dann gleich in einem neuen Bereich.
Vorteile:
1) erhebliche Erleichterung der Pflege von Zugehörigkeiten,
2) Abteilungs-/Bereichsrundmail haben automatisch einen richtigen Verteiler,
3) notfalls können diese Gruppen auch in ACLs verwendet werden, wenn klar ist, dass bestimmte DBs nur für bestimmte Abteilungen zugänglich sein sollenNachteile:
1) man muss sich bei der Ersteinrichtung der Gruppen ein wenig Gedanken machen
2) bei vielen Abteilungen hast du bald ein riesiges Gewusel an Gruppen (aussagekräftige Benennung hilft :P)
3) durch Verschachtelungstiefen kann es bei Zugriffsproblemen auf DBs schnell in Sucharbeit ausarten, sich durch die Gruppen zu wurschteln.Ich hab damit aber gute Erfahrungen gemacht...
greetz
RW[edit
langsamer Tippen hilft Fehler zu vermeiden...
[/edit]