Open sybrenwille opened 4 months ago
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
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.
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.
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.
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:
List of Visual Studio Code extensions that you have installed: