Nicolas Saleron Cap Vision

Hello,

This suggestion is related to this Yammer thread: https://www.yammer.com/dynamicsnavdev/#/Threads/show?threadId=1817386951745536

The issue

The matter is about library apps.

When we publish a offer, we specify for it supported countries. Any update of the offer (the main app of the App Source submission), the new version of the app is published for all supported countries.

When we publish a library app, the new version of the library is only published for the countries of the offer.

However, it is quite common for a library to be common for several offers. And these offers might not be available in the same countries. As a consequence, if a library is not published with all the offers in way it covers all the countries where this library is available, it results that the latest version of the library might not be available everywhere.

This might cause confusion and might also creates blocking issues when features are deprecated in the library: the new version is not compared with the same previous version in all countries.

As an ISV, we have no summary about which version of the library is available in which country.

The suggestions

I can propose several way to solve this issue:

- A library could be validated and published for all countries where it is already pushed on App Source

OR

- A library could be validated and published for all countries in its AppSourceCop.json

OR

- We could be able to create a hidden offer (without marketing informations) so the app remains hidden in the App Source website but submitted with the same validation process as a normal offer.

Hello,

Currently if you call an API by using the batch call endpoint and one of the call is failing, there is nothing sent in the telemetry.

It would be helpful to get the error message and stack trace for each call inside the batch as if they have been done separately.

I think it would be helpful, especially for ISV, if we had a signal emitted each time an obsolete feature is used based of the ObsoleteState in the source code.

It would be very helpful at least for the following levels:

• Actions on page: when a user click on it
• Page: when the object is opened
• Report: when the object is run
• Xmlports: when the object is run

At some point, it would be also interesting to get insights for obsolete procedure calls, but it might emit too much signals and we already have the ability to log a signal manually. Unless, we are able to set somewhere that we only want one signal per day for each obsolete procedure call.

Could we have a way on a page to know if a control is displayed or not on the client?

The goal would be to skip some costly calculations, especially in lists, if the field is hidden.

I know we have factboxes or Page Background tasks, but customers are sometimes really interested to get some info directly in the list with the other fields.

If we are able to skip the calculation if the field is hidden, it would only impact users where the field is displayed.

Sometimes we need to insert long text strings, especially if we have to hard code XML, Json or other technical structures in our code.

It would be helpful to keep the code readable if text literal could support multiline content.

For instance, instead of typing this:

myVar := 'line1'

+ 'line2'

+ 'line3';

We could type this :

myVar := 'line1

line2

line3';

Note : in this example, the result would not be exactly the same as the multiline example new line characters and spaces are supposed to be preserved.

As an inspiration for this, we could compare it with what Javascript offers: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#multi-line_strings

Sometimes we need to insert long text strings, especially if we have to hard code XML, Json or other technical structures in our code.

It would be helpful to keep the code readable if text literal could support multiline content.

For instance, instead of typing this:

myVar := 'line1'

+ 'line2'

+ 'line3';

We could type this :

myVar := 'line1

line2

line3';

Note : in this example, the result would not be exactly the same as the multiline example new line characters and spaces are supposed to be preserved.

As an inspiration for this, we could compare it with what Javascript offers: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#multi-line_strings

Would it be possible to allow markdown in Confirm, Dialog, Message and Error calls?

It is today possible in the teaching tips.

A bit of text formatting could be an enhancement in the communication with the user (if there is guidelines also of course).

For instance, field names or action names could be in bold.

If the error message is correctly designed, we could also add a link to redirect the user to the right page to fix the error, or an external link to get more information in the doc.

Exemple :

var

PostingGroupMissingErr: '**Gen. Bus. Posting Group** is missing on [Customer %1](?page=22&&filter=Customer."No." IS "%1").';

begin

if Customer."Gen. Bus. Posting Group" = '' then

Error(PostingGroupMissingErr, Customer."No.");

end;

With the recent action Get a picture, a file or a document (V3) if I try to retrieve a salesQuote in PDF, the document is always printed in English if the customer has no language code.

This is due to the fact that users usually do not fill the language code if the customer speaks the same language as they are using Business Central.

It might be a bad habit but my request is the following:

Can you add a way to get documents in the context of a specific language?

Today, it is possible with the Accept-Language (https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-connect-apps-tips#AcceptLanguage) element when calling APIs.

Could you give us a way to open a query to the user from the code.

Something like the methods we have on Page variables and the static Page object.

• Query.Run(Query::"My Query");
• Query.RunModal(Query::"My Query");
• MyQuery.Run()
• MyQuery.RunModal()

I see two reasons for this:

• We could use QueryCategory to make a query available from a page but you can only set one QueryCategory per page and this property cannot be set by pageextension objects.
• BC23 offers the ability to Analyze queries.... but if we cannot run them this feature is a bit limited.

This issue is only related to App Source apps because of AS0002 and AS0004 rules.

The issue is already described here : https://github.com/microsoft/AL/issues/5818

To summarize (app A and B are App Source apps):

1. App A can declare an enum.

2. App B can take a dependency to app A and use the enum as the type a table field

3. App A can mark the enum as ObsoleteState = Pending and then remove the enum in a future version

  The reason can also be because app B wants to remove its dependency to app A at some point.

4. App B is now in a dead end: the field cannot be removed (because of AS0002) or its datatype cannot be changed (because of AS0004).

My suggestion is not to prevent apps from removing enums. I strongly think that at some point and with the correct obsolescence path, any change should be allowed.

My suggestions are:

• Either at some point AS0002 must be relaxed (if the field is already marked as ObsoleteState = Removed for instance) (In my opinion, it is not the safer solution)
• Either AS0004 must be relaxed to allow switching from one enum to another enum (if the field is marked as ObsoleteState = Pending or Removed for instance).

The current reason since dependent extensions may break marked on the documentation page is not relevant as many AppSourceCop rules already allow to break dependent extensions IF the right obsolescence process is applied.