-
Update the way PermissionSets are defined
PermissionSets are currently defined using XML files, which have several problems: 1. They still use IDs and basically expect you to remember the IDs of every table by memory, if you want to quickly review permissions. 2. There is no autocomplete when selecting the IDs. 3. When entering an ID there is no way to check which tables are missing in the file, nor whether the ID you are entering is already in the file, unless you manually search the complete file (very easy, specially in projects with 100+ tables). 4. There are no validations while editing the file. You get a message informing of the permission XML files found when compiling, but it is easy to miss and, specially, if you make a mistake when editing an existing file, it is very easy to miss that one of the permission sets is not being logged in the console when compiling. 5. There is a VS Command that autogenerates the file, including permissions for codeunits, pages, etc... even though those permissions will never make a different, because BC default permissions grant access to all objects. What a great way to trick new BC developers into doing the totally useless job of assigning permissions to those objects! It would be nice if you adopted a new file format, either keeping xml or using json, that: 1. Warned you if a table is not included in any of the permissionset files. 2. Warned you if no permissionsets exists (and AppSourceCop is enabled). 3. Used named tables instead of IDs. 4. Only supported tabledata permissions. 5. Validated the contents of the file. 6. Supported autocomplete. -
Add a "TableRelationDisplayField" property for fields with the "TableRelation" property set.
This a very basic UX improvement: let us set which field will be *shown* in fields with the TableRelation property. Sure, If you have used NAV/BC for long enough you end up memorising all vendor, customer, salesperson, item category codes (and get used to using the Code field as some kind of description field), but it would be nice if, for example, the Category field in the item card actually showed the name of the category. As we compatibility should be maintained, and some customers ignore the description field of some tables (as they are mostly useless), if the field defined as "Display Field" is empty, the TableRelation field/code should be shown instead. This is something that almost every other system I've used had, yet NAV/Business Central does not! :/ -
Add an option to load all AL projects in the VS Code workspace
When you refactor (F2) a method, or even when you are making changes to any object, the AL compilation engine only takes into account projects that you have explicitly opened (that is, where you have opened any AL file into the VS Code editor). This means that, for apps composed of several projects (e.g. a core project and localization projects, tests, etc.) you have to explicitly open a file in everyone of the projects, every time you open the workspace, if you want the AL engine to check of errors, consider them when refactoring, etc. If would be very useful to have an option to load all AL projects/folders in a workspace, either when it is opened, or by running a VS Code Command. This idea is related to this GitHub ticket: https://github.com/microsoft/AL/issues/5878#issuecomment-634700638 -
defaultApplicationArea in app.json
Yeah, when you need it, the ApplicationArea property is great. But when you are developing a per tenant extension for a customer, of an app for app source where it's all or nothing (if you install it is because you want to see all fields/actions added by the app), having to add ApplicationArea = XXX to every single element becomes just visual noise, and even if you have some elements with a different ApplicationArea they will be hard to notice because every single element in the page has that property. It would be nice to be able to specify a defaultApplicationArea in the app.json (which might not be All, depending on what the app does), so that any field or action without a specified Application Area is assigned to it. P.S. I'm not adding an idea for it, but DataClassification is in a similar situation. I can see why you want us to be sure that we assign the correct DataClassification for each field. But really, if most people just copy/paste DataClassification = CustomerContent without a second thought (because that's the correct value 99% of the time), how is that different from just making CustomerContent the default and just letting us specify a different value when needed? -
Add extra information to the delete confirmation dialog.
Sometimes, when a user wants to delete a record, we might want to show some extra information about the consequences of doing so (e.g. "This will delete all related XXX", or "The customer already has XX active, and deleting this record will stop them".
When we do so, this results in two confirmation dialogs for the user: the default BC dialog ("Delete XXX?") + our confirmation dialog.
We believe that the UX would be much improved if there was some kind of event in BC to which we could subscribe when deleting records, that let us return an extra text to be shown in the default dialog. So that instead of just
"Delete XXX?"
The user would be shown:
"Delete XXX?
This will..... (additional text)"
Something like "OnBeforDeleteConfirmation(var Rec: Record XXX; var AdditionalText: Text)".
-
Add a SortBy and SortIdx properties to Enums so that they can be shown in a different order from their IDs
Ok, I think we've all been there: you have an enum that's shown to the user, and you need to add a new option. But, because of how enums work, if you use sequential IDs, and add a new option, it will always appear at the end, regardless of the logical relation between the different options.
What I'm proposing is to have a new SortBy property in enums, that specifies how Enums should be shown to the user (in dropdowns, when selecting a value). This property would have three possible values: Index (default), SortIndex, Caption.
This way, if nothing is specified, everything will work as usual. But, if we specify
enum 50000 "My Example Enum" { SortBy = Caption; value(0; OptionB) { Caption = 'B'; } value(1; OptionA) { Caption = 'A'; } }
This would mean that the user would see a dropdown with the options "A" and "B" (actually depending on the user language and translated captions).
Similarly, if we specify SortBy = SortIndex
enum 50000 "My Example Enum" { SortBy = SortIndex; value(0; OptionB) { Caption = 'B'; SortIndex = 1; // Required property if SortBy = SortIndex. } value(1; OptionA) { Caption = 'A'; SortIndex = 0; } }
The user would see "A" and "B" as options (in that order), regardless of their captions.