SQL Securityroles with MS Dynamics NAV

February 27th, 2012 by rola

I’ve received many questions on how to setup security for common admin tasks in NAV.

This is what I discovered so far..

  • In order to  kill a user session (Using F4 in the Session List):
    User must be a member of processadmin server role.
  • In order to add/delete users in NAV:
    User must be a member of the server role ’securityadmin’.
    User must be a member of database role ‘db_owner’ in databases ‘master’ and ‘<navision>’.
  • In order to import new table objects:
    User must be a member of the server role ‘dbcreator’.
    User must be a member of database role ‘db_owner’ in database ‘<navision>’.

Feel free to comment and append information..

Input check for text and code fields in NAV

January 31st, 2012 by rola

In NAV there is often an issue with invalid characters when a user is using copy&paste with external programs. For instance when copying data from Excel. Fields that comes to my mind is address-fields on Customer and Vendor cards etc.

When using copy&paste the copied data often also contain hidden whitespaces like carriage-return (0×13 0×10).

When exporting this data to files, or when using data in integrations projects, these characters can be annoying, causing the output to be malformed.

An even worse case is when the user is using  “copy&paste” to enter serial no into NAV.

When later someone tries to do a search on a serialno, there user must user a wildcard-search to find the record.

For instance, a user pastes a serial no ‘ABC123′ from a list in Word/Excel. The invalid character is not visible when running NAV on Win7. On Win XP there is a ’square’-character. To find the record the user must search for ‘ABC123*’, instead of ‘ABC123′.

So, here’s the solution.

In cu 1 there is a function called “MakeText” (function no 107). This function is called whenever users enter data to a text-field. If we clean the incoming data in this function, we will not have any issues with address-fields etc.

Serial number are of data type CODE and will not be handled by this function.

If we create a new function “MakeCode” (function no 109), we have solved the problem with CODE-fields to. Below you find the code-changes made to cu 1.

Please note that function 109 is not implemented by default. I don’t know if this feature is supported by Microsoft.

However, I’ve been using it on several sites for years now..

cu 1:...PROCEDURE MakeText@107(VAR Text@1000 : Text[250]) : Integer;
VAR
Position@1004 : Integer;
Length@1003 : Integer;
BEGIN
//START
Text := CleanCRLF(Text);
//END
Position := 1;
Length := STRLEN(Text);
ReadCharacter(’ ‘,Text,Position,Length);
IF NOT ReadSymbol(’?',Text,Position,Length) THEN
EXIT(0);
PartOfText := COPYSTR(Text,Position);
IF PartOfText = ” THEN BEGIN
IF FORM.RUNMODAL(0,StdTxt) = ACTION::LookupOK THEN
Text := StdTxt.Description;
EXIT(0);
END;
StdTxt.Code := COPYSTR(Text,Position,MAXSTRLEN(StdTxt.Code));
IF NOT StdTxt.FIND(’=>’) OR
(UPPERCASE(PartOfText) <> COPYSTR(StdTxt.Code,1,STRLEN(PartOfText)))
THEN
EXIT(Position);
Text := StdTxt.Description;
EXIT(0);
END;
...

..and the new functions....

PROCEDURE MakeCode@109(VAR Text@1000 : Text[250]) : Integer;
BEGIN
Text := CleanCRLF(Text);
EXIT(0);
END;

PROCEDURE CleanCRLF@1070000(Text@1070000 : Text[250]) : Text[250];
VAR
CRLF@1070001 : Text[2];
BEGIN
CRLF[1] := 10;
CRLF[2] := 13;
EXIT(DELCHR(Text,’<>’,CRLF));
END;