Security Filters and posting

jorgito

Hi everyone.

My client is divided into departments and the employees of each department should be able to post and view data relevant to only their department.

The department is setup as a dimension and I have created roles for each department. I have set the permissions to both the master table as well as the entry tables (as stated in other posts). When I login as a user of a department I can actually view only the data that is relevant to this department (customer balances, entries etc.). So far so good.

When I try to post a sales invoice, I get the error "You do not have permission to read the G/L Entry table". When I open the debugger, it stops on the line that goes to the last record of the G/L Entry table in order to find the next Entry No and the next Transaction No. It seems that the program tries to access records that are outside the user's permission, which is normal since the last record of the G/L Entry could have been inserted by a user of another department.

How can the program find the correct Entry No for the next line, since it has to overide the security filter that have been set? Has anyone been able to post after having set security filters? What should I do to allow users to post invoices?

Thanx in advance
Jorgito

Arhontis

Hi,

I have a couple of ideas:

1) You could add the read permission of G/L Entry table in the permissions of cu12.
2) If your department dimension is a global one, you could remove the security filter from the G/L Entry and place some code in the onOpen of the form that show G/L Entries and use something like that:

  varUserDepartment := .... (get the department somehow)
  FILTERGROUP(2);
  SETRANGE("Global Dimension 1 Code",varUserDepartment);
  FILTERGROUP(0);

That way you show only the recs the user should see, and don't have any security filters enabled...

jorgito

I tried adding the read permission of G/L Entry table in CU80 but it didn't work.

I do not wish to do this by code since there are many forms that the users are using and I don't like redefining half the forms of Navision. Even if I do that, I will have to link each user with his department etc etc. Lots of work...

Is it possible that if I set a security filter, Navision cannot post? There must be a workaround that I am missing.

Arhontis

Arhontis wrote:

1) You could add the read permission of G/L Entry table in the permissions of cu12.

Tried on cu12?

The actual information of G/L Entries usually are displayed on one form (form 20). And you can get the department of the user by looking into the user's roles and permissions and accessing the security filters you might have placed.

jorgito

Yes, I tried setting it in CU12, but since it is a sales document, codeunit 80 starts first.

Before implementing security filters using code, and since I have put so much effort in building the roles and the security filters, I would like to be sure that posting does not work if you set security filters.

If posting is impossible, then this is a serious Navision bug.

Arhontis

I am out of ideas, so I guess that the best way on overcoming this problem is to place an MBS incident on partnersource to let them know about this issue and get their opinion.

Arhontis

:-k
(long shot idea)
I looked up some info about the FILTERGROUP function and FILTERGROUP(6) holds the security filters of the user.

The help says about "applying security filters for user permissions" but maybe resetting (clearing) the filter of the field you use in the security filters in the roles for the G/L Entry prior the FIND('+') might get you the last g/l entry without an error.

jorgito

I tried changing the FILTERGROUP, but if I MESSAGE the GETFILTERS, it shows nothing. I tried SETRANGE on the field but it didn't work.

GLEntry.FILTERGROUP(6);
GLEntry.SETRANGE("Global Dimension 1 Code");
GLEntry.FILTERGROUP(0);

Arhontis

First of all you need the GLEntry.SETPERMISSIONFILTER before all to be able to read correctly with the FILTERGROUP(6) and the getfilter.

I replicated your problem in a db of mine and tried some solutions like clear, setrange, adding tbl17 to the cu80 e.t.c. but none of them worked...

Every time the cu80 stopped at the FIND('+') in cu80, even after clearing the security filter. Seems like the sec. filter is been reapplied every time...

So I only suggest the official support with an mbs incident or if someone else here has seen that before.

That was tricky, I am sorry I could not come with a solution to your problem.

Make sure to post here if you come up with a solution or workaround...

raven44

Add another role with:
G/L Entry - READ permission only (no security filters on this role)
Assign this role to the relevant users, inclusive of the role that contains the security filters.

This should now still filter your relevant COA, as well as allow posting to your specific filtered dimensions.

Robyn

As well as giving codeunit 12 and 11 permission to read the G/L Entry table, you must give the users indirect read permission to the table with no security filter.

So each user who must post to restricted groups will need to have two different roles containing g/l entry, one with indirect read, no filters and one will normal read, filtered to their department security.

If you don't give unrestricted indirect read at least when finding the last Entry No. used, you will run into Entry No. assignment issues.