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 Your Privacy Choices Consumer Health Privacy