Explicit set Extensible property

[jwikman]

When you have published a new AppSource app, where there are still some developments going on (you all know about time to market 😉), having to obsolete controls for every little change you need to do on pages can cause some challenges and slows down development.

I rather set Extensible = false on the objects until we are ready to let other extend them.
But if we miss the Extensible property, we need to go for deprecation of controls or objects before we can do our changes.

I would suggest a new rule: Show a warning if the Extensible property is missing on tables, pages, and reports.

Similar rules are LC0007 and LC0011 which has saved me several times already!

Don't get me wrong, I do like that other extensions can extend our objects - but only when time is right, and we do not cause the other extension issues because of refactoring.

[Arthurvdv]

@jwikman Good idea, and seems like a easy rule to create.

If I'm not mistaken these are the objects that could be set with the Extensible property true or false.

• Table
• Codeunit
• Page
• Report
• Query
• XmlPort
• Enum

Are there any exceptions to this rule? For example

1. If the object has Access = Internal; set, do we then really need to raise this also rule?
2. Not sure how a table with TableType = Temporary; works on modifications with the AppSource validation.

[jwikman]

According to the docs for the Extensible property (https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/properties/devenv-extensible-property), it applies to these object types:

• Report
• Enum Type
• Table
• Page

The default values are true for all, except Enums. Since the impact of missing the property on Enums is zero, I suggested this rule to only apply on tables, pages, and reports.

Since the Access property does not exist on reports and pages, you could add an exception for Access = Internal; on tables (and Enums, if you decide that the rule should apply to them as well).
I can't see why you couldn't extend a temporary table, so rule should not consider the TableType property.

[Arthurvdv]

Oops, I was looking into the SymbolKinds in the compiler itself, which is a long list of objects. An extensible codeunit, what was I thinking 🙈

The default values are true for all, except Enums. Since the impact of missing the property on Enums is zero, I suggested this rule to only apply on tables, pages, and reports.

Completely agree!

Since the Access property does not exist on reports and pages, you could add an exception for Access = Internal; on tables (and Enums, if you decide that the rule should apply to them as well).

I believe it is best to add this exception for the tables, so the rule doesn't get raised unnecessary. I'm going to skip the Enum objects for this rule, because of the default value of false.

I can't see why you couldn't extend a temporary table, so rule should not consider the TableType property.

On many places in the LinterCop we've need to exclude this type of table. Just checking if we're not overlooking something here.

I've tested with the examples below.

table 50100 MyTable // raise rule LC0034
{ 

}

table 50101 MyTable2 // Do not raise rule LC0034
{
    Extensible = true;
}

table 50103 MyInternalTable // Do not raise rule LC0034
{
    Access = Internal; 
}

enum 50100 MyEnum  // Do not raise rule LC0034
{

}

report 50100 MyReport  // raise rule LC0034
{

}

page 50100 MyPage  // raise rule LC0034
{

}

Thank you for creating the idea and helping setting the right conditions for this new rule!

[Arthurvdv]

Did some more testing, should we also exclude some PageTypes, like API?

Is there somewhere documentation on which PageTypes can be extended and which not?

[jwikman]

Of course... From my knowledge it is only the API pages that cannot be extended, but I might be wrong...

[Arthurvdv]

To be sure I've tested alle the types and indeed the PageType API is the only one which isn't allowed to extend.

I thought there where idea's for in the future to allow extending API pages. For now I'll exclude these PageTypes.

[Arthurvdv]

I think I have everything in place for rolling out this new rule to the prerelease.

Last horde: What should be the default severity of this rule? Is it okay to set it as Disabled, like the LC0007 and LC0011?

[jwikman]

Oh, I didn't realize they were disabled as default - since we've got them as errors in our ruleset! 😅

But I'm fine if you go for the same here, it might be too intrusive if enabled for all.

[fvet]

By accident reported a similar issue in combination with AZ AL Dev Tools wizards ...
anzwdev/al-code-outline#508

Reading the above, I wonder if it make sense so set it explicitly for enums or not.
As the default is false, it has no impact, although it might improve readability?

[Arthurvdv]

This is a tough one I believe 🤔

For consistency of the rule and readability of code I would like to raise this rule also on enums, on the other hand, I would only like to raise this rule when it's necessary for it's purpose: Unawares releasing of extensible objects.

So I'm a bit conflicted here and for now lean towards to only raise the rule when necessary.

[fvet]

Givin' this a second thought, it makes more sense indeed only raising the rule when it's necessary for it's purpose: Unawares releasing of extensible objects.

[Arthurvdv]

The rule is available in the (pre)release v0.30.7

If you encounter an issue with this new rule, it would be best to create an issue, where I'm going to close of this discussion now the rule is created.

@jwikman and @fvet, thank you for the insights on this in the discussion here, much appreciated.

[jwikman]

I just gave it a quick spin, and I couldn't find any false positives in my projects so far. :)