Nicolas Saleron Cap Vision

Before removing a page or a report, we mark the object as ObsoleteState = Pending in version N. In version N+1, we delete the object. But in version N+1, we also create new objects. For that, we use the intellisense in VSCode that gives us the next available object number in the app object range. The con comes the fact intellisense recycles the object number deleted, without looking at the object numbers in use in version N, beside the fact the package is in the alpackage folder for the AppSourceCop. The consequence is errors coming from AppSourceCop about the fact all actions/fields/public procedures has been changed within the same object id between version N and N+1. Could the object numbering be improved? It would require to consider objects declared in the previous version as still in use.

Related to this discussion : https://github.com/microsoft/AL/issues/6545#issuecomment-803894400 I propose to change the current behaviour of the ObsoleteState or (as @qutreson suggested) gives the hability to opt-in to a new behaviour: when a control is marked as obsolete, then all child control should inherit this state. It would mean: - If I mark a page, at the object level, as ObsoleteState = Pending, then all fields, actions, procedures are automatically obsolete. - If a group/repeater is ObsoleteState = Pending, then all child controls becomes obsolete. If the child element has its own ObsoleteTag/ObsoleteReason, this one should overload the same property at the parent level.

In BC18 we have got a new object type named permissionset. This object type allows to build a permission by including other permissionsets (with property IncludePermissionSets) and add our own on top. Although, we frequently deploy customers by copying standard permissionsets (like D365 BASIC) where we remove some permissions (like those on G/L Entries and G/L Accounts). The immediate consequence is a important workload when major upgrades occur: new tables are created, customers cannot work until we add these tables on their custom permissionsets. This could be "easily" solved if we could exclude a permissionset from another. For instance, I could create a permissionset for G/L Entry and G/L Account tables: permissionset 50000 "Accounting PTE" { Permissions = tabledata "G/L Entry" = RIM, tabledata "G/L Account" = RIMD; } Then I could create my customized D365 BASIC permissionset: permissionset 50001 "My Basic PTE" { IncludePermissionSets = "D365 BASIC"; ExcludePermissionSets = "Accounting PTE"; } Users with permissionset My Basic PTE would access the same things as D365 BASIC expect the read permission on G/L Account and the read permission on G/L Entry would be removed. It would mean that permissionset are build this way: First add IncludePermissionSets, Then remove ExcludePermissionSets and finally add Permissions. This design would permit us to build custom permission sets that easily can be upgraded if Microsoft adds new objects.

Developers have a property in AL named ExtendedDataType (https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/properties/devenv-extendeddatatype-property). In the modern client, this property does not really surface in the UI for URL and EMail, especially when the field is editable. My suggestion if this one: if there is no lookup or drilldown specified for the field, then display a default button (similar to the one that was displayed in the retired Windows Client). => If the ExtendedDatatype is URL, run a Hyperlink command. => If the ExtendedDatatype is EMail, then, now we have a very good Email module, open an empty e-mail. If on the top of that we could get global an event to catch the click with the current record, fieldno and field value to implement our own behavior, that would be awesome.

As a VAR we manage many customers and we might have multiple tabs in the web browser with different Dynamics 365 Business Central admin center opened. The tenant ID is displayed in the address bar and in environment details but the tenant name (aka Primary Domain Name) would help to distinguish each customer. Could it be displayed somewhere? (in the

On the Customer card, there is a field called "Ship-to Code" related to customer "Ship-to Address" table. There is such table on Vendors ("Order Address") but there is not a similar field on the Vendor Card to specify the default order address code. Could you add such field to get consistent capabilities between customers and vendors?

If you post a purchase invoice with item charges with mistakes, you can create a credit memo. However, the credit memo is hard to complete because the item charge assignments are not copied from the purchase invoice. Could you implement this feature that would be really helpful when correcting purchase invoices? I guess a similar feature would also be helpful on sales credit memos.

On tableextension or pageextension objects, we are able to write to platform events like OnAfterAction, OnOpenPage, OnAfterInsert, and so on. But for IntegrationEvent or BusinessEvent, we have to create codeunits. If I take as an example the page "Sales Order Subform", I would like being able to do this: pageextension 50000 "Sales Order Subform PTE" extends "Sales Order Subform" { //OnBeforeSetDefaultType is an IntegrationEvent declared in Sales Order Subform page trigger OnBeforeSetDefaultType(var SalesLine: Record "Sales Line"; var xSalesLine: Record "Sales Line"; var IsHandled: Boolean) begin //Do something.. end; }

If you have an empty pageextension like this: pageextension 50000 "MyPageExt" extends "Customer Card" { } You cannot remove the object from your app because of rule AS0029. If think we cannot take dependency on pageextension themselves so removing a pageextension should not be a breaking change (unless there is control inside but that way we have the hability to obsolete them and remove them afterwards). Could you improve AS0029 to ignore such cases?

1. Describe the bug When you rename a pagecustomization object, the error AS0089 is raised and I do not see any path to do it. 2. To Reproduce Steps to reproduce the behavior: In V1 of your app create a pagecustomization named "My Cust. Card" In V2 of your app, rename the pagecustomization "My Customer Card" 3. Expected behavior I do not see immediate problems regarding changing the name of a pagecustomization, so my first thought would be this rule should not apply to this type of object. However if it can be a problem, then, we should be able to mark a pagecustomization as obsolete. 4. Actual behavior The error AS0089 is raised, preventing us to change the name of this object. 5. Versions: AL Language: 8.1.525271 Visual Studio Code: 1.60.2 Business Central: 19 List of Visual Studio Code extensions that you have installed: AL Language