Einzelne Felder zur Änderung freigeben

Hallo liebe Community,

bin noch recht neu in dem Thema Dynamics NAV. Daher ergeben sich für mich noch viele viele Fragen und ich hoffe in Verbindung mit diesem interessanten Forum viele viele Antworten mit der Zeit zu bekommen.

Momentan beschäftigt mich ein Thema ganz besonders, welches ich leider mit Hilfe der Suche nicht lösen konnte.
Es geht darum, das ich einer Abteilung die "Artikelkarte" komplett frei geben musste, weil diese dort bei einigen Feldern Änderungen vornehmen müssen. Genau da ist aber der Punkt, sie brauchen nur eine Hand voll von Feldern in der "Artikelkarte" und nicht alle....

Die Frage ist, wie kann ich den Anwendern über Berechtigungen (Dynamics-Seitig oder SQL-Seitig ??) NUR einzelne Felder der "Artikelkarte" freigeben bzw sperren ?? Ist das überhaupt möglich ??

Ich hoffe ihr könnt mir das beantworten, muss aber darauf hinweisen, das ich noch nicht der "Profi" in Sachen Dynamics bin. Bitte habt ein bisschen nachsicht mit mir und berücksichtigt das bei evtl. Lösungen..... Danke

Gruß
Mirko

meines Wissens nach geht das nicht:

dafuer muesste man eine alternative Form erstellen und diese dann fuer die Benutzer anzeigen.
Denke das waere der unkomplizierteste Weg.


Gruß Matthias

"Geht nicht gibt's nicht."

Im NAV Standard ist das zwar nicht möglich, aber rein technisch gesehen wäre es schon möglich, jedoch sehr aufwändig in der Umsetzung.
Man müsste eine Tabelle definieren, in welcher pro Benutzer (oder Benutzergruppe) festgelegt werden kann, welche Felder er (nicht?) editieren darf.
Auf der Artikelkarte (Form30) müsste man dann in dieser Tabelle nachsehen, was der Benutzer darf und jedes einzelne Control per C/AL-Code (nicht) editierbar schalten.
Rein theoretisch könnte man diese Tabelle auch dazu nutzen, um bestimmte Felder komplett auszublenden, wenn z. B. der Verkäufer auf der Artikelkarte keine Einstandspreise sehen soll. Das wäre logischerweise noch aufwändiger, dafür aber noch flexibler.

Wie gesagt: Technisch möglich, jedoch mit viel Fleißarbeit verbunden, da jedes einzelne Control auf der Artikelkarte (oder welche Form auch immer) einzeln EDITABLE := TRUE/FALSE geschaltet werden muss.

Hallo,

ich würde folgenden Versuch unternehmen:
1. Die gewünschte Maske im OnOpen-Trigger oder ggf. im OnAferGetRecord-Trigger per
CurrForm.EDITABLE := FALSE;
komplett auf nicht editierbar setzen.
2. In der Benutzereinrichtungstabelle ein Feld "Abteilung" definieren
3. In den Feldern der Maske, die die Benutzer dieser Abteilung editieren dürfen, Folgendes codieren:
Im OnActivate:
IF "User Setup".Abteilung = ... THEN
CurrForm.EDITABLE(TRUE);
Im OnDeactivate:
IF "User Setup".Abteilung = ... THEN
CurrForm.EDITABLE(FALSE);

Die Geschichte mit der Zuordnung Benutzer <-> Abteilung bzw. die Abfragen in den Feldtriggern kann man je nach Bedarf beliebig verfeinern.

Ich war bisher auch immer der Meinung, dass dies nur mit immens hohem Aufwand verbunden ist.
Unter anderem ein Beitrag von Natalie, den du unter dem Suchbegriff "CurrForm.Editable" findest, hat mich eines Besseren belehrt.

Viel Spaß

Hi!

Und wenn man das ganze sehr "exzessiv" betreiben möchte, dann gäbe es auch ein "Field Level Security" Add-On: http://www.lanhamassoc.com/securitymgmt.htm

Gruß,
Jörg

Hallo StefanS,

