AllowInCustomizations redundancy
AllowInCustomizations set on a table or tableextension applies automatically to every field in that object. When a field repeats the same value, the property is redundant — it adds noise to the object definition without changing behavior. Remove the field-level property and let the object-level setting take effect.
Example
The following field redundantly specifies the same AllowInCustomizations as the table:
table 50100 MyTable
{
AllowInCustomizations = Never;
fields
{
field(1; MyField; Integer)
{
AllowInCustomizations = Never; // AllowInCustomizations redundancy [LC0094]
}
}
}To fix this, remove the redundant property from the field:
table 50100 MyTable
{
AllowInCustomizations = Never;
fields
{
field(1; MyField; Integer)
{
}
}
}Table extensions
For table extensions the rule only looks at the AllowInCustomizations property defined on the table extension object itself. It does not consider the base table being extended. This means that if the base table sets AllowInCustomizations = Never and your table extension independently sets the same value, no diagnostic is raised. The table extension keeps its own explicit setting so it is unaffected when the base table changes.
The following field is flagged because it repeats the value already set on the table extension:
tableextension 50100 MyTableExtension extends MyTable
{
AllowInCustomizations = Never;
fields
{
field(50100; MyExtField; Integer)
{
AllowInCustomizations = Never; // AllowInCustomizations redundancy [LC0094]
}
}
}However, setting AllowInCustomizations on the table extension object itself is not considered redundant even when the base table already specifies the same value. The following code does not trigger a diagnostic:
tableextension 50100 MyTableExtension extends MyTable
// Base table already has: AllowInCustomizations = Never;
{
AllowInCustomizations = Never;
fields
{
field(50100; MyExtField; Integer)
{
}
}
}