installed modules

is there a way i can determine what 3rd party modules are installed on my NAV system?

Do you mean Addon’s?

If yes, they will be in different object ID range…

yes i believe so. I have been asked to remove all super users from our system but have only used nav for around 4 months now. I was told that since there were addons such as a ‘jobs’ module and a ‘asset’ module and ‘asset location’ module (and who know what others) when permissions were set no one could complete their job so everyone was just made a freaking super user instead of slowing down and fixing the problem when NAV was implemented in the company i (a new employee) have to figure out how to make this transition of limiting permissions. The recommendation is for me to run the sql profiler on a user for the busiest time (month end) and write a VB parser that will take the output of the profiler and write update scripts to the roles permissions. I feel this is an almost impossible task going about it this way since i ran the profiler on a user for around 2 minutes and i have about 2 thousand transactions in the profiler and most of the transactions execute stored procedures.

I have a few recommendations from this forum (see link below). I have a great concern attempting this project in the manner above. So i need to figure out what addon objects have been added so i might better understand how i can restrict super users

I can tell you one thing and that is the VB parser approach is absolutely dead wrong.

You should get in touch with your NAV partner and get a consultant out to explain how to use permissions. This is not a trivial task, you need professional guidance on how to do this properly.

One way to get a quick overview of the granules is to open your license. Go to the Tools in the NAV client and select License Information. This should list all the granules. If you can’t make sense of that, call your NAV partner and have them send you a new license and its configuration file.

One more thing is that you’re probably not tracing the right events in SQL Profiler, because you can definitely catch actual queries on actual tables. I usually only track SP:StmtCompleted under Stored Procedures and SQL:BatchCompleted under TSQL and get LOTS of T-SQL queries.

Also, if you did it that way, you’re starting out with bad data from the beginning. If they have access to all of the data, how do you know they are only accessing the data they need / are supposed to? You would be building permissions based on incorrect assumptions. Take Daniel’s advice. Roles / Permissions are deceptively simple and it can be very beneficial to have someone out there that really knows how to use them to the company’s advantage.

awesome, Thanks for the advice…