There seems to be a mysterious difference between developer licenses for customers and those for NSC’s. At a customer, who is having a full (Application) Developer license, an error pops up when they make a change to a codeunit or report where the permissions on the tables used, are set in the properties. The error is something like “You do not have permission to modify table XYZ. Contact the system administrator if you need permissions changed.” But it is the admin who is making the changes (it doesn’t matter what the change is - i.e. some comment in the doc section is enough already), who is logged on as super-user. And modifying the offending table itself is allowed, it’s only happening with the programmed permission settings in the object properties. When the permission setting in the properties is cleared, or at Read only, the error disappears. When saving is done while running on a NSC developers license, there’s no error. But there shouldn’t be an error when running the customer license (what else do they have a developer license for?) The problem is present in NF2.01 and 2.60, and has been reported to local NTR support. Anybody experienced this also? Found a solution? John
John This is working as it should, as far as I know. The issue relates to what the permissions on the object allow it to do. For example, if a codeunit does posting like 80 & 90, then the customer cannot edit it unless they have a Solution Developer licence. Basically, even with a customers development licence it still checks what the object has permission to do before it allows them to modify the object. Craig Craig Bradney Project Manager - Technical Navision Solutions & Services Deloitte Growth Solutions Deloitte Touche Tohmatsu P:+61-2-9322-7796 F:+61-2-9322-7502 E:craig_bradney@deloitte.com.au
John This is correct the licence we have is a Solution Developers licence not am Applications one. I think its like the base developers one! Allows restricted access to the code. Solution Developer has full code access. David Cox MindSource (UK) Limited Navision Solutions Partner Email: david@mindsource.co.uk Web: www.mindsource.co.uk
Okay guys. I do agree that a customer developer license should have restrictions. Still it remains a strange thing that you can change the permissions on a table directly, but are not allowed to do the same indirectly. Don’t worry though, will use a NSC license to make the modifications 
John
Hi, Please note that the design granules (Table, Form, Report, Application Builder, and Solution Develooper) in a customer license only gives access to the functional granules that the customer have bought license for. This means that if the customer only have purchased eg. Finance and Sales & Receivables then the customer can only modify objects belongng to those granules. Maybe that is part of your problem. Lars Strøm Valsted Head of Project and Analysis Columbus IT Partner A/S www.columbusitpartner.com
Lars, That’s true, but not the problem here. One of the cases where the “no permission” came up was when the user wanted to modify a label field on the invoice. But as this report is setting permissions on the header table (113), the error comes up and saving isn’t possible under their license (although they have Report Designer and Application Designer license!) Now, don’t ask me why the report is setting permissions - it has been designed that way long time ago by the NSC which did the development. But, as said, don’t worry further. I’ll use a NSC license to get the modifications done. John
quote:
Originally posted by John Tegelaar: But as this report is setting permissions on the header table (113), the error comes up and saving isn’t possible under their license (although they have Report Designer and Application Designer license!) Now, don’t ask me why the report is setting permissions - it has been designed that way long time ago by the NSC which did the development.
I think I have a general idea of why they did this: this was done so a given user could run the Report object even if he or she didn’t have permissions to read and/or write Table 113. This is actually a good programming practice in many cases— especially if you have a client who is restrictive about which employees get to see which information (and/or if security is being set up by a prject manager who has not been through Solution Developer training.) In fact, you should usually do this when you build custom reports or forms: i.e., you should explicitly give the form/report permission to read/write all tables which it looks at. ------- Tim Horrigan horrigan@aol.com Edited by - horrigan on 2001 Apr 09 05:35:11
I think Tim is right. Also, please note that Table 113 is one of the tables that you don’t get access to (as a customer) until you purchase the Solution Developer granule. Lars Strøm Valsted Head of Project and Analysis Columbus IT Partner A/S www.columbusitpartner.com
This is to amplify the points discussed above. Suppose Administrator is create a object Called Myobject using Programmer license (Provided the permission to create this object. ) This object Can be modify by Administrator with customer license (Provided the permission to create/modified this object) But this object can’t be modified by the Administrator with customer license (if the license have lack of permission for create or modifiy this object.) This indicates these type of permissions are mainly based on license. We can see all these permissions from virtual table 2000000044. When we start navision, values of this table dynamically changes depending on our license file. Thanks and regards Mathew