Frédéric Vercaemst

"When creating a TableExtension and/or PageExtension object it would be really useful to be able to call the local functions / variables of the original object. This would also come close to the concepts of inheritance. You could also address the inherited object with Base.XYZ to call the function. In this case, it would also make sense to access the global variables in this object." Full discussion / other arguments and examples are available on Github (originally posted by FSharpCSharp) https://github.com/Microsoft/AL/issues/593

AdditionalSearchTerms works fine on pages, but could be used even more 'Application wide'. When the property is set, using 'Tell Me', the page will show up when you search on one of the AdditionalSearchTerms values. However, when you add an action to a page, referring to this same page (Runobject), I would expect the AdditionalSearchTerms to be used as well to list the action in the search results for the current page context. E.g. set AdditionalSearchTerms = 'Quotation' to the 'Purchase Quotes' page. Searching for 'Quotations' show the 'Purchase Quotes' page. When I have the 'Vendor Card' page opened and I would search for 'Quotation', I would expect the 'Quotes' action (Navigate > Documents > Quotes) to be listed as well within the search results (On Current Page).

We often create generic functionalities (linking attachments, notes, comments, ...) that use 'RecordID' as a means to link data between master/detail record. On the master record, flowfields are added to show the no. of linked records, ... On the master pages, generic factboxes are added to show the linked records (see #1552). The above is always coded, since there's no native support for the 'RecordID' integration inside the FlowField definition or the SubPageLink property. Adding support for the RECORDID function (or an alternative to it) in various field/page properties would ease the integration of application-wide / generic features. More info on https://github.com/Microsoft/AL/issues/1757 https://github.com/Microsoft/AL/issues/1552

The AL CodeCop currently only detects unused variables, both global and local. However, when a local function is created, containing function parameters that are not used, it would be interesting to have a CodeCop rule detecting these 'unused local function parameters' as well. More info on Github https://github.com/Microsoft/AL/issues/4929

Using WITH statements in combination with function parameters can often lead to errors, since the WITH statement is using the record 'field' instead of the - by the developer intended - function parameter. In the function below, it would be interesting to have a CodeCop rule to alert to refactor the code by either removing the WITH statement, either by renaming the function parameter 'Code' to 'NewCode' or 'PaymentTermsCode' to improve readibility / avoid future conflicts. CreatePaymentsTerms(Code : Code[10]) WITH PaymentTerms DO BEGIN INIT; Code := Code; ... END;

If a new flowfield of type Lookup is created, the field datatype/length is set. If the related table definition is changed, e.g. increase of related field length from text 50 to text 100, the related Lookup flowfields should be increased as well. Describe the solution you'd like: Have a new CodeCop rule that checks any Lookup flowfields to match the EXACT length of the related field See also on Github https://github.com/Microsoft/AL/issues/4494

If a new field is created, having a table relation, the field datatype/length is set. If the related table definition is changed, e.g. increase of related (key) field length from code 10 to code 20, the fields having a table relation should be increased as well. Describe the solution you'd like: Have a new CodeCop rule that checks any field having a TableRelation to match at least the MINIMUM length of the related field (cfr. test codeunit 134926 Table Relation Test) Also see Github https://github.com/Microsoft/AL/issues/4493

There are a lot of improvements to be made on the 'translation' experience to be on par with the translation experience in C/AL. These suggestions are not about external XLIFF editing tooling, but about the process inside VSCode. Here are some suggestions / feedback: - Moving around Labels (e.g. cut-paste from table to codeunit), reusing labels (copy-paste) or renaming labels ('Text001' to VarMsg / fixing typos) often breaks the translations since it changes the trans-unit ids. In C/AL, copy-pasting a Text constant always kept all translations. - As ISV, XLIFF files can be usefull to send to an external translation agent on a periodic basis. However, as VAR, the developer (team) is responsible to deliver per tenant extension in English AND native language on a daily basis. In C/AL, CaptionML ruled. In VSCode, we should have an as-easy alternative to immediately add the translation in VSCode (not using LCS / external extensions - tools / databases to maintain - import translations). Providing a VSCode extension (cfr. AL outline, AL object browser, ...) showing all translations of the current object in a Grid style, containing the aggregated contents of the various Xliff files in columns, allowing grid updates, auto-updating the xliff files. - In general, hide the complexity of having to copy / overwrite / merge xliff files by language. Please keep the translation XLIFF files automatically in sync upon building an extension with any changes like newly added fields / labels, renamed / refactored labels, ... - Maintain a 'global' dictionary of translations that can be referenced all over the extension. (Table) Fields / labels / variables (on pages or report datasets) which are copied on multiple objects should reference a single translation. This reduces the no. of translations and improves the uniformity. - Allow adding 'tooltips' on 'table' fields instead of pages, with the option to reference the global dictionary. - Discover / mark translations where the source has been changed. Changing a source translation requires possible target translations to be reviewed. E.g. when adding an option to an OptionCaption, all translations require review. - Provide CodeCop(?) alternatives to the PowerShell commandlets to ease dealing with translations to detect missing Captions.

We would like to have the totals (over all countries) of the fields / columns TotalValueofItemSupplies, TotalValueofServiceSupplies, EU3PartyItemTradeAmt, EU3PartyServiceTradeAmt printed at the bottom of the report (Report 19 - VAT- VIES Declaration Tax Auth). This will ease verification of the amounts printed.

We think this feature was available in earlier versions of NAV (3.60?)


 

On an action that launches a page, the default 'RunPageMode' property is set to 'Edit', which allows you to immediately edit the record.

When coding the actions instead and calling the page via PAGE.RUN or the PageManagement generic functions, the page is opened by default in View mode, which requires the user to click 'Edit' first.

We'd like to be able to call / run any page via code in Edit mode immediately. (without having to create a variable of the page and set the 'Editable' property first)