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 :P


    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

    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

    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!


    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

    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!


    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 sollen


    Nachteile:
    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]