-
Warn about insufficient/invalid arguments in a call to the built-in GET procedure
Would like to see that the AL compiler or one of the code analyzers gives a warning when the Get procedure is called with insufficient arguments, too many arguments, or arguments of invalid types that do not match the formal parameters expected given the PK of the record in question. This is an error that is hard to spot, so I think detection and a warning on this error would be really helpful. -
Code analyzer warning on passing (text-)array with (entries of) insufficient length as an argument to a procedure
Would like to see a code analyzer rule that warns developers when in code a text-array is passed as an argument, but the array length or max. length of the text-entries do not match the formal parameter. (1) Example 1: Given the following variable declarations: var FormatAddr: Codeunit "Format Address"; CustAddr: array[8] of Text[50]; And the following statement: FormatAddr.SalesHeaderBillTo(CustAddr, SalesHdr); Knowing that this procedure has the following signature: SalesHeaderBillTo(VAR AddrArray : ARRAY [8] OF Text[100];VAR SalesHeader : Record "Sales Header") We should get a warning on a possible overflow (i.e., array[8] of Text[50] given, but array[8] of Text[100] expected). (2) Example 2: Given the following variable declarations: var FormatAddr: Codeunit "Format Address"; CustAddr: array[7] of Text[100]; And the following statement: FormatAddr.SalesHeaderBillTo(CustAddr, SalesHdr); Knowing that this procedure has the following signature: SalesHeaderBillTo(VAR AddrArray : ARRAY [8] OF Text[100];VAR SalesHeader : Record "Sales Header") We should get a warning on the length of the arrays not matching (i.e., array of length 7 given, but array of length 8 expected). -
Service Item Worksheet as Standard Report Usage/Selection
Add the "Service Item Worksheet" document as a standard report usage/report selection in the base application. The Service Item Worksheet is a document that is very often customized, not simply in layout(s), but also in report object(s). Therefore, the standard report is often replaced with a custom report object. It is also a document that is used externally, i.e., send to and viewed by their customers. Also, via report selections one could also configure to use multiple reports for the service item worksheet document. It also seems odd that all other 'main' sales, purchase and service documents already have a report usage, except for this document. See also: https://github.com/microsoft/ALAppExtensions/issues/2347 (This issue was closed and it was suggested to add it as an idea instead) -
Show All Overloads of a Procedure in the IntelliSense (or indicator of multiple overloads)
If you have a procedure that has multiple overloads (so, for example, same procedure name but different parameters), then if you want to add a new statement somewhere else in your code calling one of these procedures utilizing the IntelliSense will always only show a single procedure and not all the overloads. I would suggest to show all overloads for the procedure when you use the IntelliSense, or at least show some indication that there are multiple overloads available. For example, when you use the IntelliSense when you create a new statement with a function call in C# you will see an indicator that says "1 of 2" if there are multiple methods that you can choose from with the same name. It would be very useful if we can see the signatures of the possible overloads we can choose from. -
Implement "Quick Fix" in VSCode for completing Handler functions' signatures
When you add one of the Handler attributes to a procedure, your procedure should match the expected signature for that Handler-type. For example: [MessageHandler] procedure MyMessageHandler() begin end; Will raise the following error message: ``` The signature of procedure 'MyMessageHandler' does not match the signature required by attribute 'MessageHandler'. The expected signature is: MyMessageHandler(Message: Text[1024]). AL(AL0241) Here's a picture of this: https://i.imgur.com/vJnjqDd.png This also shows an option to apply a *Quick Fix*, however there are no options for this yet. It would be nice to see an option that automatically lets us fix the signature of procedures in such situations. -
Code analysis error or warning on missing affixes for permissionset objects (AS0011 for permissionset objects)
Dear Dynamics 365 Business Central team, It might be good to look into implementing AppSourceCop rule AS0011 for permissionset objects as well, i.e., raise an error (or warning) that tells you that your affix is missing in the object name. If I am correct, the permission set IDs could clash in the same way as object names for existing object types could (if not, then it would be good to know as well). If you need any further information, then I am glad to further elaborate. -
Static Code Analysis Rule that checks that the DataPerCompany property is set explicitly
It would be helpful to have a code analysis rule that enforces you to set the DataPerCompany property on a table object explicitly. Considering this property has a huge impact, it would be good to have the developer be reminded of the choice of making the table a per-company or 'global'/company-wide table. This could initially be a warning that is changed into an error a few major releases later. -
Enum.GetName() Method
Request
Add an Enum.GetName() method for the Enum datatype.
Similar to how we have an Enum.AsInteger() method.
Syntax
The Name of the Enum Value as a Text value := Enum.GetName()
Parameters
Enum
Type: Enum
An instance of the Enum data type.
Return Value
The Name of the Enum Value as a Text value
Type: Text
Examples
local procedure Sample1(CustomerStatus: Enum "Customer Status") var EnumValueName: Text; begin EnumValueName := CustomerStatus.GetName(); end;
local procedure Sample2() var EnumValueName: Text; begin EnumValueName := Enum::"Customer Status"::"Gold Customer".GetName(); end;
Explanation and Motivation
I am aware that we can currently use the following code to get the Enum value name, but it is very inefficient:
(See GitHub issue 5576: https://github.com/microsoft/AL/issues/5576#issuecomment-572456605)
procedure GetEnumValueName(MyTestEnum: Enum TestEnum) Name: Text; var Index: Integer; begin Index:= MyTestEnum.Ordinals.IndexOf(MyTestEnum.AsInteger()); MyTestEnum.Names.Get(Index, Name); end;
Instead I would like to get an instantaneous result, rather than needing an O(n) IndexOf-operation to get the enum name (impacting performance) and requiring multiple statements to achieve this.
So translating that example in what we would like to see:
procedure GetEnumValueName(MyTestEnum: Enum TestEnum) Name: Text; var Index: Integer; begin Name := MyTestEnum.GetName(); end;
-
Detect obsoleted report object columns / Inform administrators that their report layouts are using obsoleted columns
It is possible to set the ObsoleteReason, ObsoleteState and ObsoleteTag properties on report object columns (and data items).
That's good, but there is no way for administrators/users to know that their report layouts are still using obsoleted report object columns.
Because of that users may be in for a surprise when suddenly they cannot render their report layouts anymore, because the extension developer removed obsoleted report columns with a new update of the extension containing the report object columns.
It would first of all be good if we had a way of detecting it ourselves, for example by having:
(1) Information about the ObsoleteState in the XmlPart of the report object, so we can at least use that to detect it.
With that I mean, include it on the 'column definitions' that you can get from
WordXmlPartAsText := Report.WordXmlPart(MyReportID, true);
Where it would be great to have an attribute/property that shows us that the report column has been obsoleted, e.g.:
MyColumnName (or something similar)
(2) Have some sort of "Report Column Metadata" table which would report back the ObsoleteState of report object columns.
Similar to how we have metadata tables which include the ObsoleteState for table objects and table fields.
Ideally, it would be great if BC can also somehow automatically raise attention to the administrator/user that layouts that have been rendered are referencing obsoleted columns.
That could be via a notification, telemetry (maybe even 'daily telemetry'?), and/or somewhere else.
NOTE: Please consider this for both *dataitem* and *column* nodes.
