Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AllowInCustomizations = Never, gives no compiler warning when field is still used #7771

Open
sybrenwille opened this issue Jun 18, 2024 · 4 comments

Comments

@sybrenwille
Copy link

1. Describe the bug
When you set AllowInCustomization to Never the field cannot be used in page customizations.
However you can still add the field to a page or page extension without a warning from the compiler.
The field is however not visible.
This happens in extensions themself and also when you add a field from a dependend extension

2. To Reproduce
Create a table field with AllowInCustomization set to Never
Add the field to a page.
No compiler Error/Warning/Info appears.
Publish the extension
The field is not visible on the page, and can also not be added

3. Expected behavior
I Expected a Warning from the compiler that a field is used on a page that is not allowed because of AllowInCustomization.

4. Actual behavior
There is no indication that a field is used on a page that will never appear.
You can only check this in the client itself.

5. Versions:

  • AL Language: v13.0.1027618
  • Visual Studio Code: 1.87.2
  • Business Central: 24.0

List of Visual Studio Code extensions that you have installed:

  • BusinessCentral.LinterCop
  • ALCodeActions
  • AL Extension Pack
  • AL Navigator
  • AL Object ID Ninja
  • AL Toolbox
  • AZ AL Dev Tools/AL Code Outline
@pri-kise
Copy link

pri-kise commented Jul 3, 2024

I've stumbled over this issue today, too.
To be honest - in my opinion the current behaviour is a bug.
We should be able to add a Field with the property to a page via a PageExtension, but still disallow to add the field via customization.

e.g. Imagine the following (very common) scenario.
A field is added to the SalesLine or the SalesHeader. The field has only a valid meaning in the conext of a Sales Invoice.
Therefore we add this field via PageExtension to those places.
Furthermore we don't want users to add those fields to any other page (e.g. Sales Order) via customization.
Then I would expect that I can sett the property AllowInCustomizations to Never and still see the field where it's added via a PageExtension.

Here is small exmaple of this scenario.
https://github.com/pri-kise/msdyn365bc-allowincustomizations-test

@TKapitan
Copy link

TKapitan commented Jul 8, 2024

Agree with @pri-kise - the current behaviour makes no sense. If the property is used in the base app, partners won't be able to add the field to any page. Is this REALLY something Microsoft wants to enforce? Long term, this property should be used for most of the "background" fields if Microsoft wants to allow fields added through customizations to be editable. However, partners still need to be able to add such fields to page extensions as they may have specific use cases (and this may even be legal requirements - for partners' localizations - field may not be useful for W1, but some countries may need the field to be visible/exposed to users.

The current behaviour would add additional logic for partners and Microsoft when partners start asking for "make the field accessible from page extension", similar to what we have right now with events, local/internal procedures, onprem scope etc.

@sybrenwille
Copy link
Author

Agree that you can even call it a bug.
Other option could be to add a third option Between "Always" and "Never" something like "OnlyCode".
That enables that you can only add it in code (with page Extensions) but not with customizations in the client.
Then Never makes sure nobody even third party extensions can add it to a page with page extensions.

@TKapitan
Copy link

TKapitan commented Jul 9, 2024

Agree that you can even call it a bug. Other option could be to add a third option Between "Always" and "Never" something like "OnlyCode". That enables that you can only add it in code (with page Extensions) but not with customizations in the client. Then Never makes sure nobody even third party extensions can add it to a page with page extensions.

I don't think this is needed/useful. If partners need such field to be available, they will still have options - you can use variable to show the page field and validate the field in the background. This would just add unnecessary complexity without any benefits. This should remain only for customization where we want to prevent users showing the field when they are not aware of the logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants