Zugriffsrechte Datenbankintern vergeben?

[feel_x]

Moin,

ich hab mal wieder eine DB-Anfrage für den Fachbereich,
diesmal geht es um Dozentenbewertungen.

Man stelle sich vor:
Ich habe einen Hauptmanager, der allen Dozenten sagt:
"Schickt eine Dozentenbewertung los."
Diese schicken dann an ihre Studis eine Bewertungsanfrage.
Die wird ausgefüllt und ist dann nur für den jeweiligen Dozenten und sie selbst lesbar.
(ich denke da an User roles.)

Die Frage ist: Wir wollen keine Gruppen im Adressbuch des Fachbereichs anlegen. Wenn man eine neue Kopie der DB macht, soll die DB mittels einer Abfrage als erstes danach Fragen, wer "Gott" (Admin), wer "Dozent" und wer "Studi" ist.

Wie vergibt man solche Rechte am sinnvollsten?
Mir schwebte da sowas vor wie das kopieren von Fachbereichs-Adressbuchdokumenten in die DB oder so..

Hat da jemand einen Tipp?

*Gespanntsei*
Gruß, felix s.

[Rob Green]

ich gehe von folgenden Prozess aus:

- eine DB
- dort legt Dozent seinen Umfragebogen an
- dann versendet er EMails mit DocLink auf die Umfrage (wie er an seine Studis rankommt, betrachte ich hier nicht ... dent Euch was aus)
- wenn Studi in Umfragebogen kommt, klickt er auf den Button "bewerte den Dozenten"..
- dadurch wird ein Antwortdoc angelegt
- im Antwortdoc ist ein Feld "Ersteller" enthalten, berechnet beim Anlegen
- im Antwortdoc ist ein Feld "Dozentname" enthalten, das auf Basis "inherit Values from ..." den Dozentnamen aus dem Original ausliest
- dazu ein weiteres Feld, Typ LESER, berechnet, mit Formel
"Feld_Studiname:Feld_Dozentname:"[Admin]""

Ergebnis:
- die Studis sehen nur ihre Bewertung und den Originalumfragebogen
- der Dozent "SchlafEin" sieht seinen Orginalumfragebogen "Wie bin ich" und die Antworten der Studis auf dessen Umfrage
- der Dozent "Wirri" sieht seinen Originalumfragebogen "Wer bin ich" und die Antworten der Studis auf dessen Umfrage
- alle sind glücklich  

[feel_x]

Jo, soweit alles fein.

Der Knackpunkt sind die Zustände kurz vor diesem Prozess:
Nehmen wir an, ein neuer Dozent kommt in den Fachbereich.

Der Datenbank-Manager müsste diesen Dozenten dann in den DB-Zugriffsrechten anlegen.
Schöner wäre jetzt aber, wenn er den Dozenten nicht als Person in die Zugriffsliste aufnimmt, eine Gruppe "Dozenten" gibt es nicht (und soll es nicht geben)

Wenn zum Beispiel die DB von anderen Fachbereichen mitbenutzt wird, hätte man teilweise verschiedene Adressbücher, teilweise gleiche Adressbücher, eine Gruppe "Dozenten Fachbereich Technik" und eine Gruppe "Dozenten Fachbereich SoWe" etc.
Und wenn alle Personen die gleichen Rechte haben, muss ich verhindern, dass die Studis Umfragen losschicken

Ich hoffe, das Problem ist anschaulich
Wie vergebe ich also die Zugriffsrechte für die DB intern am besten?


felix

[Rob Green]

Ich verstehe das Problem nicht ganz, wenn es denn eines gibt.

Logik:
Ihr wollt keine Gruppen anlegen?
Ok, dann auch keine personelle Zuordnung über ACL und damit wer Dozent ist und => Umfragen erstellen darf.

Ausweg:
a.) weiche Sicherheit: ein Konfigdoc, daß beim Versuch, eine Umfrage zu
erstellen, abgefragt wird, ob der Ersteller Dozent ist.

b.) harte Sicherheit: Genehmigung einer zu publizierenden Umfrage...Ersteller haut nen Umfragebogen rein...Genehmiger bekommt und nickt ab oder nicht..wenn er abnickt, wird Bogen public gestellt.

