[Bug]: AC0031 and AC0032 are contradictory for table permissions

[ralf-escher]

Analyzer

ApplicationCop
AL version: BC 28
ALCop version: 0.8.3

Issue type

False positive (diagnostic fires when it shouldn't)

Rule ID

AC0031 and AC0032

Description

AC0031 and AC0032 are contradictory for table permissions that are required at runtime but not directly visible to the static analyzer. Declaring the permission triggers AC0032; removing it triggers AC0031. There is no way to satisfy both rules simultaneously without a #pragma suppression.

To reproduce

Consider a codeunit that receives a Record "Posted Whse. Shipment Line" as a parameter and reads a field from it:

With the permission declared: AC0032 fires — "Permission 'tabledata Posted Whse. Shipment Line' is declared but this object performs no database operations on table 'Posted Whse. Shipment Line'."
With the permission removed: AC0031 fires — "Permission for table 'Posted Whse. Shipment Line' is missing."
Expected behavior

Passing a record as a parameter and accessing its fields constitutes a read operation. AC0031/AC0032 should recognise record parameters as an implicit = R usage and not flag the permission as unused.

Actual behavior

Both AC0031 and AC0032 fire depending on whether the permission is declared or not. The only escape is:

#pragma warning disable AC0032
tabledata "Posted Whse. Shipment Line" = R,   // needed at runtime via record parameter
#pragma warning restore AC0032

Additional context

This also occurs for permissions required through:

Event subscriber parameters carrying a record variable
Indirect calls where the record is passed through a chain of local procedures

AL code to reproduce

{
    Permissions =
        tabledata "Posted Whse. Shipment Line" = R;  // AC0032 fires here

    procedure DoSomething(ShipmentLine: Record "Posted Whse. Shipment Line")
    begin
        // Reading a field value — no explicit Get/FindSet/FindFirst call
        if ShipmentLine."No." <> '' then
            DoWork(ShipmentLine."No.");
    end;
}

Additional context

No response

[Arthurvdv]

I could use some help to reproduce this issue. If I create a small code example the AC0031 diagnostic isn't raised. What am I missing here?

codeunit 50100 MyCodeunit
{
    procedure MyProcedure(ShipmentLine: Record "Posted Whse. Shipment Line")
    begin
        if ShipmentLine."No." <> '' then
            this.DoWork(ShipmentLine."No.");
    end;

    local procedure DoWork(RefNo: Code[20])
    begin
    end;
}

[ralf-escher]

Hi @Arthurvdv,
I checked two projects and was able to remove the permissions that triggered the AC0032 warnings—thanks for the hint!
The remaining issue concerns reports. I could try to build a minimal example to illustrate the problem if that would help.
Let me know if you need further details.

[Arthurvdv]

@ralf-escher With the update of v0.8.4 of ALCops, maybe also your issues are resolved?

Would you be able to update to this version and let me know if it fixes both issues on your side as well.

[tkroes]

@Arthurvdv I am using v0.9.0-beta.1 and found a way to reproduce this issue. It seems to do specifically (in this case) with read functions that don't hard require parentheses. The following snippet reproduces it for me:

codeunit 50001 PermissionTest
{
    Permissions = tabledata "Sales Invoice Line" = R;

    trigger OnRun()
    var
        SalesInvoiceLine: Record "Sales Invoice Line";
    begin
        Message('%1', SalesInvoiceLine.Count); // Note no Count(), which works correctly
    end;
}

This sample throws AC0032 on the permission declaration and AC0031 on the .Count call if I remove it.

[Arthurvdv]

@tkroes Thanks for reporting this and for providing the .Count example.

I've updated the analyzer to resolve the contradiction between AC0031 and AC0032 for this scenario. From a Roslyn perspective, .Count and .Count() are two different constructs, while the AL compiler currently accepts both forms. This makes the analysis a bit more challenging, especially if AL ever introduces actual properties on objects in the future.

Would you mind giving this a try with the ALCops beta channel? The fix is available in 0.9.0-beta.2. I'd be interested to hear whether it also resolves the issue in your environment.