[gelöst] Keine Objektlizenz. Tabelle dennoch in LicensePerm.

Hi,

ich habe einen Kunden, welcher Objektanpassungen im Standardbereich durch eine Archivlösung hat. In den OnAfterGetRecord-Triggern wird die Lizenz für die Archivlösungsobjekte mittels Tabelle "License Permission" geprüft. Dabei wird auf eine Tabelle der Archivlösung gefiltert. Bei Positiver Prüfung (Tabelle ist vorhanden/lizenziert) wird eine Page oder auch Codeunit der Archivlösung angesteuert.

Nun möchte ich aber auch mit unserer Programmierlizenz im Testsystem arbeiten und stoße auf ein seltsames Problem. Die Programmierlizenz enthält keinerlei lizenzierte Objekte für die Archivlösung. Ich erwarte daher, dass die Lizenzprüfung der Archivierungslösungstabelle auf FALSE läuft und daher nicht auf die Archivcodeunits/-Pages zugegriffen wird. Dem ist aber seltsamerweise nicht so. Die Lizenzprüfung der besagten Tabelle ist weiterhin positiv und die Programmierung möchte daher dann auf die Codeunits/Pages zugreifen, was dann aber scheitert. Ich kann also keine Standardpages mehr mit unserer Programmierlizenz öffnen, da dies dann mit der Fehlermeldung "Sie verfügen nicht die Zugriffsrechte für..." endet.

Wenn ich die Prüfung über die "License Permission" Tabelle direkt auf die jeweilige Codeunit oder Page ändere, dann wird zuverlässig erkannt, dass diese Objekte nicht lizenziert sind. Wie kann das sein?

Zuletzt geändert von Raik Zobel am 17. März 2020 14:27, insgesamt 1-mal geändert.

Seit dem Jahr 2016 sind in Entwicklerlizenzen sowohl Standardobjekte als auch Module anderer Partner freigeschaltet. Grund waren Probleme bei Mergen und Updates. Vorher konnte man z.B. neue Felder im Standardbereich und neue Standardobjekte nur per Fob und nicht per Txt anlegen, das wurde damals aufgehoben.

@Kowa:
Du meinst mit "Entwicklerlizenz" sicherlich die "Partnerlizenz", denn auch wir (als End-Anwender) haben eine "Lizenz zum töten" (Application-Builder und Solution-Developer).
Leider scheint es aber noch Microsoft Dynamics Partner (gold certified ERP) zu geben, die mit ihrer Lizenz zwar Objekte und Felder im W1-Bereich anlegen dürfen, jedoch keinen Zugriff auf Module von anderen Partnern haben.

@vandyke:
Wird bei der Lizenzprüfung eventuell auf die Berechtigung einer bestimmten Tabelle (oder gar TableData) abgeprüft und darauf basierend dann eine Codeunit gestartet?
Ich habe es leider schon des Öfteren gesehen, dass der Partner auf die Insert-Permission ihrer Setup-Tabelle geprüft hat, um anschließend eine Codeunit, ... aufzurufen.
Richtig wäre, die Execute-Permission des aufzurufenden Objektes (also Codeunit) abzufragen.

Ich kann mit meiner Partner-Lizenz Felder in geschützten Nummernbereichen anlegen, ich kann aber nicht in geschützte Partner-Objekte rein wenn der andere Partner die mir nicht freigeschaltet hat. Wie Kowa schon schreibt kann ich damit mergen und updaten aber nicht Partner-Code ändern (oder sehen) wenn der mir das nicht erlaubt. Finde ich auch richtig so.

Ich bin immer noch der Meinung, dass Microsoft den "Certified Microsoft Partner" die Execute-Berechtigung auf alle Objekte, sowie die RIMD-Berechtigung auf alle TableData geben sollte.
Das würde schon vollkommen ausreichen und immer noch verhindern, dass die Partner Änderungen an den Objekten vornehmen können.

Code:

TableData                      0 RIMD
Table                          0     X
Table                 1..999 999 RIMDX
Table     99 000 000..99 999 999 RIMDX
Report                         0     X
Codeunit                       0     X
Page                           0     X
Query                          0     X
System                         0     X
Field                          0     X
Field                 1..999 999 RIMDX
Field     99 000 000..99 999 999 RIMDX

Hallo und vielen Dank erstmal an alle. Dieses Verhalten war mir bisher nicht bekannt.

@Kowa:
[...] Wird bei der Lizenzprüfung eventuell auf die Berechtigung einer bestimmten Tabelle (oder gar TableData) abgeprüft und darauf basierend dann eine Codeunit gestartet?
[...]

Genauso ist es, leider.
Edit: Ein "Object Type" ist ja nicht mal angegeben.

Code:

  LicensePermissionLoc.RESET;
  LicensePermissionLoc.SETRANGE("Object Number",xxxxxxx);
  LicensePermissionLoc.SETRANGE("Read Permission",LicensePermissionLoc."Read Permission"::Yes);
  IF LicensePermissionLoc.FINDFIRST THEN
    CurrPage.DropAreaFactBox.PAGE.SetFilter(DocType,"No.",TRUE);

Ich habe mich an den Support gewandt und selbst schon gemeint, Sie müssen die Prüfung auf das auszuführende Objekt machen.

Edit:
Habe jetzt per Text Export, Suchen & Ersetzen und Text Import ein zusätzliches SETRANGE auf LicensePermissionLoc."Object Type"::Codeunit gemacht, da es auch eine Codeunit mit der angegebenen "Object Number" gibt.

Dann war's ja nur ein Programmierfehler. Es bringt mich nicht weiter wenn ich die Lizenz für Tabelle 50000 prüfe, dann aber Codeunit 50000 ausführen will...

Es bringt mich nicht weiter wenn ich die Lizenz für Tabelle 50000 prüfe, dann aber Codeunit 50000 ausführen will...

Wo sollte da auch der Sinn liegen? Wenn ich die Codeunit 50000 ausführen will, dann muss ich schon die Execute-Permission der Codeunit 50000 abfragen und nicht eine andere Permission und/oder ein anderes Objekt.