Ich denke nun einmal straight in einfachen Bahnen und suche die direkteste Lösung.

Nur, eines: es ist unklug, das eingebaute Notesfeature "ACL" zu umgehen, nur weil die Pflege der Gruppen etwas aufwendiger scheint...man kann an falschen Ecken Geld sparen.

[feel_x]

ist richtig, gerät in Unis nur leider oft ausser Kontrolle, weil zu viele Leute gleichzeitig Manager-Rechte haben wollen und meist niemand als alleinige Person Zugriffsbefugt ist..
ist blöd. Wir leben aber mit diesem Problem, seit wir Notes benutzen

In ner Firma würde ich auch eine Person alleine Verantwortlich machen, aber bei uns.. das ist alles ein bisschen schwierig, vor allem, wenn der Dekan ein Rechnerfeind ist, dem das sowieso alles völlig egal ist.  
Dann gibts keine klaren Weisungen und wir haben den Salat.

Dazu: Wie würdest Du den Genehmigungsvorgang gestalten?
Als Schaltfläche in einer Mail? Oder per Dokumentlink?
wie sollte ich die schreiben? Mit einer Feldänderung, wenn Antwort "genehmigt"?

Danke für Deine Hilfe,
felix

[Rob Green]

wie ich einen genehmigungsvorgang gestalten würde?

Weiß nicht, ob Du jetzt eine DB von mir erwartest...

also nur kurz:
man schicke vom Ersteller eine Mail aus DB mit Doclink an eine feste Person...diese gibt das verlinkte Doc frei und damit erscheint es in einer separaten Ansicht, public. Ersteller bekommt Hinweismail, daß er nur seine Umfrage an Studis vermailen kann. Diese versendet Mails mit Doclink auf Umfrage in public view.

[eknori]

also ohne Gruppen, entschuldige bitte, aber was baut ihr da für einen Mist.
Notes bietet nun einmal die Möglichkeit, Gruppen zu verwenden; und das aus gutem Grund.

Uni, ein Haufen Theoretiker.

Sorry, aber mein Verständnis für eine solche Vorgehensweise geht da gegen NULL

P.S.  Habt ihr etwa auch noch für jeden Fachbereich einen eigenen DominoServer in einer eigenen Domäne ?? Oder was hat das mit den unterschiedlichen NAB sonst auf sich.

[feel_x]

Hast ja recht

Wäre mir ja auch lieber, wir hätten als Notes-Admins oder zumindest Hiwis eine größere Weisungsbefugnis..
Das war während meines Praxissemesters in ner Maschinenbaufirma was anderes: Da wußte jeder, wo's langgeht..

(im Übrigen: FH, keine Uni )

Und: Ja, wir betreiben mehrere Domino-Server in verschiedenen Domänen.. das ist genau unser Problemchen.
Bei uns im Fachbereich gibts eine Entwicklungsteam, das sich auf Anwendungen spezialisiert, die in solchen Heterogenen Netzwerken laufen. Naja. Der FB Business Consulting macht eh immer Chaos

Gruß,
felix

[feel_x]

"diese gibt das verlinkte Doc frei und damit erscheint es in einer separaten Ansicht"

genau das meine ich: wie programmiere ich die Freigabe?
Feldstatus ändern?

[Rob Green]

genau das meine ich: wie programmiere ich die Freigabe?
Feldstatus ändern?

ich muß zu doof sein, aber ich verstehe Deine Frage nicht  
dauerhafte Informationen = werden in Form von Datensätzen dauerhaft abgelegt (bei Notes in Dokumentform)
Die Menge der dauerhaften Informationen spiegelt einen bestimmten regelbasierten Zustand wieder..ändert man einen Informationsbestandteil, kann sich der regelbaiserte Zustand ändern. Dazu muß man stets Informationen - wie gesagt - in Datensatzform speichern = Notesdokument bei Notes.

ok, das zur Theorie...und Praxis..

man nehme ein Feld Status
setze das feld Status von "NICHT GENEHMIGT" auf....
eine View "ungenehmigte", Select Field_Status="...."
eine View "Umfragen", Select Field_Status="....."

