Anonymer Autor?

[qu1cke]

Jetzt wird's knifflig: In einer Anwendung soll ein beliebiger Benutzer Dokumente erstellen sowie diese lesen und bearbeiten können, sollte also als Autor hinterlegt sein.

Nun sollen aber andere Autoren desselben Dokuments nicht sehen können, wer der Originator ist. Wir haben nun schon einmal probiert, über Dokument kopieren... eine Lösung zu finden, das Problem ist, daß der Benutzer ja auch die Kopie bearbeiten können muß und so auch wieder im Autorenfeld steht.

Irgendwelche Ideen?

Danke,
René

[Ayhan]

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.

[Semeaphoros]

Stimmt. Da müsste eine Applikation dahinter gesetzt werden, welche beim Speichern eine anonymisierte Kopie erstellt (Agent oder so, im QuerySave selber geht das vermutlich nur mit Kopfstand) und beim Oeffnen zum Editieren wieder das Originaldokument hervorzaubert. Sprich, das braucht zusätzlich zum normalen Verfahren noch einen [mini-]Workfloh

[qu1cke]

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é

[Semeaphoros]

Na, dann schreib doch mal ein Pflichtenheft und gib das Ding in Auftrag, den Workfloh braucht es ja sowieso, also lässt sich das Anonymisieren durchaus auch bewältigen.

[qu1cke]

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  

[Semeaphoros]

F: Warum bleiben wir solange in der Rezession?

A: Weil überall herumgebastelt wird.

[qu1cke]

  Die armen Banken halt  

[Semeaphoros]

Stimmt!

Und genau die würden von einer Verbesserung profitieren.

Und genau die tragen einen grossen Teil der Verantwortung für die gegenwärtige Situation

Und genau die sollten - wenigstens was die Schweiz anbelangt - es besser wissen, schliesslich haben die Banken hier vor 10 Jahren genau das durchgemacht, was jetzt auch ausserhalb der Banken passiert: Eigene Kompetenzen abgebaut, bis sie fast nicht mehr funktionierten. Und - muss schon sagen - nix gelernt.

Anwesende natürlich immer ausgeschlossen ....  

[Ayhan]

go Semeaphoros go  

[Semeaphoros]

Danke ...  

Ich bin tatsächlich am Ueberlegen, wo man was (natürlich wohlformuliert) publizieren könnte, bin mir aber noch nicht so ganz schlüssig, ausserdem brauch ich noch ein bisschen mehr Infos für einen guten Artikel.

[Axel Janssen temp]

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

[Semeaphoros]

Vor mehr als 10 Jahren, potentieller Kunde von mir, Besitzer einer Druckerei:


".... ich will die und die Lösung ......... und es muss in C programmiert sein ....."

... was weder sinnvoll noch in meinem Sinne war ... :-)

Ich fragte ihn dann:

"Was meinen Sie zu einer Anfrage für Briefpapier, wenn der potentielle Kunde am Schluss sagt: '... aber die Sache muss unbedingt auf der Linotype 1020xyz pipapo gedruckt werden ...' .... haben Sie nicht das Gefühl, dass Sie als Drucker eigentlich besser wissen müssten, welches die bestgeeignete Maschine und das beste Verfahren für diese Drucksachen sein sollten? ......"


... soviel zu "... und könnte man das nicht auch in XML machen?"

[qu1cke]

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é

[Semeaphoros]

Klassische "Make or buy" Problematik. Alles ausserhalb des Kerngeschäftes selber machen zu wollen, ist meistens keine gute Idee, und doch erleben wir genau das im Moment. Gegen Abhängigkeit kann man sich gerade in dieser Situation absichern, indem man - extrem gesagt - Know how einkauft statt Produkte, das verhindert, dass man alles selber erfinden muss. Der richtige Mix ist der kritische Punkt. Und klar, das wollte ich unbedingt auch noch sagen, das Problem liegt sicher nicht bei Dir, das sind Sachen die auf Ebene der Geschäftsleitung und so ihren Ursprung haben. Und das speziell merkwürdige bei den Banken (sicher nicht bei allen und gerade die kleineren Banken haben das Problem besser erkannt als die Grossen), dass das Abbauen von Kompetenzen eben gerade auch im Kernkompetenzbereich passiert. Kunststück, wenn gewisse Manager am Schluss für ihren Abgang dann auch noch vergoldet werden. Langfristig zerbricht das Sozialgefüge ...... alles schon ein paarmal in der Geschichte dagewesen.

[Rob Green]

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)

[qu1cke]

Vielen Dank, Rob Green, Deine Idee hat uns nun doch wieder ermutigt und in die richtige Richtung gebracht. Auf jeden Fall ein guter Ansatz. Wenn man das ganze mit zeitgesteuerten Server-Agenten macht, braucht man die "onBehalfOf" Geschichte ja noch nicht mal... Zugegebenermaßen ist das Konstrukt an sich ja auch ein wenig paradox - Jemand soll etwas genehmigen, von dem er noch nicht einmal weiß, wer's verbockt hat  

Egal. Manchmal ist nur die Lösung so nahe...

Danke & Grüße
René

[Chriss]

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

[qu1cke]

Hi, Chriss,

danke, daß Du dich des Themas nochmal angenommen hast. Um die Autoren eines Dokuments zu verbergen, funktioniert das ganz gut (wenn man z.B. den Server das Dok. erstellen läßt). Problem ist: Nur die Autoren (sowie der Initiator) sollen das Dokument lesen können, vom Initiator soll aber keiner wissen. Damit müssen die Namen in Leserfeldern stehen, die jeder Leser wiederum einsehen kann.   Also muß man wohl doch den Umweg über mehrere Dokumente wie in Rob Green's Vorschlag machen.

Danke nochmals & Grüße
René

[HarryB]

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