Nun sollen aber andere Autoren desselben Dokuments nicht sehen können, wer der Originator ist

Ergibts es Sinn? Welche anderen Autoren? Wenn Benutzer Autorenrechte haben, können Sie Dokumente anlegen und diese Bearbeiten. Die anderen dürfen das Dokument nur lesen. Diese sollen nicht sehen, wer das Dokument erstellt hat? Im Dokument selber kannst ja die Infos verstecken, aber in der View unter Dokument-Properties nicht.

Hmm, mit normalen Notesmitteln nicht möglich.

Danke erst mal für die Antworten...  

Das Problem an sich ist, daß ein Vorgesetzter nicht sehen soll, daß einer seiner Mitarbeiter ein Dokument erstellt hat, er und der Mitarbeiter sollen aber das Dokument bearbeiten. Den Vorgesetzten in ein Autorenfeld aufzunehmen ist ja kein Problem. Der Ersteller aber soll wie gesagt nicht erkennbar sein. Und jetzt der Hammer  : Das ganze soll ja Workflow-Charakter haben:

Mitarbeiter erstellt Dokument => Benachrichtigung des Vorgesetzten => Vorgesetzter: "Nanu, wer hat denn da ein Dokument erstellt? Naja, sieht gut aus, ich geb's mal frei" => Benachrichtigung des Origininators => Orginator:"Juhu, mein Boss hat's freigegeben"...

Vielleicht gibt's ja doch noch jemanden, der eine Idee hat. Vielleicht ja auch mit Schlüsseln oder so?!?

Danke,
René

Genau das wollen wir ja nicht unbedingt - Soll ja möglichst nix kosten. Da müssen dann wohl entweder die Auftraggeber etwas von ihren Vorstellungen abweichen oder uns fällt noch was ein...

Danke, trotzdem  

  Die armen Banken halt  

go Semeaphoros go  

Garantiert nicht böse, sondern humorvoll gemeint

Man sollte mal eine "zoologische" Beschreibung von Software-Projekt-Consulting Kunden schreiben.

Typ A: Juchu. ich bin irgendwie Management.  
"Ich hab zwar keine technische Ahnung aber Budget"
Merkmale:

Kümmern sich nicht um so Details wie Programmiersprachen, Compiler, Server oder ähnlichen Tüdelskram. Kennen sich aber gut mit Computern aus. Schließlich haben sie in ihrer Uni eine Internet-Schulung besucht und sämtliche Uni-Arbeiten auf MS-Word und Powerpoint geschrieben. Ausserdem hatte er/sie auch mal einen Semesterferienjob, wo Excel-Makros geschrieben wurden.

Software-Architektur ist etwas für Spinner. Sie wollen auf jeden Fall damit verschont werden. Die extremst-super-spezielle Situation der IT ihres Unternehmens kann mit solchen generalistischen Ansätzen sowieso nicht abgedeckt werden. Dafür braucht es schon hartgesottenere Typen. Solche nämlich, die die IT ihres Unternehmens immer super-spezieller machen.

Neigen dazu auf schwachsinnige Requirements zu beharren, die zwar nicht unbedingt logisch sind, aber die sie irgendwie kreativ finden. Also quasi ihre persönliche Duftnote in der IT-Landschaft des Unternehmens. Diese Requirements nehmen dann 80% der Kosten in Anspruch und machen spätere Änderungen um den Faktor 4 teurer. Das ist aber nicht so schlimm.

Halten Software-Leute für 120% verlogen. Glauben denen kein Wort. Niemals.

In der Frühphase ihrer Karriere beharren sie auf Dokumentation der Grösse des Himalayas. Später lernen sie, dass diese Dokumentation nichts bringt, und wollen überhaupt keine Dokumentation mehr. Zwar gibt es in den Beauftragungen immer den Punkt Dokumentation 4 Tage. Sie haben aber gelernt, dass gerade dieser Posten mit der Consulting prima gegen Requirements getauscht werden kann, die ihnen erst während des Projekts eingefallen sind. Und dieses Postengeschiebe muß nicht mal intern besprochen werden. Genial.
 

Typ B: Software-Entwicklung ist geil, aber auf Kundenseite ist es doch schöner:
"Geht das nicht auch mit xml?"

- Sind bereit für Projekte mit brandneuer, nicht-funktionierender hype-Software viel Geld auszugeben, auch wenn das für das Unternehmen eigentlich nix bringt.
Ihnen gehts eben mehr um den kick von nicht sauber implementierten beta-Produkten und humboldinische Bewußtseinserweiterung in ihrem Lieblingsbereich.  

- Erwarten irgendwann in der Mitte eine gute Präsentation vor der Geschäftsführung. Am Ende scheitert das Projekt sowieso, aber in der Mitte können sie Punkte sammeln.

- Programmieren teilweise Stücke selbst, wenn die Zeit knapp wird. Finden im code des Entwicklers eine Menge an schlechten code. Sind dabei aber meist fair. Wollen es nur angemerkt haben.

- V.a. gegen Ende des Projekts werden dort bedenkenlos Nachtsitzungen geschoben, an denen sie selber teilnehmen.

Gruß Axel

Das ist genau die leidige Diskussion, die ich hier vermeiden wollte. Kurzum: Ich habe lediglich wissen wollen, ob jemand vielleicht eine Idee hat, wie man das Problem gekonnt umschiffen kann. Wir wollen nicht wegen einer kleinen Sache, die so schon so gut wie fertig ist, eine Consulting-Firma beschäftigen.