Sach mal, kann es sein, daß Du noch ganz am Notesanfang stehst? Es macht es etwas leichter, wenn man zB mitteilt, ob man erfahrener ist oder nicht...dann kann man einfacher auf gleicher Augenhöhe antworten, da ich sonst Stuss erzähle, den Du nicht verstehst, oder das viel zu trivial ist....

[feel_x]

Pardon, klingt jetzt beim nachlesen ziemlich dämlich, was ich geschrieben habe,
denke zu viel an mehrere Sachen gleichzeitig.

ich meinte folgendes:
Mittels Doklink ist die Freigabe ja problemlos zu realisieren,
mich interessiert jetzt der Sinn oder Unsinn, einen Teil der Maske direkt per Mail zu verschicken und beim Anklicken eines Buttons einen Feldstatus in der DB zu ändern.
Im Sinne der Faulheit der Anwender: sie wären halt einen Klick näher dran.
Ist wahrscheinlich völlig überflüssiger Blödsinn; mich interessiert nur, ob und wie das geht.



Bin übrigens seit 3 Jahren mit Notes beschäftigt, davon 2 Jahre als Admin und DB-designer. Leichte bis mittelmäßige Erfahrung, würde ich sagen.
Studier ja ein bisschen nebenbei
Kaum Skript-Programmier-Erfahrungen.
Habe Anfangs mal den Fundamentals-Kurs und vor kurzem ein Notes6-Server-upgradeseminar gemacht.

Projekte zum Beispiel:
http://wirtschaft.fho-emden.de
(ist aber jetzt ein neuer Admin, der erstmal das Layout geschrottet hat..)
oder http://wirtschaft.fho-emden.de/Vorlesungen/SS_03.nsf



Gruß,
felix s.

[Rob Green]

dann kannste aber gleich das gesamte Doc mit stored form in doc versenden (mußt halt eben drauf achten, daß es nit zuvel weird, weil diese Doctypen ca. um das 20x fache größer als normale Docs dieses Typus sind..ganz grob gesagt...ohne Attachments).

Und Teile davon..weiß nicht...nahh..mag nit...neee...finde ich irgendwie doof...

mach doch ein klares Prinzip: entweder kommt User zur Info (Holschuld) oder die Info zum User (Bringschuld). Beim Ersten sielt sich alles in der DB ab. Im zweiten Fall spielt sich alles per Mailing ab und am Ende landen nur die ausgefüllten Umfragebögen in einer zentralen Mail In DB zwecks Auswertung. Beide Wege haben Ihre Vor/Nachteile etc... Ausgehend von diesen gedanklichen Extrema kannst Du mE eher den für Dich/User etc. richtigen Designweg finden.

Den User ist es doch eh egal, ob links oder rechts herum..Hautpsache einfach, schnell und sorglos.

[feel_x]

Genau,
an die Bringschuld hatte ich gedacht.
Im Durchschnitt ist der User faul.

Einen Button klickt man dann doch lieber kurz mal an als einen Dok-link mit einem dahinterliegenden Button. Besser is.

Fein

Danke für die Hilfe, ich wollte halt nur nen Tipp haben, ob die Idee, das Dokument komplett zu versenden, absoluter Unfug ist.
Deswegen hab ich erstmal vorsichtig nachgefragt..

)
felix

[cpo]

Öh,  
faule User sind ja normal - aber wie willst Du denn die "Umfrage" per Mail verschicken?
Gespeicherte Masken in Mail-Datenbanken zulassen? Würde ich erstens niemals erlauben (wenn ich gott wäre ), gibt zweitens Chaos, sobald einer der Götter in euren Domänen da eine ähnliche Einstellung vertritt, und ist drittens auch einfach nicht vernünftig zu kontrollieren.

Als Text?   Wie soll das denn dann ausgewertet werden?

Also ich würde aus Sicherheits-, Praktikabilitäts- und diversen anderen Gründen zur zwei-klick-Lösung raten!
CPO

[feel_x]

Jo, mittlerweile hab ich das auch eingesehen

Zwei klicks sind doch erheblich einfacher als einer..
für den designer  


Gruß, felix s.