Randomly receive permission error

kelseykong@hotmail.com · 2013-11-06

Dear Experts

Users randomly received the following permission error when they try to post Purchase Receipt or Sales Return Receipt:

You do not have permission to read the G/L Entry table.

We are using NAV 2009 RTC.

Most of the cases users are able to post and print, which means there is no issue with the permission setup.

Please let me know if you have any clue of this issue.

Thank you.

Li

william_marcelinus · 2013-11-07

Dear,
Try check user access on Database, set users who access as DB_OWNER.
so all users can posting on tables.

Andwian · 2013-11-07

Do you use Security Filter?

kelseykong@hotmail.com · 2013-11-07

william_marcelinus wrote:

Dear,
Try check user access on Database, set users who access as DB_OWNER.
so all users can posting on tables.

Hi William
We prefer to not to change the permission to DB_Owner to regular users as they are not the owner of the database.

Just to let you know this error does not happen all the time, which is really confusing to us.

Thank you.

Li

kelseykong@hotmail.com · 2013-11-07

Andwian wrote:

Do you use Security Filter?

Hi Andwian

We are using Security Filter so that users don’t post GL Entries from Journal Entry page, by mistake.

May I know if this will cause the issue?

Thank you.

Li

Andwian · 2013-11-08

kelseykong wrote:

We are using Security Filter so that users don’t post GL Entries from Journal Entry page, by mistake.

May I know if this will cause the issue?

sometimes, perhaps, eg. when system try to read the record that out of the filter. It can be tricky.

Could you please explain in more detail, what Security Filter did you use?
Do you apply SETPERMISSIONFILTER?

kelseykong@hotmail.com · 2013-11-08

Andwian wrote:

kelseykong wrote:

We are using Security Filter so that users don’t post GL Entries from Journal Entry page, by mistake.

May I know if this will cause the issue?

sometimes, perhaps, eg. when system try to read the record that out of the filter. It can be tricky.

Could you please explain in more detail, what Security Filter did you use?
Do you apply SETPERMISSIONFILTER?

Hi Andwian

Thank you for your response.

Regarding your question, we applied the following security filter for all the role IDs that allow Read Permission for Tabledata 17.

G/L Entry: Source Code=<>GENJNL

We dont apply any SETPERMISSIONFILTER.

The confusing part is the error doesn't always pop up? And even it pops up, later on, users will be able to post.

Do you think this is related to responsibility center setup (the function is there, but only applies to purchase. the issue exists in both purchase and sales), or two users access the post and print function at the same time?

Thank you.

Li

Andwian · 2013-11-12

kelseykong wrote:

Do you think this is related to responsibility center setup (the function is there, but only applies to purchase. the issue exists in both purchase and sales)

I am not sure

kelseykong wrote:

two users access the post and print function at the same time?

No. The error should be:

"The G/L Entry table is locked by another user"

kelseykong wrote:

The confusing part is the error doesn't always pop up? And even it pops up, later on, users will be able to post.

It will raise an error only when the system find a record (G/L Entry in your case) that outside your Security Filter, i.e it find G/L Entry that Source Code is GENJNL.

Kishorm · 2013-11-12

When posting sales and purchase documents NAV will call a LOCKTABLE and then find the last g/l entry record so if the last record had source code = GENJNL then the restricted users will get the error. As soon as someone with access manages to post a sales or purchase document then the last g/l entry will no longer have source code = GENJNL so the restricted users will then be able to post with getting an error. This is why you are getting the error intermittently.

kelseykong@hotmail.com · 2013-11-14

Andwian wrote:
kelseykong wrote:

Do you think this is related to responsibility center setup (the function is there, but only applies to purchase. the issue exists in both purchase and sales)

I am not sure

kelseykong wrote:

two users access the post and print function at the same time?

No. The error should be:
"The G/L Entry table is locked by another user"
kelseykong wrote:

The confusing part is the error doesn't always pop up? And even it pops up, later on, users will be able to post.

It will raise an error only when the system find a record (G/L Entry in your case) that outside your Security Filter, i.e it find G/L Entry that Source Code is GENJNL.

Thank you Andwian!

kelseykong@hotmail.com · 2013-11-14