Wir machen solange es geht, in Richting Notes/Domino alles alleine, um uns schlichtweg nicht von anderen Dienstleistern/Consultingfirmen abhängig zu machen, was nicht heißt, daß wir kein Vertrauen in deren Kompetenz haben, oder es uns (selbstverständlich nach Kosten-Nutzen-Schätzung) nicht leisten könnten.

BTW: Unser Haus beschäftigt als kleine Privatbank etwa 600 Mitarbeiter weltweit, davon ca. 1/5 im IT-Bereich, wir haben Kompetenzen in allen möglichen Bereichen der Anwendungsentwicklung und entwickeln so fast alle von uns benötigten Clearing- und Verwaltungssysteme sowie Teile einer einzigartigen Fondshandelsplattform selbst. Die IT wird als wesentlicher Bestandteil eines funktionierenden Geschäftsbetriebes angesehen und so gehen auch die jählichen Investitionen zum großen Teil in diesen Bereich.

Also: es ist doch möglich, daß eine Bank kapiert, wie wichtig die IT für sie selbst sein kann...

Grüße
René

statt über die Welt zu sinnieren, zur Ursprungsfrage zurück:

ein Ansatz ist bei R6 nunmehr durchaus einfacher möglich, nämlich über einen Agenten eine Doc Kopie anzulegen und Namenspuren zu verwischen. Wobei der Agent "im Namen von" läuft, was ja eine neue Optiuon bei R6 ist. An dieser Stelle eben die Admin ID nehmen. Wenn Ihr eine habt. Vorteil: der Ersteller des Docs ist derjenige, der den Agent entsprechend eingestellt hat bzw. auf wessen Namen er läuft. Damit verliert sich die Spur zum wirklichen Ersteller, was man nutzen kann in Deinem Fall. Erklär ich sofort:

Was macht der Agent: er kopiert das Doc A (die Angabe von Author und Leserfeld verbleibt in DocA) in Doc B (Response), wobei natürlich die relevanten Felder ohne Personenangaben kopiert werden. Dieses Doc erhält zusätzlich die Angabe, wer das nun im 2. Schritt bearbeiten darf (ebenso über ein Authoren- und Leserfeld lösbar). Mit Hilfe der Leserfelder kann man sich uU die Mail sparen und stattdessen eine eigene View "offene Anträge" für den/die "Genehmiger" zur Verfügung stellen. Nochmals: Genehmiger hat keine Chance zu sehen, wer der echte Ersteller war!

Sobald Genehmiger seinen Part erledigt hat, kommt das Doc B in Status genehmigt. Nun kann man je nach Prozessvorgabe entweder einen zeitlichen Agent laufen lassen oder aber einen Event auslösen, die auf jeden Fall beide die Deltas in Doc A übertragen. Dann kann man DocB removen.

Sollte Originärersteller wieder etwas bearbeiten und dann genehmigen müssen, geht das Spiel von vorne los. Wichtig ist hierbei nur, daß der Originäerersteller auf keinen Fall n Kopien des Originaldocs zur gleichen Zeit erzeugen darf. Sonst gibt es kuddelmuddel. Also
1. Edit Doc A -> DocB -> genehmigt -> Doc A update -> Doc B remove
2. Edit Doc A -> Doc B -> genehmigt -> Doc A update -> DocB remove
etc etc etc

So, und das macht nun 235.879 Euro plus Märchensteuer, zahlbar in 14 Tagen, sonst kommt der Gerichtsvollzieher  

(btw, in meiner alten Firma hatten wir eine Job DB, bei der man Stellengesuche fast genauso behandelt hatte. Das echte Doc incl. der internen $Felder lag in einer "abgeschotteten" DB und die komplett anonymen Kopien unter Chiffreangabe in der öffentlichen DB. So wurde die Anonymität der MA sichergestellt. Das Template habe ich natürlich nicht, da nicht meins und habe leider erfahren, daß der zuständige MA nicht mehr in der Firma verweilt, den man dazu hätte fragen können)

Hallo Quicke,
stell in den Eigenschaften der Maske Anonyme Maske ein, dann werden keinerlei iInformationen über den Ersteller abgespeichert.
In dem Feld in dem der Name des Erstellers stehen sollte, kann man eine Auswahlbox machen und Anonymous anbieten. Damit steht dann Anonymous als Ersteller in dem Dokument.
Hoffe es hilft.

schönen Tach noch

Chriss

Hallo Quicke,

Anonyme Masken können Dich hier weiterbringen. Benutze für die Zugriffsrechte auf die entsprechenden Dokumente Rollen und Gruppen. Beispiel:

- Gruppe "Anonyme Autoren" hat Autorrechte auf die Datenbank und die Rolle "[Die Anonymen]" per ACL zugeordnet bekommen.
- Gruppe "Die Überwacher" hat Autorenrechte auf die Datenbank und die Rolle "[Big Brother]" bekommen
- Die Rolle "[Die Anonymen]" dürfen die entsprechenden Dokumente erstellen (Kann man in der Maske einstellen, wer Dokumente damit erstellen darf)
- Die Rolle "[Big Brother]" kann Dokumente Freigeben
- in der Maske definierst Du ein Autorenfeld mit Mehrfachwerten, welches Du beim erstellen der Maske berechnest ("Computed when Composed"). Als berechneten Wert gibst Du an: "[Die Anonymen]":"[Big Brother]"

Voilá

Viele Grüße
Harry