Mandatory CaptionClass (vs Field patterns)

[fvet]

Business Central contains several patterns for defining fields (ShortCut Dimension, DimensionSet, County, Unit Price, Amounts, ...). These always share a similar set of properties. We could imagine the developer using some snippets that contain the boilerplate code, but snippets are not mandatory to use.

Most common properties are set by the developer (TableRelation, field length, DecimalPlaces, ...), but what is e.g. often forgotten is the use of the CaptionClass.

Some Base App examples:

field(11; "Shortcut Dimension 1 Code"; Code[20])
   CaptionClass = '1,2,1';

field(12; "Shortcut Dimension 2 Code"; Code[20])
   CaptionClass = '1,2,2';

field(5715; County; Text[30])
  CaptionClass = '5,1,' + "Country/Region Code";

What might be useful, is to maintain a list (maybe already including some standards shipped via LinterCop) of field (regex) patterns that should have at least the captionClass property.

We recently stumbled upon not setting the CaptionClass for County fields, so having a regex to identify field(xxx; xxx County xxx; Text[30]) fields would be nice.

Not only is (part of ) the field name important, the fieldtype is important too. I don't want fields 'Show County'; Boolean to be included as part of the rule.

Ideally, we should be able to maintain the list of fields in the settings.json, since we adopt this pattern a lot of our custom fields.

E.g. volume, weight, dimensions, ... always receive a Unit in our add-on.

• Volume > captionClass > Volume (m³)
• Total Volume > captionClass > Total Volume (m³)
• Gross Weight > captionClass > Gross Weight (kg)
• Tare Weight > captionClass > Tare Weight (kg)
• Net Weight > captionClass > Net Weight (kg)
• Length > captionClass > Net Weight (m)
• ...

PS: CaptionClass is the one we often forget, but there are other properties too that are shared amongst field definitions (e.g. Unit Price / Amount fields, ...) Not sure if the CaptionClass rule should be considered as a separate rule, or should be looked from a broader perspective... (eventually ending up that a 'Customer No.' field should have a 'Customer' tablerelation ... ? :()

[fvet]

@rvanbekkum Any input / ideas on this one (to make it somewhat more generic for other properties)?

[rvanbekkum]

I'll give this a bit of thought, but what could be done is adding a setting to LinterCop.json which takes an array of objects to define the field patterns:

{
    "fieldPatterns" : [
        {
            "name": "*County*",
            "type": "Text",
            "propertyName": "CaptionClass"
        },
        ...
    ]
}

Which could be extended to objects as well by adding a objectPatterns setting.

This is just an initial thought of how it could be done. I think we could finetune it further, or even implement it differently.

[StefanMaron]

I like the idea of a warning if certain fields are not defined correctly.
This was a similar idea for PKs #63