You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a tough one, not impossible I believe, but could be complex.
The assignment of the table on the RecordRef is determined during runtime. So the LinterCop, as a static code analyzer, can’t determine this during compile time.
What I can think of is something similar as the CodeCop AA0181 warning. This would then translate to;
Trigger on a .Get() of a RecordRef instance
Retrieving the Local/Global variable instance
Loop through the codeblock of the method, line-by-line, for a match on .Open()
Retrieve the Database:: value
Then there could be more complex situations:
localprocedure DoMagic(Entry: Record "PTE Entry")var
RecRef: RecordRef;
begin
RecRef.Open(Database::"Incoming Document");
RecRef.Get(Entry."Record ID");
RecRef.Open(Database::"Document Sharing");
RecRef.Get(Entry."Record ID");
RecRef.Modify(false)end;
The .Modify() here could then raise a false positive for the "Incoming Document" table. So when looping through the codeblock, we need to start at the line of the action (.Get/.Modify) and walk upwards till we find the first matching .Open() reference.
With the restriction that the .Open operator and .Get/.Modift/.. operator are within in the same procedure I think it should be possible. I'm unsure if there are other scenario's where the "just-look-at-the-lines-above-in-the-code" method could still cause false positives.
I know that it's difficult to check this rule for RecordRef, but there is one case, that maybe can be found.
At the least the indirect read permission could be found here.
The text was updated successfully, but these errors were encountered: