Nav Security setup

pa_tou

Hi,

How can I setup the security in NAV 4 sp2 to be able to :
- Give acess to only certain contacts to users
I.e: Users that are working in New York locations should have only acess to read, create, delete contacts company in New york etc....

thanks

kine

May be the Responsibility Centers functionality can help you, but still you will need some customization if I am correct.

SD-JR

Hi,

No standard way without making code changes.

Standard security won't pass down to this level and responsibility centres don't kick in on contact records.

Looks like some programming work.

David_Singleton

In 2009 you should be able to use global filters, in which case this will be a much simpler modification than in earlier versions.

Alex_Chow

bummer that they didn't extend the responsibility center to contacts. But it wouldn't be tough to extend that functionality to the Contact area.

ara3n

David Singleton wrote:

In 2009 you should be able to use global filters, in which case this will be a much simpler modification than in earlier versions.

IS MS going to add some std functionality using this new feature?
Or is this something that will be up for NSC to implement based on requirements?
I am wondering how much of code will require (Fixing) to make it work with certain tables. :-k

kine

I am sure that it is mainly for the lists like customers, vendors, items, not for ledger entries because in this case you will be in deep troubles... 8)

David_Singleton

ara3n wrote:

David Singleton wrote:

In 2009 you should be able to use global filters, in which case this will be a much simpler modification than in earlier versions.

IS MS going to add some std functionality using this new feature?
Or is this something that will be up for NSC to implement based on requirements?
I am wondering how much of code will require (Fixing) to make it work with certain tables. :-k

When they first released this feature in 1993 in version 3.53 (or 3.52 maybe???) the function was not used in the base app. Navision Germany had some samples using it but that was about it. Of course it only lasted for the 3.5x versions, and never appeared again.

The excuse for not bringing it back was because of performance issues (filtering without a key) and of course the Entry number issues. I think it would be good if they could use it in the base app so that they can set some basic guide lines.

One piece of advise I can give, is to make certain that you have a key on any large table that you are going to filter like this.

As to the entry numbers, I assume that in version 7 we will see GUID instead of entry number thus removing that issue. Lets hope they don't create a single able (like Number Series) with fields like "Last Item Ledger Entry No." "Last GL Entry No." etc.

David_Singleton

Alex Chow wrote:

bummer that they didn't extend the responsibility center to contacts. But it wouldn't be tough to extend that functionality to the Contact area.

Yes I agree. Did you ever get the feeling that someone started developing the Responsibility Center functionality but forgot to complete it :-k

ara3n

for large tables, if the code filters on other field and there is an index for it, but then you have this global filter on top,

sql will choose one of the indexes to search.

I do see a major performance issue. :-k .


It's as though you have to add this filed to each index, but that means updating the code when set currently is used.

Unless in future version SETCURRENTKEY will not error out if the key doesn't exist.
Standard nav code would later remove 95 percent of all the SETCURRENTKEY. you only want to use it if you want the data to be sorted that way.

David_Singleton

ara3n wrote:

It's as though you have to add this filed to each index, but that means updating the code when set currently is used.

Yes basically this was the issue with the DOS version, you basically had to create the key and then select it. At least with SQL you only have to create the key, no need to worry about the C/SIDE code.

ara3n wrote:

Standard nav code would later remove 95 percent of all the SETCURRENTKEY. you only want to use it if you want the data to be sorted that way.

Well isn't that they case now? Do you use setcurrentkey now except to present data on reports and forms, or if the data needs to be processed in a specific order? SQL knows better than me which key it should use. (OK there are exceptions, but most of the time).

ta5

David Singleton wrote:

In 2009 you should be able to use global filters, in which case this will be a much simpler modification than in earlier versions.

Did you find something about this in an official document?
Thanks
Thomas

ara3n

I'm still using setcurrentkey, because Native db are still supported, most consultants test on native db and the code needs to work on both.

David_Singleton

ara3n wrote:

I'm still using setcurrentkey, because Native db are still supported, most consultants test on native db and the code needs to work on both.

Yes your situation would be different to mine, because you would be supporting add-ons and other code that would be used by multiple customers, so that makes sense. The only time I see Native database these days is when I am helping a client upgrade to SQL.

David_Singleton

Oh and by the way, don't you do....

IF NOT RECORDLEVELLOCKING THEN
SETCURRENTKEY(.......

:?:

jannestig

Actually i had a queestion in my mind about this platform release and how it could be applied.

I was looking for a developers opinion on how this would be implemented.

This seems the solution aimed at the original question

https://mbs.microsoft.com/knowledgebase ... knnuqrzysk

Problem
Microsoft Dynamics NAV 5.0 with Service Pack 1 does not limit the general visibility for users. For example, in a company that has several departments in Microsoft Dynamics NAV 5.0 with Service Pack 1, a user can view data or post data for other departments. However, you expect that the data for a specific user is filtered on a dimension code so that the user cannot view or post data for other departments. Therefore, you require a new platform feature to provide the functionality to limit the general visibility for users.
Back to the top

RESOLUTION
This hotfix provides a new platform feature for Microsoft Dynamics NAV to provide the functionality to limit the general visibility for users. This hotfix introduces the "Global Filter Groups" feature. After you apply this hotfix, you can use C/AL functions to set a filter for a table in the Global Filter Group "Filtergroup 1" so that all subsequent initialization or resets for records on the specified table have these filters applied automatically. This does not replace security-filter, but is a way to restrict visibility for each user.

Additionally, the "Filtergroup 1" filter group applies a global filter. Therefore, if this filter group is used anywhere in the C/AL code, the functionality may be different. The existing use of this filter group should be reviewed before you apply this hotfix.

You can insert data that will be outside the scope of "Filtergroup 1". However, this inserted data will not be visible to the user. This behavior is the same as you would see with a normal user filter such as "FilterGroup 0". If a filter is applied to a list and you inserted data into the list, and if a record was outside the scope of the filter, the insert will succeed but the record would not be visible to the user.

For more information about Filtergroups, see the section that is titled "FILTERGROUP(Record)" in the C/SIDE Reference Guide in Microsoft Dynamics NAV 5.0 with Service Pack 1.

ara3n

I have been using it in certain instances for performance reasons. For large tables, otherwise I'm fallowing how std NAV is doing, and MS isn't using this in any std code.

pa_tou

Thanks for all your contributions.
So How can I make those modifications to make sure that users are doing transactions and see only what they need base on their location . In this case , responsablities centers are also in place.

ara3n

you can look at 2009 sp1 executable and global filters feature they have added.