das ist aus meiner Erfahrung keine gute Idee. Ich habe das ganze bei einem Kunden im Einsatz, dort funktioniert das nur deshalb, weil der Kunde nur zwei Felder in der Form ändern muss, und er die Felder in einer bestimmten Reihenfolge bedient. Es gab dabei Probleme mit der Tab- Reihenfolge, und ich meine auch mit einigen Triggern, die nicht gerne aufgerufen werden, wenn das Form nicht editierbar ist. Timos Vorschlag ist zwar im ersten Moment aufwendiger, ist aber die sauberste Lösung.

Zu der Zuordnung: Definier doch einfach eine Rolle 'ITEMEDIT'. Diese Rolle ordnest du jedem Benutzer zu, der die Artikelkarte ändern muss. In deinem Programm fragst du dann ab, ob dem Benutzer die Rolle zugeordnet ist (Datenbank und Windows-Authentifizierung beachten).

Gruß, Fiddi

Bin mit Timo und Fiddi einverstanden!

Wenn die Vielfallt von Begrenzungen Editierbar/Nicht editierbar noch in Rahmen hält bzw. ein Feld in der ganzen Anwendung einer einfachen „Editieren“ Regelung unterliegt, dann kann man das auf der Tabellen- bzw. Formularebene ruhig und schnell gestallten. Sobald aber die Anforderungen an die Flexibilität solcher Einrichtung steigen, ist es nicht mehr möglich, das vernünftig zu steuern. Was würdest du machen, wenn Artikelmerkmale in EK/VK Zeile abhängig von der Globalen Einstellungen, Artikel Einstellungen, Einstellungen in der Artikel Hauptkategorie, Artikel Kategorie bzw. Produktgruppe editiert werden dürfen oder nicht.

Aber bevor los zu legen, muss man zuerst ein Konzept erstellen, was damit gesteuert werden soll und immer über die Zukunft nachdenken, was dazu noch kommen könnte. Sonst hat man angefangen, die Lösung umzusetzen, sind die nicht berücksichtigten Anforderungen schon aufgetaucht, und das Ganze muss überarbeitet bzw. angepasst werden. Bzw. noch schlimmer ist, wenn alles funktioniert, aber die neuen Anforderungen alles auf den Kopf stellen.

Gruß, Michael

Aber bevor los zu legen, muss man zuerst ein Konzept erstellen, was damit gesteuert werden soll und immer über die Zukunft nachdenken, was dazu noch kommen könnte. Sonst hat man angefangen, die Lösung umzusetzen, sind die nicht berücksichtigten Anforderungen schon aufgetaucht, und das Ganze muss überarbeitet bzw. angepasst werden. Bzw. noch schlimmer ist, wenn alles funktioniert, aber die neuen Anforderungen alles auf den Kopf stellen.

Genau hierin besteht die große Kunst der Consultants und Programmierer:
Sie müssen ihre Glaskugel auf Hochglanz polieren und (aufgrund ihrer jahrelangen Erfahrung) vorhersehen können, was der Anwender in Zukunft sich noch wünschen könnte.
Der Programmierer muss seine Lösung dann so umsetzen, dass sie in möglichst viele Richtungen flexibel erweitert werden kann.
In meinem Lösungsvorschlag habe ich ja schon ein Beispiel genannt, wie so eine "Vision" aussehen könnte: Anstatt nur Editierbar/Nicht editierbar könnte es zukünftig gewünscht werden, die Felder einzeln komplett auszublenden.
Von daher sollte man in diesem Fall von Anfang an auf ein Option-Feld (anstatt eines Boolean) setzen, da man dies jederzeit entsprechend erweitern kann.
Hätte man auf ein Boolean gesetzt, so müsste man später entweder die Daten konvertieren oder der Programmcode wird mit der Zeit unüberschaubar ("Spaghetti-Code").

Im Laufe der Zeit habe ich sowas wie einen 7. Sinn entwickelt und erkenne recht zuverlässig die zukünftigen Wünsche.
Manche Kunden fordern solche Erweiterungen zwar niemals ein, sind jedoch beeindruckt, dass ihre Lösung solche Erweiterungen zulassen würde.
Abgesehen davon hat es für einen MBSP den Vorteil, dass er ein entsprechendes "Snippet" auch in anderen - ähnlich gelagerten Fällen - wiederverwenden kann und das Rad nicht nochmal erfinden muss.