-
Data / objects usages insights
In AL Github issue 984 (https://github.com/Microsoft/AL/issues/984), a reference has been made to support 'Insight' (and Telemetry) capabilities in a future release. Are there more details available on the content / planning? Addon / modules / on-prem We're looking for a solution to give us more insight in the 'features' / modules used in NAV databases. E.g. when upgrading older customers (from other partners), we often have to deal with lots of customisations that are no longer used (and thus require no upgrade). The customer is not aware of these features, so we need to analyse either the objects individually, either analyze the company information / table data (check the date of the latest transactions), ... Having this kind of information available on 2018 / BC on-prem would give us better insights. The same applies for report upgrades. If the customer would have the 'Report Usage' feature installed on the database, this would give us some insights whether reports are still used and can be skipped during upgrades. Having this natively available on 2018 / BC would give us better insights. We have similar requirements to optimize addon managament. Getting better insights on 'features' used can lead us to deprecate some features, or optimize some heavily used modules instead. Knowing whom (customer) is using what (not only based on the license modules, but also on a more detailed 'feature' level) when (how recent the feature is used) is important information. Can we expect to receive this kind of feature / object / data insights from D365 BC? How often / recent is an 'object' (report / ...) used? How recent are the latest 'table' transactions? If not, we'll have to build a proper mechanism to extract / report these statistics or find a 3rd party tool. D365 BC / extensions The same applies for extensions. If customers install our extensions (via AppSource or not), just to try out, but never use it, how can we get insights on the installed extensions / versions out there? Splitting extensions into smaller pieces (by feature) could give us already some more detailed insights. But the same requirements as above apply here as well. Copied from AL Github issue 2507 (https://github.com/Microsoft/AL/issues/2507)
-
Date Formula support on Job Queue Report Request Page options
When applying filters to date fields on pages, date formulas can be used (TODAY, +1D, -2D, ...) Saving the page filters as a view takes into account these date formulas. When opening the view on a later date, the date filters applied are recalculated, since the date formula seems to be stored internally. We would like to have the same behavior on the job queue report request page options. When scheduling a report to be ran periodically, often the data on the report is to be filtered as well. When using the same dateformula filters on date field of the report dataset, the dates are stored fixed and the formulas are lost / not recalculated when the report is ran on another date.
You’re offline. This is a read only version of the page.
