microsoft / AL

Home of the Dynamics 365 Business Central AL Language extension for Visual Studio Code. Used to track issues regarding the latest version of the AL compiler and developer tools available in the Visual Studio Code Marketplace or as part of the AL Developer Preview builds for Dynamics 365 Business Central.
MIT License
744 stars 245 forks source link

AppSourceCop not warning if 50,000 to 99,999 field ID Used #5230

Closed eknraw closed 4 years ago

eknraw commented 5 years ago

Describe the bug If I set IdRange in app.json to be in an AppSource object ID range and turn on AppSourceCop it doesn't warn/error when using a per tenant extension field id range.

However, if I turn the PerTenantExtensionCop ON it will warn me that a field id is NOT in the 50,000 - 99,999 range, even if I have IdRange to be in an AppSource only range.

To Reproduce Steps and to reproduce the behavior:

Set settings.json:

{
    "al.enableCodeAnalysis": true,
    "al.codeAnalyzers": [
        "${AppSourceCop}",
        "${CodeCop}",
        "${UICop}"
    ]
}

In app.json (something like this)

  "idRange": {
    "from": 70000000,
    "to": 70999999
  },

Create a new table with a field ID in the 50,000-99,000 range.

AL Code to reproduce the issue

table 70000000 "Test Table"
{
    DataClassification = CustomerContent;

    fields
    {
        field(50000; "TEST"; Integer)
        {
            DataClassification = CustomerContent;

        }
    }

    keys
    {
        key(PK; TEST)
        {
            Clustered = true;
        }
    }

}

Expected behavior I'd want (hope?) a warning or error that a per tenant extension id field range was being used.

Versions:

eknraw commented 5 years ago

This is an edge case but potentially very devastating.

If I was developing an AppSource app and included a 50,000-99,999 thousand range field in a table that was used with TransferFields, let's say a "posting" table, I could put myself in an unrecoverable situation by then adding the same field id to an extension table (in a per-tenant extension) of the unposted table. If the data type was not the same this would cause an error even if you have marked fields as ObsoleteState = Removed.

ALGitHubBot commented 4 years ago

The fix for this issue has been checked in to the master branch. It will be available in the bcinsider.azurecr.io/bcsandbox-master Docker image starting from platform build number 37837.

If you don’t have access to these images you need to become part of the Ready2Go program: aka.ms/readytogo

For more details on code branches and docker images please read: https://blogs.msdn.microsoft.com/nav/2018/05/03/al-developer-previews-multiple-releases-and-github/ https://blogs.msdn.microsoft.com/freddyk/2018/04/16/which-docker-image-is-the-right-for-you/