Feature Request: readonly-Rechte auf BCD

Es gibt Situationen, wo man Leuten gerne readonly-Rechte auf BCDs geben möchte. Das geht afaik stand heute nicht. Daher dieser Feature-Request.

Wie man das genau implementieren könnte, muss man noch ausdiskutieren.

added API label

added Feature Request label

am einfachsten wäre das via cntl.mgr2group, dh. das konto bekommt (über einen neu zu definierenden schalter bzw. bool-attribut) nur-lese-zugriff auf alle gruppeninhalte, dh. fqdns (namespace) und bcds (addrspace) der gruppe. (also alles nur-lesen oder alles schreiben)

reicht das?

Für mich hört sich das an, als würde das in die richtige Richtung gehen.

Die Frage wäre, ob es an nd.bcd2group besser aufgehoben wäre - dann kann ich eine RO-Gruppe machen und dort die Leute einfügen. Ansonsten müsste man das RO-Flag für jeden User einzeln setzen - wenn man nicht aufpasst, kann man so einem Nutzer mehr Rechte geben, als er ursprünglich bekommen sollte.

dann gehoert das attribut direkt an die gruppe. dh. alle gruppeninhalte, also namespace und addrspace sind fuer alle konten dieser gruppe nur-lesend zugeordnet. das attribut wird auch auf alle untergruppen vererbt.

Wie wäre es die Logik umzudrehen? Standardmäßig ist alles RO und wir machen ein RW-Attribut? Klar, das wird aufwendiger. Aber im Zweifel vielleicht logischer?

der technische aufwand besteht nur in der definition des defaultwertes (aktuell true). ansonsten muss man die leute dran gewoehnen, dass die voreinstellung jetzt andersrum ist.

assigned to @rainer.steinmueller

problem dabei: wenn ein konto mehreren gruppen zugeordnet ist, die gleiche bcds oder gleiche fqdns beinhalten, aber unterschiedliche ro/rw-attributwerte (des o.g. neuen attributs) haben. was soll dann gelten?

diese loesung ist deshalb m.e. untauglich.

"Höchste" Berechtigung gewinnt? Fände ich jetzt nicht völlig abwägig.

Fände ich auch nicht abwägig.

schon, aber das ist sehr unuebersichtlich. wenn der OEB fuer ein konto eine ro-zuordnung eintraegt und dabei uebersieht, dass das konto schon in einer anderen gruppe (mit zumindest teilweise gleichem inhalt) rw-zugriff hat, ist sein eintrag wirkungslos. dann wird erstmal gefragt, warum das nicht funktioniert.

Das geht an der BCD aus der Berechtigungsübersicht eigentlich ganz gut hervor finde ich ("Berechtigungen"/"Permissions"-Reiter in der BCD im NETVS).

(dort würde ich das RO-Attribut auch durch ein badge an der Zuordung sichtbar machen)

ja, aber nur fuer den betreffenden account - nicht fuer den OEB.

auf devel ist der erstentwurf fertig (ungetestet). das attribut heisst cntl.group.content_is_rw_accessible.

sehr cool, ich schau mir das mal an.

changed milestone to %API 4.2 Release

closed