Kishorm wrote:

When posting sales and purchase documents NAV will call a LOCKTABLE and then find the last g/l entry record so if the last record had source code = GENJNL then the restricted users will get the error. As soon as someone with access manages to post a sales or purchase document then the last g/l entry will no longer have source code = GENJNL so the restricted users will then be able to post with getting an error. This is why you are getting the error intermittently.

Thank you Kishorm. You have pointed the right issue. I could replicate the error by adding a new GL Entry posted from General Journal. We added a read permission to the users that have issue and the issue was resolved.

Thank you so much for your kind support.

Li

Andwian · 2013-11-15

Kishorm wrote:

When posting sales and purchase documents NAV will call a LOCKTABLE and then find the last g/l entry record so if the last record had source code = GENJNL then the restricted users will get the error. As soon as someone with access manages to post a sales or purchase document then the last g/l entry will no longer have source code = GENJNL so the restricted users will then be able to post with getting an error. This is why you are getting the error intermittently.

Great explanation!
Thank you for pointing that out. =D>

mdPartnerNL · 2013-11-16

Kishorm wrote:

When posting sales and purchase documents NAV will call a LOCKTABLE and then find the last g/l entry record so if the last record had source code = GENJNL then the restricted users will get the error. As soon as someone with access manages to post a sales or purchase document then the last g/l entry will no longer have source code = GENJNL so the restricted users will then be able to post with getting an error. This is why you are getting the error intermittently.

Could you explain it again in little steps

"...the last record had source code = GENJNL then the restricted users will get the error".
Q.
Why would they get the error "You do not have permission to read the G/L Entry table."?

geordie · 2013-11-16

mdPartnerNL wrote:

Could you explain it again in little steps

"...the last record had source code = GENJNL then the restricted users will get the error".
Q.
Why would they get the error "You do not have permission to read the G/L Entry table."?

For every datatable permission using "Security Filter" field it's possible to define a specific criteria to limit records which can be read or not.
In this case on G/L Entry permission security filter was "Source Code<>GENJNL": when the following code in sales post codeunit is performed if G/L Entry record read has
Source Code = GENJNL security filter isn't respect and the error is raised:

IF RECORDLEVELLOCKING THEN BEGIN
  ..
  GLEntry.LOCKTABLE;
  IF GLEntry.FINDLAST THEN;
END;

Anyone know if it's possible using security filtering to apply modify/delete criteria?

mdPartnerNL · 2013-11-17

ok, I was under the assumption, when the security filter is setup, you cannot see the record (filtered out).

Maybe it's better to set a filter higher up the tree, on table GL Account, field Direct Posting=false, or on Register.

Andwian · 2013-11-25

mdPartnerNL wrote:

ok, I was under the assumption, when the security filter is setup, you cannot see the record (filtered out).

Maybe it's better to set a filter higher up the tree, on table GL Account, field Direct Posting=false, or on Register.

That is a better approach, since when using Security Filter <> GENJNL, we could not use SETPERMISSIONFILTER to bypass the last record which is GENJNL.

mdPartnerNL · 2013-11-25

Hope the topic starter will let us know what worked.

Kishorm · 2013-11-28

Kishorm wrote:

When posting sales and purchase documents NAV will call a LOCKTABLE and then find the last g/l entry record so if the last record had source code = GENJNL then the restricted users will get the error. As soon as someone with access manages to post a sales or purchase document then the last g/l entry will no longer have source code = GENJNL so the restricted users will then be able to post with getting an error. This is why you are getting the error intermittently.

Oops, typo - but I think a couple of you got the intended meaning - last bit was supposed to say...

"so the restricted users will then be able to post WITHOUT getting an error."

Andwian · 2013-11-28

Oops... I don't recognized the typos, until you notice us, and I keep it read two-three times, I still don't recognize it.
Finally, I can locate the typos. But indeed, I read it like this, before:

"so the restricted users will then be able to post WITHOUT getting an error."

I read it correctly, and understand correctly, although without 'OUT'. Maybe it is true fact that human brain could correct the typos automatically.

Howdy, Stranger!

Quick Links

Categories

Randomly receive permission error

Answers