So let’s start with this. When you setup the user role you have got two possibilities. You can either add each table data to delete manually (this would be the way to go, if the number of tables is not to great) or you can start with all table datas to delete and remove the delete permission from those tables you don’t want to delete data. To do it the second way you first will have to comprise a line like this:

Then after clicking at “All Objects”, you can remove the delete permission from those tables, you don’t want to delete data.
Now here is the simple report you will have to run finally in order to delete the data.�
report98001.txt
The report will work very quickly (because of the DELETEALL and no performing of DELETE-triggers), but you might need SUPER-user rights in order to delete some data (the permissions of the role _DELETE_DATA are not checked by the NAV permission management system, since the user role is not assigned to any login). Nevertheless be careful when deleting data. Note that you are using the code on this site at your own risk. No liabilty can be taken from the author.

There exists already a similar functionality for doing background jobs from within a normal NAV client, namely the E-Mail logging functionality which is launched in the LogInStart function of codeunit 1:

So it is only straightforward to implement a similar functionality for the job queue. At first we define a “Job Queue User ID” in the “Job Queue Setup” table (don’t forget to provide validate and lookup functionality for the field as you can find in table “Marketing Setup”):

It is advantegeous to choose a windows login as “Job Queue User ID”, because a windows login can be configured to start a NAV client automatically, when windows is started.

All what is left is to put some code into codeunit 1 in order to start the job queue scheduler, when the “Job Queue User ID” logs in:

So every time the “Job Queue User” logs in, the global scheduler codeunit is started in the background to check periodically for jobs to perform. Don’t forget to supply the “Job Queue User” with appropriate rights to perform his jobs. But as the NAV client session is always accesible from the console, the user should not have too much rights. For example it is often unnecessary to grant rights to any forms, object designer, etc….

I prefer to use a special background color (cyan) in order to show the user, that there is an individual online help available.
In the OnPush trigger of the button there is just one line of code:

So the button can be easily copied from one form to another (or from one report request form to another report’s request form). For use with reports, of course, the line of code has to be modified to

OnlineHelpMgt.ShowDocument(Object.Type::Report,CurrReport.OBJECTID);

Important is, that the variables are defined as local variables, so they are copied by the copy and paste process even with a “normal” form designer license.

As one might have guessed already, the data structure of the table “Online Help Document” should at least be something like this:

1. Object Type - Option (only Form and Report makes sense)
2. Object ID - Text (!), since CurrForm.OBJECTID gives a text
3. Document - Blob (contains the help document to show, e.g. in PDF format)

The primary key should be Object Type + Object ID. May be you should provide some Lookup functionality for field 2. Some additional fields may be useful, for example “Original document” - Blob (may be in word format), “Description”, “Creation Date”, etc.

In codeunit “Online Document Management” you will have to implement some functions like ShowDocument, ImportDocument, ExportDocument, etc. - the latter two will be provided in the corresponding tabular form in a Function-MenuButton. Some code suggestions may be taken from table 5062 Attachment, where analogous functions exist.

Needless to say, that the whole tool can be purchased from our company.

There are several possible approaches to this problem:
1.) The programmer might say: “Well, let’s remove the “dangerous” menu items from the “G/L Account List”. I would call this the “quick and dirty” solution. The main disadvantage is of course, that now nobody can branch from the list to the card, anymore, not even the users, who might want to do that. Another aspect is, that this approach would violate the fundamental policy “As much customizing as necessary and as less as possible.”

2.) The sophisticated programmer might say: “OK, let’s put a flag into the “User Setup” table to control which user may open the “G/L Account Card” and which user may not do that. Besides the fact that this approach would mean even more customizing, it is in some respect even dirtier (though not quicker) than approach 1, because one is forced to manage user rights once in the standard way (with roles and permissions for table data) and once again in the “User Setup” table with one (or more) flags for various objects (forms, report,..) - Remember that the “G/L Account Card” was only an example for an object, which should be disabled for certain users.

3.) The “setup manager” might say: “Well, NAV provides standard capabilities to handle the problem. You simply have to define in the respective roles, which forms the role should grant access permission and which form not.” - Unfortunately this approach turns out to become an outgrowth, mainly because of the fact that if you want to grant access to all forms, this can be done with one record in the permission table, containing zero in the field “Object ID”:

But if you want to exclude only one form from access you have to list all other forms, which you want grant access to. In other words: there is nothing like “negative permissions” in standard NAV. The disadvantages are on the one hand, that the whole rights setup will become monstrous and intransparent, on the other hand, each time a new form (or other object) is appended to the application, it has to be added to the respective roles. -

Although things would be so easy, if one could set up an access denial (for form “G/L Account Card”, e. g.) by simply adding a permission line like this,

unfortunately this line is ignored by the system, and access to form “G/L Account Card” is still granted with this additional line.

And here comes my proposal for the more or less short time until negative permissions will become standard in NAV (as they are already in Windows, e. g.). The idea is to have a general mechanism which prohibits the carrying out of an object (form, report, etc.) if a negative permission (as in the picture above) is active for a user’s role. With that mechanism working, the problem above can be easliy solved like this: Create a new user role named NO_GL, e. g. - Add a permission line with no execute right for form 17 to that new role (like in the picture above). Assign the new role to all users, who shall not be able to open the “G/L Account Card”. Later this role can be extended easily to prohibit access to other “dangerous” forms, which are accesible from the “G/L Account List” form, like “G/L Account Balance”, etc.

How would we implement this new mechanism in a straightforward and easy to use manner? Obviously there is no way off from putting some code into the OnOpenForm Trigger of the forms we want to protect. For reports, we would choose the OnInitReport trigger, instead. This code should be as short as possible (because we may need to supply many forms with it) and it should lead to an access deny error, which is ideally identical to the standard error, if a user has got no access rights to an object:

Now, here is a Codeunit “Permission Management” with a function CheckExecutePermission to be called as soon as possible, when running an object:
Codeunit 71600 “Permission Management”
The text object file is to be imported into NAV 2009. A similar approach should be possible for earlier versions of NAV.
To secure the form “G/L Account Card” against unauthorized opening, the following line of code has to be inserted into its OnOpenForm trigger:
PermissionMgt.CheckExecutePermission(2,17);
here 2 stands for object type Form and 17 is the ID of the form. PermissionMgt is a codeunit variable.
In this manner every object can be protected by using corresponding permission lines with negative execute permissions.
In order that every user can execute the code above one additional right has to be added to the user role ALL, namely Read permission for table 2000000009 (Session).